SYSTEM AND METHOD FOR DIGITAL DATA PROCESSOR DIAGNOSTICS
Background of the Invention
The invention pertains to digital data processing and, more particularly, to the diagnosis and correction of faults in digital data processing software and hardware. The invention has application in, among other things, rapidly and cost-effectively resolving problems (and apparent problems) experienced by personal computer hardware and software users.
Personal computer systems are notoriously difficult to set up and upgrade. Though a basic system may be assembled and easily run "out ofthe box," adding further hardware and software remains quite difficult. This often frustrates users, leading them to rely on the manufactures technical support to diagnose and solve even rudimentary problems. According to the market-research firm Dataquest, Inc., technical support calls cost on average $20 - $100, accounting for 3.5% of a personal computer costs; see, "PC Makers Cure Customer Ills with Virtual House Calls," Wall Street Journal. March 21, 1995. Dataquest found that the average length ofthe technical support calls and the number of those calls have increased 20% per year over the past two years. Id. To account for this volume, at least one large personal computer manufacturer has boosted its technical support staff to over 1800.
U.S. Patent No. 5,367,667 suggests one way to reduce the time and costs of technical support calls. On receiving a telephone call from a user, a technical support staff person creates a batch file for executing diagnostic tests already present on the user's computer. The technical support center accesses the user's computer remotely, by modem, and downloads that batch file. On execution, the selected test programs run and generate log files, which are subsequently transmitted back to the technical support center. The technical support staff person reviews the log files and suggests possible solutions to the user by phone, downloading new files as necessary by modem.
On another front, an industry trade journal reports that manufacturers and publishers are increasingly relying on remote control access software to aid in diagnosing and resolving user's computer problems; see, "Technical Support Hits the Road," PC Week. July 25, 1994. IBM Personal Computer Co., for example, is said to bundle Triton Technologies' CO-SESSION
software with its portable computers. This is said to enable the IBM technical support staff to access a user's computer remotely and to reconfigure DOS initialization files such as CONFIG.SYS.
In view ofthe foregoing, an object of this invention is to provide improved systems and methods for diagnosing and correcting faults in digital data processing apparatus.
A further object is to provide such systems and methods to reduce users' need for technical support, thereby, to reduce users' frustrations and manufacturers' costs.
A still further object is to provide such systems and methods as can be readily implemented and adapted for use on an array of computer systems. Still another object to provide such systems and methods as can be easily upgraded, thereby, permitting diagnosis and corrections of problems caused by newly released products, as well as newly identified problems in previously released products.
Summary of the Invention
The foregoing and other objects are attained by the invention which provides, in one aspect, a system for remote diagnostic of a digital data processor, e.g., a user's home or office computer. The system includes a local diagnostic element coupled with the digital data processor that determines the status ofthe computer and that diagnoses a first set of problems. The local diagnostic element can be, for example, a software package resident on the digital data processor that gathers information about the hardware and software components ofthe digital data processor and that analyzes this information using expert software. When the problem cannot be identified locally, a remote communication element, e.g., a modem, permits the local diagnostic element to transmit the status information to a diagnostic element disposed at a remote site.
The remote diagnostic element, which can be a computer residing at a manufacturer's, publisher's or reseller's technical support center, responds to the received status information for diagnosing a further or broader class of problems, e.g., using its own expert system software.
According to other aspects ofthe invention, the remote diagnostic element can retransmit status information to a technical support interface in the event that it (the remote diagnostic element) is unable to diagnose or correct the problem. The technical support interface conveys at
least portions ofthe status information to a human operator, e.g., a staff member at the technical support center, for diagnosis of still further or broader classes of problems.
The local and remote diagnostic elements can apply instrumentation to the digital data processor in order to gather information necessary to identify problems. Whereas the local diagnostic element can apply that instrumentation directly to the digital data processor, the remote diagnostic element applies it remotely, e.g., via modem. The instrumentation can be software routines for testing specific aspects ofthe state and operation ofthe digital data processor, e.g., the status of CPU registers during selected machine operations.
In still other aspects, the local and remote diagnostic elements are capable of reconfiguring the digital data processor to correct identified problems. This can include, for example, altering configuration files or upgrading software (such as Window™ drivers). Again, whereas the local diagnostic element can make those corrections directly to the digital data processor, the remote diagnostic element makes them remotely, e.g., via modem. The technical support interface likewise permits the human operator to apply corrective measures, e.g., via modem, and to directly control the digital data processor, e.g., using remote control software.
In yet another aspect ofthe invention, the local diagnostic element can be invoked by the user's selection of an "error diagnosis" or "help!" icon on the screen. This aspect ofthe invention has particular applicability where the digital data processor is equipped with a functioning graphical user interface, such as Windows ™. Still other aspects ofthe invention provide methods of remote diagnosis paralleling the operations described above.
These and other aspects ofthe invention are evident in the drawings and in the text that follows.
Brief Description of the Drawings
Figure 1 illustrates a system for remote diagnostics according to the invention;
Figure 2 illustrates the functional components of a local diagnostic element according to the invention; Figure 3 illustrates decision nodes and action leaves used by an expert system according to the invention;
Figure 4 illustrates how the procedure call bindings to the DLL file are declared in a problem-solution database according to the invention;
Figure 5 illustrates the construction and operation of a remote diagnostic element according to the invention;
Figure 6 illustrates the interconnection ofthe remote diagnostic element to the support engineer's workstation in a system according to the invention;
Figures 7 - 9 chart the operational flow ofthe local diagnostic element;
Figure 10 - 11 chart the operational flow ofthe remote diagnostic element. Detailed Description of Illustrated Embodiment
Figure 1 illustrates a system 5 for remote diagnostics according to the invention. The system includes digital data processors 10, 12, 14 interconnected for remote communications, e.g., via modems 16, 18, 20 and telecommunications equipment 22, 24, 26. The digital data processors 10, 12, 14 comprise conventional commercially available computing systems programmed in accord with the teachings herein. Digital data processor 10, for example, can be a personal computer or workstation that resides at a user's home or office. Digital data processor 12 can be a more powerful workstation residing at a manufacturer's, publisher's or reseller's technical support center. Digital data processor 14 can be a technical support person's 31 workstation at the technical support center. In the illustrated embodiment, the digital data processors 10 - 14 can operate under the
Window™ or Windows 95™ operating systems, as well as other operating systems. The rerαote communications equipment, which in the illustrated system utilizes modulated communications over the telephone lines, can comprise any other conventional techniques for remote communications, such as local area networks, wide area networks, or the Internet.
The system 5 includes a local diagnostic element that is coupled with digital data processor 10 for determining the status of that computer and for diagnosing a first class of problems thereon. The local diagnostic element is, preferably, a software package resident on the digital data processor 10 that executes on that computer to gather infoπnation about its hardware and software components and that analyzes that information using an expert system ofthe type described herein.
The functional components ofthe local diagnostic element are illustrated in Figure 2, where there is shown an expert system 30, a front end 32, expert system databases 34, 36, 38 and a remote interface 40. The local diagnostic element 28 is invoked at the user's request, e.g., via invocation of a menu option or icon, or automatically, e.g., in response to operating system error handling system messages (such as a "printer communications error").
User interface element 32 serves as an interface between the user and the expert system 30. It displays "icons" that graphically depict components ofthe digital data processor 10 and that respond to user selection, e.g., via "clicking" of a mouse button, for alerting expert system 30 of a component, or components, to be diagnosed. Alternatively, the user interface element accepts and interprets text input by a user that describes a problem. Such interpretation can be done, e.g., via keyword scanning or via natural language recognition techniques.
Once the problem area has been identified, the expert system 30 applies conventional expert system techniques, using information contained in the databases 34 - 36, to diagnose problems in the selected components ofthe digital data processor 10. In the illustration, database 34 contains information regarding problems and solutions concerning Windows 95™; database 36 contains information regarding problems and solutions concerning any CD-ROM devices that may be attached to the digital data processor 10; and database 38 contains information regarding problems and solutions concerning any sound card that may be attached to the digital data processor 10. As evident in the discussion below, further databases containing other information regarding other problems and solutions are provided as well. The databases 34 - 38 are formatted and accessed in a manner conventional to expert systems, as further discussed herein.
To facilitate diagnosis of problems, the expert system 30 applies "instrumentation" to the digital data processor to test its responses under specified conditions. These tests are contained within the databases 34 - 36, as well as in the expert system 30 itself. In a preferred embodiment, executing under Windows 95™, the instrumentation modules are implemented as dynamic linking
libraries, or DLLs. A standard DLL provides a library of calls to allow each problem-specific database 34 - 38 to ascertain information about the digital data processor 10, e.g., to parse and edit files thereon. The databases 34 - 38 contain instrumentation specific to the hardware or software under test. Further instrumentation can be supplied in DLLs or VxDs (virtual device drivers) generated by the user or, preferably, by third parties.
The remote interface 40 serves as the remote communications manager for the local diagnostic element 28. The interface 40 is responsible for hooking up to the remote diagnostic element via conventional communications medium, e.g., modem link, wide area network, and Internet. Expert System 30
The expert system 30 operates using a search engine utilizing conventional expert system techniques, such as, decision trees, case-based reasoning, pattern matching, or decision theoretic. In the illustrated embodiment, the expert system 30 is a decision tree system ofthe type available from NASA and Attar Software, among others. Those skilled in the art will appreciate that different types of expert systems may be used alone or in combination with others, with selection based on the predefined requirements ofthe problem-solution database.
The problem-solution database contains the decision graph which is executed by the expert system 30. This graph contains complete diagnostics for one subsystem ofthe digital data processor 10 hardware or software. For instance, if digital data processor 10 contains a system unit (e.g., CPU, memory and disk controller), VGA video board, sound card, CD-ROM, keyboard and mouse, the expert system 30 will maintain six problem- solution databases to represent the digital data processor's status. In addition, the expert system 30 can include a generic knowledge base to facilitate basic fault-finding and correction in the overall digital data processor 10. Three such databases are shown as elements 34 - 38 in Figure 2, above. As users add further hardware and software subsystems, the expert system 30 adds new databases to allow diagnostics to be run on those subsystems. By maintaining separate problem-solution databases for each subsystem, a local diagnostic element according to the invention is easily updated as new problem-solving information becomes available, e.g., by way of updates from the manufacturer, publisher or reseller.
Each problem-solution database (e.g., 34 - 38) is a combination of two common data structures a graph data structure and a tree data structure. The expert system 30 traverses the resulting data structure, referred to herein as a "decision graph" data structure to identify problems in the digital data processor and their solutions. As those skilled in the art will appreciate, a decision tree generally consists of a "head" node that is connected to two leaf nodes. Decisions systems typically traverse such trees based on "TRUE" or "FALSE" evaluations at the leaves. The decision graph used herein is modified from the conventional decision tree. Though a head node in the decision graph ofthe present system can be connected to any number of other nodes, it cannot cause the decision process to flow to a prior, or parent nodes ("upward flow").
Referring to Figure 3, in local diagnostic element 28, there are two types of nodes: a "decision node" 42 - 46 and an "action leaf' 48. A decision node is a point where a question is posed (e.g., regarding the status ofthe digital data processor 10) and from where execution flows based on the answer to that question. An action leaf is a point at which a diagnosis ofthe problem has been made and an action can be taken to correct the problem. Once the expert system 30 has executed an action leaf, the problem is treated as solved.
The decision nodes 42 - 46 include functionality for invoking programs, i.e., "instrumentation," that carry out tests on the digital data processor 10 and that return information that facilitates further diagnosis. That instrumentation can be contained in Windows 95™ Dynamic Link Libraries that, in turn, call Virtual Device Drivers to interrogate the subsystems. This permits the expert system 30 to obtain more information about the digital data processor 10, e.g., information not otherwise available under the Windows 95 memory management scheme.
The expert system 30 can take advantages ofthe local computer architecture during interrogation of the hardware and/or software using the instrumentation. For example, although the preferred mechanism to get I/O port information under Windows 95™ is to use the
Microsoft/Intel/Compaq Plug N' Play (PnP) specification, this is not effective on systems that do not support PnP. On those systems, the expert system 30 obtains the I/O port information by directly scanning the system, and noting which I/O ports are in use. By allowing the instrumentation to work on the exact mechanics of getting the information, the expert system 30 does not have to address those details and, therefore, can be written more clearly and can operate
more efficiently. The instrumentation can be adapted to handle different specifications including Desktop Management Interface (DMI), PnP, Registry etc.
In certain circumstances, the information that expert system 30 needs to proceed with diagnosis is only available from the user. In this case, the decision node utilizes the user interlace 32 to display a dialog box and prompt the user for a response. This response is the returned to the expert system.
Installing and Registering Databases
Prior to invoking the expert system 30, the problem-solution databases 34 - 38 must first be registered. This can be done by a third party installation program (for example, the problem- solution databases 34 - 38 can be installed as part ofthe installation of applications software or hardware devices, such as Quicken™, Seventh Guest™, SoundBlaster™, etc.) which copies the problem-solution database onto the hard disk, and passes information about the database to local diagnostic element 28. This includes information identifying the subsystem to which the database pertains, as well as a bitmap file (.BMP) with a graphic identifying that subsystem. This file is, in turn, used by the local diagnostic element 28 as an icon that the user can select to identify a problematic subsystem. In the case of a software product, the bitmap file is the conventional icon for that software.
The installation program registers the database by modifying the local diagnostic element 28 initialization file, e.g., a standard Microsoft Windows™ ASCIII initialization file, or by modifying the registry provided with Microsoft Windows 95™. A section of such an initialization file is shown below. For each subsystem, the installation program adds a new section following the "[database]" section. The naming convention is the name ofthe problem-solution database in brackets. This new section specifies information about the file itself. This includes information about the manufacturer ofthe product, any VxD/DLLs required, remote, diagnostic element access numbers and the X, Y location ofthe graphic. Additional information can optionally be attached to this section ofthe initialization file for use by the problem-solution database,
[database]
KB=C:\SYSTEMWIZARD\SOUND.PDB, 12,C:\SYSTEMWIZ ARD\SOUND.BMP
[SOUND.PDB] DLL=SNDDIAG.DLL
Manufacturer=REVEAL Sound Card LocateX = 45 LocateY=75 VXD=None remote diagnostic elementTel=508-651 -6705
In many cases, a problem-solution database 34 - 38 requires the expert system 30 to do a custom call specific to the hardware/software under test. This custom code may be instrumentation to return information to the expert system or code that may reset configuration of the device under test. The custom code are created and stored in a separate DLL file. As shown in Figure 4, the procedure call bindings to the DLL file are declared in the problem-solution base. The expert system interpreter creates a large symbol table where these binding are stored and looked up as they are called from the problem-solution database.
Remote Access
In many cases the expert system 30 ofthe local diagnostic element 28 will not find a solution to a problem. This can occur if the expert system 30 has an invalid value or unknown value at a decision node and the traversal cannot continue, or if an action node explicitly calls for additional help from a remote diagnostic element present on remote digital data processor 12, which has larger and richer databases than those available on the local digital data processor 10. In these cases, the local diagnostic element 28 contacts a the remote diagnostic element, e.g., via modem 16 and communications equipment 22, coupled to the remote digital data processor 12. In addition, the local expert system 30 can request that the remote diagnostic element download new files, e.g. software updates or new problem-solution databases.
By passing information to the remote diagnostic element or by requesting information from it, the remote diagnostic element 50 resolves a second class of problems that the user is
encountering. This second class of problems can be distinct from the aforementioned first class but, preferably, is simply a larger inclusive class.
Where the local digital data processor runs under MircoSoft Windows 95™, the information passed to the remote diagnostic element 50 includes the files: SYSTEM.INI, WIN.INI, the Registry, AUTOEXEC.BAT and CONFIG.SYS. It also includes user identification information, hardware identification information, I/O address information, and IRQ Information. It also includes information gathered by the local diagnostic element (e.g., directly from the user or via the instrumentation) regarding the symptoms and characteristics ofthe specific problem to be solved. In the illustrated embodiment, the local diagnostic element 28 uses a modem link to connect to the remote diagnostic element Server. Alternatively, this link can be over the Internet, Infrared (IrDA), ISDN link or other communications links, instead of a phone link. The serial communications is provided by a conventional communications package, e.g., COMM-DRV VxD available from Willies Software Corp. This package allows full file uploading/downloading and actual commumcations protocol handling between the two systems. Encryption and data compression can be included into the data link as appropriate.
Referring to Figure 5, the remote diagnostic element 50 is constructed and operated similarly to local diagnostic element 28. It includes remote communications devices 52, such as modem 18 and telecommunications equipment 24 (Figure 1). In addition, it includes a remote commumcations engine 54, an expert system engine 56, problem-solution rule bases 58 and problem- solution databases 60.
The remote communications engine, which serves an analogous role to the user interface 32, serves as an interface between the remote diagnostic element 50 and the local diagnostic element 28 for communicating information therebetween. The expert system 56 can operate identically to expert system 30, albeit in connection with databases 58 and 60. Databases 58 and 60 correspond to databases 34 - 38, though they contain more problem identification and solving information than those resident on the local digital data processor 10.
In the illustrated embodiment, the remote digital data processor 12 is connected to a bank of modems (e.g., modem 18) which are set on auto-answer mode. These modems are set to answer the incoming calls from local diagnostic elements 28 in the field. Other embodiments of
-l i¬ the remote digital data processor 12 can support network Links (LAN, WAN, or Internet) to the local diagnostic elements 28.
Once the calls have been answered, the remote diagnostic element 50 exchanges infoπnation regarding the identity ofthe person calling. Once this item has been completed the remote diagnostic element 50 asks the local diagnostic element 28 to upload the packet of information regarding the user's problem.
As the remote diagnostic element 50 expert system traverses the decision graph in a similar manner to that described above, it may encounter decision nodes that require it to download information to local diagnostic element 28. Using the same communications link, the remote diagnostic element 50 downloads a DLL containing information to local diagnostic element 28. The local diagnostic element 28 executes this instrumentation and returns the result back to remote diagnostic element 50. Similarly if remote diagnostic element 50 requires a user to answer a question, it downloads the question to local diagnostic element 28 and awaits the answer. The remote diagnostic element 50 program has several options at the action nodes. It can download new software to local diagnostic element 28 that can solve the user's problem; update the necessary system files and download the file back to local diagnostic element 28 or if it encounters a problem that is does not know, it passes control to the engineer 31.
Once the diagnosis is made by remote diagnostic element 50 it can download to local digital data processor 10 information necessary to correct the problem. For example, the remote diagnostic element can make changes to SYSTEM INI and download it to the local digital data processor 10 if the problem is a configuration problem. If the problem requires new software or a software patch, a new file along with an installation program is downloaded. The installation program is started to allow the software to be automatically installed in the system. If remote diagnostic element 50 cannot diagnose the problem, the phone link is passed to a customer support engineer 31 at the call center. Referring to Figure 1 , that engineer 31 receives information from the remote diagnostic element 50 via a communication link (e.g., modem 20 and telecommunications equipment 26, or network), either from the remote diagnostic element or from the local diagnostic element. The information is displayed and analyzed via digital data
processor 14, which the engineer can use to download information to, or control, the digital data processor 10 via modem 20 and telecommunications equipment 26
The remote digital data processor 12 can be a conventional personal computer running the Windows 95™ operating system. Preferably, however, it is a high performance workstation that runs a multitasking operating system, such as, Microsoft Windows NT.
Engineer Intervention
Engineer intervention is the final tool in the chain to solve the user's problem. Referring to Figure 6, if the remote diagnostic element 50 cannot solve the problem, it transfers responsibility for the support call via central PBX 62 to the technical support engineer 31 to look at the user's problem The remote diagnostic element 50 can simultaneously place information regarding local digital data processor 10 on a central server 64 Software running on the support engineer's personal computer 14 retrieves that information from the central server. The modem 20, connected to PC 14, is used to directly connect the engineer's PC to the local digital data processor 10 More particularly, once it has been established that the call is to be handled by support engineer 31, under command control (e.g., via TAPI protocol) remote diagnostic element 50 initiates a sequence of steps to transfer a call. It first places all the information about the subject on a central file server to which all engineer's PCs 14 are connected The remote diagnostic element 50 then sends a TAPI command to the PBX to transfer the call to an engineer. The PBX transfers the call to the next available engineer who's modem synchronizes with the remote diagnostic element 50 The remote engineer's PC 14 is now in control. The support engineer's PC 14 retrieves information from the central file server for information regarding the local diagnostic element 28 call.
The engineer 31 can instruct can take direct remote control ofthe user's PC 10 This allows the support engineer 31 to manually inspect the user's PC and fix any configuration problems This control is similar to that provided by conventional remote control programs, e g., Microcom's Carbon Copy™ or Stac's Reach Out™. However, the software resident on the PC 14 and the local diagnostic element 28 facilitate the uploading ofthe information already gathered by the local and remote diagnostic elements and the downloading of new software to the local
diagnostic element 28. Preferably, the software resident on the engineer's PC uses the Intel product App Sharing™ from that company's ProShare Video Conferencing package.
A more complete understanding ofthe operation ofthe local diagnostic element 28 may be attained by reference to the flow charts of Figures 7 - 9, while that of remote diagnostic element 50 may be attained by reference to the flow charts of Figure 10 - 11.
Described above are methods and apparatus for remote diagnostics of a digital data processor meeting the objects ofthe invention. Those methods and apparatus reduce users' need for technical support, thereby, to reduce users' frustrations and manufacturers' costs. Moreover, they can be readily implemented and adapted for use on an array of computer systems. Still further they can be easily upgraded, thereby, permitting diagnosis and correction of problems caused by newly released products, as well as newly identified problems in previously released products.
It will be appreciated that the embodiments described above are merely examples ofthe invention and that other embodiments incoφorating modifications therein are contemplated to fall within the scope ofthe invention. For example, it will be appreciated that the invention can serve to optimize a digital data processor configuration using the mechanisms described above. By way of further example, the local diagnostic element, remote diagnostic element or engineer can present information to the user to educate him or her as to problem resolution. In view ofthe foregoing, what I claim is: