Abstract:
A method of providing a software application to different network clients from a server including maintaining one or more sets of state data, each set of state data describing the state of an instance of an application, each instance of an application corresponding to one or more network clients, updating the sets of state data in accordance with applications running on one or more computers connected to the server via a local area network and for at least one of the sets of state data generating an interface based on the set of state data and transmitting the generated interface to the corresponding network client(s).

Description:
PRIORITY CLAIM 
   This application relates to the following applications U.S. Ser. No. 09/603,368, entitled “Virtual Patient Hot Spots”, filed Jun. 26, 2000, now U.S. Pat. No. 6,747,672; U.S. Ser. No. 09/603,045, entitled “Patient Simulator”, filed Jun. 26, 2000, now U.S. Pat. No. 6,692,258; U.S. Ser. No. 09/603,422, entitled “Morphing”, filed Jun. 26, 2000, now U.S. Pat. No. 6,972,775. 

   REFERENCE TO RELATED APPLICATIONS 
   This application relates to the following applications U.S. Ser. No. 09/603,368, entitled “Virtual Patient Hot Spots”, filed Jun. 26, 2000; U.S. Ser. No. 09/603,045, entitled “Patient Simulator”, filed Jun. 26, 2000; U.S. Ser. No. 11/195,905, entitled “Morphing”, filed Aug. 3, 2005. 
   BACKGROUND 
   Desktop computer programs such as flight simulators, word-processors, and spreadsheets quickly respond to user input. Providing this kind of inter-activity over the Internet, however, has posed something of a challenge. This challenge stems, in part, from the simple communication model that describes most Internet traffic: clients (e.g., web-browsers) request pre-written web pages from servers, and the servers send the requested pages back for display. 
   Programmers have developed a number of different techniques to make web pages more inter-active. For example, some web pages include, or refer to, programs known as “applets.” When a browser receives a web-page featuring an applet, the browser executes the applet instructions, for example, to receive user input, change a browser GUI (Graphical User Interface) display, and communicate with the server providing the web-page. Some applets, however, include a large number of instructions and can require a significant amount of time to travel over the Internet to a user&#39;s browser. 
   Another technique for making web pages more responsive to users involves dynamic generation of web pages by servers. For example, PHP (Personal Home Page), ASP (Active Server Page), and CGI (Common Gateway Interface) scripts can dynamically produce a web page based on script instructions and variables. Script processing, however, adds yet another task to web-servers faced with handling large bursts of browser requests for information. 
   SUMMARY 
   In an aspect, the invention features a method of providing a software application to different network clients from a server including maintaining one or more sets of state data, each set of state data describing the state of an instance of an application, each instance of an application corresponding to one or more network clients, updating the sets of state data in accordance with applications running on one or more computers connected to the server via a local area network and for at least one of the sets of state data generating an interface based on the set of state data and transmitting the generated interface to the corresponding network client(s). 
   In another aspect, the invention features a method of providing a virtual patient software simulator to different Internet web-browser clients from an Internet server, the method including maintaining one or more sets of state data, each set of state data describing the state of a virtual patient, updating the sets of state data in accordance with virtual patient simulators running on one or more computers connected to the server via a local area network and
         for at least one of the sets of state data dynamically generating HTML (Hypertext Markup Language) instructions for an web-browser based on the set of state data and transmitting the generated interface to a networked web-browser client.       

   Advantages of the invention will become apparent in view of the following description, including the figures, and the claims. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIGS. 1 to 5  are diagrams illustrating a network application architecture. 
       FIG. 6  is a flowchart of a server process for providing an application to different network users. 
       FIG. 7  is a flowchart of a client process for presenting a user interface to network users. 
       FIGS. 8-14  are screenshots of a user interface that presents a virtual patient. 
       FIGS. 15A and 15B  are listings of statements associating multimedia files with different virtual patient characteristics. 
       FIG. 16  is a flowchart of a process for providing a virtual patient. 
       FIG. 17  is a diagram of a virtual patient simulator. 
       FIG. 18  is a flowchart of a process for evolving a medical condition. 
       FIG. 19  is a listing of statements defining an evolution. 
       FIG. 20  is a listing of statements defining a migration. 
       FIG. 21  is a flowchart of a process for changing multimedia presentations associated with a virtual patient. 
       FIG. 22  is a diagram illustrating a change of a multimedia presentation associated with a virtual patient. 
       FIG. 23  is a flowchart of a process for morphing a virtual patient. 
       FIG. 24  is a listing of statements defining a morphing operation. 
       FIG. 25  is a flowchart of a process for providing virtual patient responses to questions. 
       FIG. 26  is a listing of statements defining virtual patient answers to questions. 
       FIG. 27  is a listing of statements defining a response to a lab test. 
       FIG. 28  is a listing of statements defining an action. 
       FIG. 29  is a listing of statements defining a response to physical examination. 
       FIG. 30  is a listing of statements defining a computation. 
       FIG. 31  is a diagram of a virtual patient simulator using the network application architecture. 
   

   Like reference symbols in the various drawings indicate like elements. 
   DETAILED DESCRIPTION 
   A. Introduction 
     FIG. 1  shows a system  100  that uses the Internet  104  as a vehicle for providing complex, interactive applications to a large number of network users operating ordinary web-browsers  102   a ,  102   b  (e.g., Microsoft™ Internet Explorer™). The architecture  100  provides each user with a different “instance” of the application. That is, each user perceives an application program responsive to that user&#39;s input, much like an ordinary program residing on the user&#39;s personal computer. In the scheme shown in  FIG. 1 , the web-browsers  102   a - 102   b  need not receive the actual application instructions, but instead receive interface instructions for constructing a browser display and presenting different user interface controls. The interfaces are like application facades with the real application instructions residing on a remote system. 
   As shown in  FIG. 1 , the system  100  includes a network server  106  that stores the “state”  112  of each application instance. State data  112  can include the current values of different variables used by an application. A single application can handle more than one “instance.” For example, an application can read an instance&#39;s state data  112 , perform some processing, update and store the instance&#39;s state data  112 , and move on to another instance&#39;s state data. 
   Conceptually, state data  112  represents the intersection between local area network computers  118   a - 118   c  running different copies of an application  120   a - 120   d  and a process  108  that dynamically constructs web pages for each application instance. Applications  120   a - 120   d  continually operate and update the state data  112 . Independently, the server  106  can process user input and prepare browser instructions (e.g., HTML (Hypertext Markup Language)) for each instance. 
   For example, in one embodiment, the applications  120   a - 120   d  provide users with a simulation of a patient medical exam (i.e., simulation of a medical exam to a “virtual” patient). The simulation enables network users to interact with web-page controls (e.g., buttons, icons, and text fields) to examine, diagnose, and attempt to return a virtual patient to health. For this application, the state data  112  can include a virtual patient&#39;s vital signs (e.g., heart rate, pulse, and weight), images or references to images of the virtual patient&#39;s current appearance, medical orders and queries received from the user, and other information. The medical simulation applications  120   a - 120   d  continually update the state data  112  for a patient to reflect the virtual patient&#39;s health. For example, the medical simulation applications  120   a - 120   d  may slowly decrease a virtual patient&#39;s weight over time when a user prescribes a diet. While the medical simulation applications  120   a - 120   d  run behind the scenes, an interface generator  110  uses the state data  112  to construct browser instructions that display an appearance of the user&#39;s virtual patient and provide information (e.g., a medical history) requested by the user. 
   The network system of  FIG. 1  can handle the large numbers of users that typically visit popular web sites. For example, pooling the computational resources of the LAN computers  118   a - 118   c  enables the system  100  to support a large number of application instances. Additionally, the system  100  enables a network administrator to add computers to a local area network to further increase system “horse-power”. Additionally, the server  106  does not need to deliver copies of the application  120   a - 120   d  to each network user. This can reduce network traffic. Keeping the application instructions on local area network machines also enables a site manager to easily replace and modify the applications, for example, to fix bugs or provide new features. This also prevents users from easily copying the programs. The system  100  also separates interface generation (server  106 ) from the actual “number crunching” (i.e., execution) of the application  120   a - 120   d . This separation enables the server  106  to easily customize each user&#39;s interface. For example, more sophisticated computers or computers featuring faster network connections can receive interface instructions for more elaborate multimedia presentations. 
   B. Illustration of Operation 
     FIGS. 2-4  illustrate operation of the system  100 . In  FIG. 2 , a user navigates browser  102   a  to the server  106 , for example, by specifying the server&#39;s URL (Universal Resource Locator) (e.g., www.medicalsimulator.com). In response, as shown in  FIG. 3 , the server  106  initializes state data  112  for a new application instance. Initializing the state data  112  may include generating an identifier for the instance, for example, an identifier based on the IP (Internet Protocol) address of the user. The server  106  also selects an application  120   a - 120   d  to handle the instance. For example, the server  106  may select a particular application  120   a - 120   d  based on the current load of the different applications (e.g., load-balance based on how many different instances each application currently handles), the speed of the local area network computer running the application, and so forth. 
   As shown in  FIG. 4 , after initialization, communication with the user and execution of the application can proceed independently of one another, for the most part. For example, an application  120   b  can read and update state data  112  regardless of how frequently the server  106  transmits or receives data from application  120   a . Thus, even if a user directs their browser to a different site, the application instance can persist and, potentially, continue. To continue the patient simulation example, even though a user visits a different site to check on stock prices, their patient&#39;s ailment will progress. The system does not strictly impose this independence. For example, the server  106  can control the application speed based on the speed of a users connection or how frequently the user interacts with an interface. The server  106  can also store the state data  112  to freeze an application instance for later use. 
   The server process  108  that handles user interaction can communicate with the “back-end” via the server  106  database  112 . For example, the process  108  and application  120   b  can communicate using a technique known as “handshaking.” Thus, a user may interact with an interface control (e.g., a form field on an HTML page) displayed by their browser to send user input to the server  106 . The server  106  can write this input into the state data  112  for the user&#39;s application instance and set a handshake flag indicating the input requires application  120   b  processing. After the application  120   b  finishes its processing it can reset the handshake flag. The interface generator  110  may wait for the application  120   b  to reset the handshake flag before constructing a new interface. 
   State data  112  may be distributed across different LAN computers  108   a - 108   c  instead of residing solely on the server  106 . For example, as shown in  FIG. 5 , each application copy may maintain information for each instance locally. The interface generator  110  can retrieve the state data  112  from the LAN computers when constructing an interface. 
   C. Client/Server Operation 
     FIG. 6  shows a flowchart of a server operation  130 . As shown, the server identifies  132  different applications running on the LAN computers. For example, the server may run a process or thread that establishes a connection (e.g., a “socket” connection) with each application that announces itself to the server. Though shown in  FIG. 6  as initial activity of the server, identifying  132  available applications on the LAN computers can continue over time as different applications and LAN computers go on and off-line. 
   After receiving  134  a request from a user for an instance of an application, the server  106  selects  136  an application to handle the instance and initializes  138  the state data for that instance. Thereafter, the application can read and/or update the state data, for example, by issuing database commands over an ODBC (Open Database Connectivity) connection. The server also uses the state data to generate interface instructions that control the appearance of the application on a user&#39;s browser  142 ,  144 . 
   The server  106  can construct an interface using a variety of techniques. For example, the interface generator can use PHP (Personal Home Page), ASP (Active Server Page), or CGI (Common Gateway Interface) scripts to dynamically generate HTML or XML (Extensible Markup Language) interface instructions. Typically, these pages will include instructions that read state data for an instance (e.g., by looking up the instance identifier), and, based on the state data values, construct a page of sounds, graphics, and user interface controls. The user interface controls may include “form field” controls and/or a “submit” button that receives user input and transmits  146  this input to the server for processing (e.g., www.medicalsimulator.com? action=CPR). The interface may also include instructions that periodically issue a request to the server  106  for an update. 
   As shown in  FIG. 7 , a browser (or other client) receives and processes the generated instructions or data  152  to present the specified pictures, text, or sounds to a user. Though the browser receives discrete sets of web-page instructions, the resulting sequence of displays is nearly indistinguishable from that of an ordinary desktop application. The instructions may also feature applets  154 , ActiveX controls, or other programmatic instructions. These instructions can provide fast, direct updating of multimedia elements of an interface. For example, instead of requesting reconstruction of an entire new set of interface instructions, an applet may establish a JDBC (Java Database Connectivity) connection to the data stored on the server  106  and continually replace an image on the interface with a new image. For example, the applet may quickly present a series of images of a patient when the patient&#39;s health rapidly improves. 
   The system  100  described in  FIGS. 1-7  can be used to provide a wide variety of applications. For example, the system  100  can be used to provide a simulation of a virtual patient to different users on the Internet. 
   Embodiments 
   The techniques described here are not limited to any particular hardware or software configuration; they may find applicability in any computing or processing environment. The techniques may be implemented in hardware or software, or a combination of the two. Preferably, the techniques are implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code is applied to data entered using the input device to perform the functions described and to generate output information. The output information is applied to one or more output devices. 
   Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. 
   Each such computer program is preferable stored on a storage medium or device (e.g., CD-ROM, hard disk or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described in this document. The system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner. 
   Other embodiments are within the scope of the following claims. 
   The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. 
   A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.