Updating diagnostic device software and enabling features

Abstract

A method of unlocking at least one feature of a diagnostic device. The method includes receiving, from a user, product-indentifying information (such as serial number) for the diagnostic device. A server can then generate a software key that corresponds to the product-identifying information and transmit the software key to the user via a text-to-speech server to cause the software key to be spoken to the user. The user can enter the software key into the diagnostic device to unlock the at least on feature. The transaction can be initiated at the user's telephone, where the software key is also received, eliminating the need for a network-connected diagnostic device.

Description

RELATED APPLICATIONS

Priority is claimed to U.S. Provisional Patent Application No. 60/392,322, entitled “Use Of XML Protocols For Updating Repair Equipment, Diagnostic Equipment, Tools,” filed on Jun. 27, 2002. The entirety of this patent application is expressly incorporated herein by reference.

BACKGROUND

1. Technical Field

A method and system relating to the field of diagnostic devices, and, more particularly, a method for updating software or enabling diagnostic device features for use in automotive maintenance and repair, is disclosed.

2. Description of Related Art

Recent advances in computer technology have made software-enhanced equipment nearly ubiquitous in developed countries. This applies especially to equipment that, as recently as a decade or two in the past, no one would foresee as using software and processors for improved functionality, such as automotive diagnostic equipment. The use of relatively inexpensive memory, processors, and displays, for example, has enabled manufacturers of such equipment to couple legacy diagnostic devices, such as multimeters, scan tools, lab/ignition scopes, and component testers, with repair and diagnostic database software that puts large amounts of repair information literally at technicians' fingertips. One such device is the MODIS (Modular Diagnostic Information System) produced by Snap-on Technologies, Inc. Because it is modular and software-enabled, the MODIS can be updated easily to prevent obsolescence.

Even though automotive diagnostic devices have entered the realm of high technology, they are still highly specialized tools, rather than general-purpose computers. Because of this, such devices tend to be stand-alone rather than network-connected (although the MODIS, for example, has ample interfaces for communication with computers and other devices). In addition, they are not generally equipped with Internet access, although they could be. Verifying a user's authorization to access new or updated software or installed features is an important function that allows value-enhancing updates, but transmitting, receiving, and verifying software keys to verify authorization can be somewhat difficult to implement with stand-alone devices. Accordingly, a method to “unlock” available but disabled equipment features can allow an equipment manufacturer to confidently make software updates, features, and products readily available (for example, over the Internet and on CD-ROMs) without fear of unauthorized use.

SUMMARY

In one aspect, a method of unlocking at least one feature of a diagnostic device is provided. The method may include receiving, from a user, product-identifying information (such as a serial number) for the diagnostic device, and identifying a software key that corresponds to the product-identifying information. The method may also include transmitting the software key to the user via a text-to-speech server to cause the software key to be spoken to the user. Next, the method includes entering the software key into the diagnostic device to unlock the at least one feature.

In another aspect, a method of unlocking at least one feature of a diagnostic device is provided. The method may include receiving, from a user, product-identifying information (such as a serial number) for the diagnostic device, and identifying a software key that corresponds to the product-identifying information. The method may also include receiving payment information from the user and transmitting the software key to the user via a text-to-speech server to cause the software key to be spoken to the user. Next, the method includes entering the software key into the diagnostic device to unlock the at least one feature.

In another aspect, a method of unlocking at least one feature of a diagnostic device is provided. The method may include receiving, from a user, product-identifying information (such as a serial number) for the diagnostic device, and identifying a software key that corresponds to the product-identifying information. The method may also include receiving from the user information regarding the feature or features the user wishes to unlock, and transmitting the software key for that feature or features to the user via a text-to-speech server to cause the software key to be spoken to the user. Next, the method includes entering the software key into the diagnostic device to unlock the at least one feature.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present system and method are described herein with reference to the drawings, in which:

FIG. 1 illustrates a network in which an exemplary embodiment of the present system may be implemented; and

FIG. 2 is a flow chart illustrating the operation of an exemplary embodiment of the present system.

DETAILED DESCRIPTION

The present method and system allows users of software-based, stand-alone equipment to obtain and enter software keys that enable or unlock the equipment's features without a conventional Internet connection. If a user registers a stand-alone device, such as an automotive tester, with the tester's manufacturer, the serial number for the device can be stored in a database maintained by the manufacturer. Corresponding to a serial number, one or more software keys can be generated to unlock features or install new software. Since the software keys are associated with a particular device (by serial number and features to be enabled), they can only be used to enable or unlock a unique device's features. For example, an automotive tester may have an extensive set of features installed even though not all of them are enabled when the tester is first purchased. By allowing users to purchase features (or use them on a limited-time free trial basis), the tester's manufacturer has flexibility in what features are provided to users.

The present system may be used to enable features or update the software of a portable, stand-alone automotive diagnostic device. Such a device may be, for example, Snap-on's MODIS system, which is a modular, ruggedized diagnostic platform that replaces multiple pieces of automotive diagnostic equipment. The MODIS system utilizes the Windows CE operating system and standard PC-based architecture. The MODIS system also includes a VGA port to connect to external monitors, as well as infrared, serial and USB ports and a CompactFlash interface. Any of various ports and interfaces (except the VGA port) can be used for software updates and other communications. For example, software updates may be accomplished by CD-ROM inserted in a standard PC that is connected to the MODIS. Software updates may also be made directly via CompactFlash memory cards. In addition, MODIS may have extensive software features and functionality built-in but inaccessible to users until the users pay for the features.

In addition to the MODIS system, the present method and system is compatible with other types of equipment, such as diagnostic equipment implemented in Personal Digital Assistants (PDAs) and in Snap-on's Automotive Scan Tools such as the MT2500 Scanner and the MTG2500 Color Graphing Scanner. The method and system is also appropriate for use with the Snap-on Vantage Power Graphing Meter, which is a component tester that combines a graphing digital multimeter with a diagnostic database for testing engine-management components, transmission sensors and components, ABS systems, and the like. Moreover, the present method and system is not limited to operation with these noted, exemplary devices, but can instead be employed with a wide variety of devices.

Architecture

In an exemplary embodiment, a system for unlocking software features is implemented in a network, as illustrated in FIG. 1. User's initial requests can be made from telecommunications devices such a telephone 12, that communicate with telephone switch 14. Telephone switch 14 is in turn in communication with voice platform 16, which serves as an interface to network 18. Network 18 can be, or can include, the Internet. A manufacturer's or service provider's server, such as server 20, has access to a manufacturer's enterprise database 22 as well as network 18. Further, the server 20 may be protected from unauthorized access by a firewall (not shown).

Telephone 12 may be either a wireless or landline telephone, or it may be any voice-enabled telecommunications device, such as a Voice-Over-IP device. Telephone switch 14 may be a conventional Public-Switched Telephone Network (PSTN) switch or any other suitable routing or switching device. Voice platform 16 may be, for example, a Nuance Voice Platform manufactured by Nuance Communications, Inc., although voice platform 16 may be any other suitable voice platform. Voice platform 16 may include a “conversation server” that in turn includes a VoiceXML interpreter integrated with speech recognition, text-to-speech, and voice authentication software. Voice platform 16 can accept Dual-Tone MultiFrequency (DTMF), pulse-dialed, or speech input from telephone 12.

The functions performed by server 20 could be implemented with one or more interconnected, commercially available server-class computers such as the Sun Solaris, Dell NT, IBM AIX, or other servers. A server such as server 20 may generally be referred to as an enterprise server, and may also include a memory, a processor, and instructions stored in the memory that are executable by the processor to carry out various functions, including the functions described here. As mentioned above, server 20 is in communication with database 22, which may include a manufacturer's (that is, the manufacturer of a diagnostic device to be unlocked) financial, manufacturing, order processing, and product registration information, and may also include software keys associated with particular products. Database 22 may be part of an enterprise resource planning (ERP) system such as the one developed by BaaN. Other typical ERP systems that could be used include the R/3 enterprise application developed by SAP AG of Walldorf, Germany, as well as those developed by PeopleSoft, and Oracle.

Operation

An owner or user of a diagnostic device may initially purchase the device with an understanding that not all features of the device are enabled, but that some features may be purchased or used on a trial basis at a later time. The user may also realize that diagnostic devices such as the MODIS system can be updated to improve performance and prevent obsolescence. The features can be unlocked by entry of a software key associated with the particular device. As a concrete example, suppose a user purchased a MODIS system, at which time the product was registered. In the example, assume the user chose not to purchase Asian Import Troubleshooting information that could be available to the MODIS system, or that the user chose not to purchase frequency-measuring capability (as another example). Product registration could include the part number and serial number of the device, as well as the owner's business or financial information, or both.

Now suppose the user is working on the transmission of a Honda automobile. The user may take steps to access MODIS' “Asian Import Transmission Fast-Track Troubleshooter” to learn about troubleshooting the particular transmission. Since the information sought is not enabled, however, the requested information could, for example, be “grayed-out,” indicating that it is unavailable. Alternatively, the user may have purchased MODIS prior to the model year of the transmission for which information is sought. In either case, attempting to access unavailable or out-of-date features could result, in addition to a grayed-out menu item, in the display of a telephone support number or website address the user could use to enable the feature. On-screen display of a telephone number is not, however, critical to all embodiments of the present system. For example, a telephone support number or web address could be made available in the original product literature, over the Internet, or permanently displayed on the tool.

In addition to displaying a telephone number, the diagnostic device could also display a unique feature identifier or device identifier that the user could transmit in order to request a software key. If the information on the device is simply out of date, the user might first need to download or install more recent information, which could be made freely available from numerous sources, as discussed above (e.g., Internet, CD-ROM, Flash Memory, and the like).

FIG. 2 is a flow chart of various functions that may be carried out in accordance with the exemplary embodiment to allow the user to unlock the desired information. First, the user could use telephone 12 to call a product support telephone number, as shown in block 30. Voice platform 16, upon receiving a call to the proper product support number could responsively access a specific directory or website within the manufacturer's server 20. The server 20 may transmit XML, VXML, or other code that then directs the voice platform to play an appropriate (according to the dialed number) prerecorded prompt message (or to perform a text-to-speech conversion of a prompt message) that says, for example:

“Welcome to the Snap-on Diagnostics registered products system. Please select your product from the following menu: One, scanners; Two, lab scopes; Three, engine analyzers; Four, component testers (system pauses for response). Please enter your serial number.” The user may also be prompted to select a feature or features that he wishes to enable, as shown at block 32, or there may be only one non-enabled feature or feature set so that selecting a feature is not necessary. The user's input can be either spoken or entered via the telephone keypad or other suitable data entry device. Next, as shown at block 34, the server 20 receives the serial number for a particular product type (for example, category 3 from the user's response to the prompt) and, if applicable, the feature to be enabled. As an alternative, any product-identifying information could be entered in lieu of a serial number. Once the serial number is verified by access to the database 22, the server 20 can either generate a software key for a particular feature or the entire product, or, alternatively, can look up a stored software key corresponding to the serial number.

At block 36, the server 20 can authorize the user. This authorization can comprise receiving a credit card number, for example, or verifying that the owner of the device identified by the user has a preexisting relationship with the manufacturer so that the user can be charged accordingly. Alternatively, the system can respond to software key requests without user authorization if, for example, features are to be unlocked for a free trial period.

At block 38, the software key is transmitted to the user via network 18 and voice platform 16. The software key may be transmitted from the server 20 in VXML (VoiceXML) format so that the voice platform can perform a text-to-speech conversion, shown at block 40, although other text formats, such as HTTP or XML are also possible.

The software key may be a simple alphanumeric such as “98 G” although more or fewer characters could be used. As an alternative to speech, the software key could be sent to users via the Internet, the PSTN, or both, in other formats, such as text-based formats or markup languages, which would enable users to view software keys on handheld devices or telephone text display screens.

Next, as shown at block 42, the user receives the software key that unlocks the applicable features of his particular device. The user can then enter the software key to unlock the features of the device. The software key may be entered by a peripheral component connected to the diagnostic device, such as a handheld PDA or a personal computer, or it may be entered directly by a built-in input device. As an example, the MODIS unit includes a Thumb Pad and selection keys that, in combination, operate much as a computer mouse to allow direct user input. As another alternative, the software key could be “beamed” via infrared link, to the MODIS from a PDA or cellular phone. Other key entry methods can also be used.

The software or feature to be enabled on the diagnostic device can be enabled by entry of the software key. To accomplish this, the software key may be verified by a user key verifier software routine in the diagnostic device. Depending on the level of security required or desired, the enabling routine can verify whether the software key entered matches unique product identifying information, requested feature information, user information, date, and the like. For example, the user key verifier routine could perform an algorithm on the user key to generate a match with the last six digits of a product serial number embedded within a chipset in the diagnostic device. For more security, the verifier routine could restrict feature or update enablement to a certain time period after the key is generated. If less security is required, one or more software keys may enable a group of devices, rather than just one unique diagnostic device. Because a verifier routine can be used, it is not necessary to store valid key data in diagnostic devices at the time of manufacture, although doing so would also be possible. Other methods of key verification are possible.

The present system allows untrained users to update, upgrade, or enable features of stand-alone equipment that may not be (although it could be) connected to the Internet. Further, such modifications can be made using, for example, an ordinary telephone, a cellular telephone, a PDA, or the like. Because an enterprise server and a voice platform as described can work in combination to provide a seamless user experience by dynamically accommodating interactions with a database, little or no human intervention is required to operate the system. In addition, the system can service customer requests around the clock at minimal incremental cost for each transaction. The system is also scalable, in that virtually any service that could be implemented through authorized, automated access to a manufacturer's database, can easily be provided via telephone.

Although several possible embodiments of an apparatus, system, and method has been described, various changes and modifications may be made or suggested by those skilled in the art without departing from the scope of the claims that follow.

Claims

1. A method of modifying a diagnostic device, the method comprising:

receiving, from a user, product-identifying information for the diagnostic device;

transmitting a software key that corresponds to the product-identifying information to a text-to-speech server; and

performing a text-to-speech conversion of the software key to cause the software key to be spoken to the user.

2. The method of claim 1, further comprising entering the software key into the diagnostic device, and wherein modifying the diagnostic device comprises unlocking at least one feature in response to the software key being entered.

3. The method of claim 1, further comprising entering the software key into the diagnostic device, and wherein modifying the diagnostic device comprises enabling a software update in response to the software key being entered.

4. The method of claim 1, further comprising receiving, from the user, payment information.

5. The method of claim 4, wherein the payment information comprises credit card information.

6. The method of claim 2, further comprising receiving, from the user, feature-identifying information corresponding to the feature to be unlocked.

7. The method of claim 1, wherein the product-identifying information comprises a serial number.

8. The method of claim 1, wherein the software key is transmitted to the text-to-speech server in VXML format.

9. The method of claim 1, wherein the software key is transmitted via the Internet.

10. The method of claim 1, further comprising transmitting a prompt to the user requesting the user to specify a diagnostic device type.

11. The method of claim 1, further comprising indicating to the user that a feature of the diagnostic device must be unlocked before it can be used.

12. The method of claim 1, wherein the product-identifying information comprises a DTMF signal.

13. The method of claim 1, wherein the product-identifying information comprises a set of spoken characters.

14. A method of unlocking at least one feature of a diagnostic device, the method comprising:

receiving, from a user, a serial number for the diagnostic device;

receiving, from the user, credit card information;

receiving, from the user, feature-identifying information corresponding to the feature to be unlocked;

generating a software key in response to receiving the serial number and the credit card information, the software key corresponds to the serial number and the feature-identifying information;

transmitting the software key to a text-to-speech server via the Internet;

transmitting the software key from the text-to-speech server to the user in voice format via the PSTN to cause the software key to be spoken to the user; and

entering the software key into the diagnostic device to unlock the at least one feature.

15. A system for providing a software key to a user comprising:

a voice platform;

a diagnostic device database comprising identifying data for particular diagnostic devices and further comprising feature data for particular diagnostic devices;

an enterprise server comprising a processor and a memory, the enterprise server being communicatively connectable to the voice platform and the diagnostic device database; and

a set of machine instructions stored in the memory, the instructions being executable by the processor to: receive at least one input requesting a software key for a particular diagnostic device; verify the particular diagnostic device by reference to the database; and transmit a software key in a markup language to the voice platform;

wherein the voice platform converts the markup language software key to voice format and transmits it to the user.

16. The system of claim 15, wherein the set of instructions are further operable to generate a software key that is associated with the particular diagnostic device.

17. The system of claim 16, wherein the software key only enables the particular diagnostic device and no other diagnostic device.

18. The system of claim 15, wherein the markup language is VXML.

19. The system of claim 15, wherein the software routine is further executable to identify a particular feature to be enabled, the particular feature being associated with the particular device.

20. The system of claim 19, wherein the enterprise server receives information regarding the particular feature to be enabled from the user via the voice platform.

21. The system of claim 19, wherein the software key only enables the particular feature.

22. The system of claim 21, wherein the software key further only enables the particular device.