Integrated application management system
A method and system for coordinating the simultaneous execution of computer programs on a computer system. A set of key events that describe certain states and conditions that can be generated during execution of the computer programs are stored in a database, along with a set of commands for each computer program that can be accepted and executed by that computer program in response to each of the key events. When a computer program generates a state or condition during execution that corresponds to a key event, the computer program sends a notification of the occurrence of the key event to a coordination module. The coordination module then retrieves from the database the commands to be executed by each of the computer programs, and sends the retrieved commands to the computer programs for execution.
Latest Micron Technology, Inc. Patents:
The present invention relates to application program interoperability and, in particular, to a user configurable program that manages concurrently-executing application programs.
BACKGROUND OF THE INVENTIONThe personal computer (“PC”) has, during the past decade, evolved into a useful and relatively usable electronic home appliance. The increasing usefulness of PCs in the home has arisen both from the development of powerful application programs like, for example, graphics-oriented word processing applications and Internet browsers, as well as from an increased connectivity to, and compatibility with, other common household electronic appliances, including telephones, answering machines, fax machines, CD players, and televisions. The PC is thus evolving into a central management device for managing operations of many types of consumer electronic devices, as well as providing a powerful computational platform on which sophisticated consumer-oriented application programs can be run. The increasing usability of PCs has arisen from the adoption by both operating systems and application programs that provide user-friendly, graphical user interfaces. Users are now able to launch and control sophisticated programs using mouse and minimal keyboard input to simple and uniformly presented graphical displays comprising graphical pushbuttons, pull-down menus, and other easy to use graphical controls.
Numerous separate application programs that interface to, and control, external peripheral devices have become commonly available. These applications include, for example, application programs that provide a graphical user interface to a telephone answering machine. The CD-ROM drives that are now provided as a standard feature of PC systems can play recorded music CDs through speakers attached to a PC system, and application programs have been developed to facilitate play of recorded music CDs. Television application programs have been developed that allow a user to view live television broadcasts in a multimedia window displayed on the monitor attached to the PC. Telephone monitoring applications have been developed to run on a PC that allow a user to accept and conduct telephone calls through the microphone and speakers that come standard with modern PCs.
Although great strides have been made in increasing the usefulness of home PCs, certain usability problems remain. One significant usability problem is that of coordinating concurrently executing application programs, so that the PC, and the applications executing on the PC, present a seamless, internally-coordinated system that behaves as a user desires and expects an integrated system to behave.
One aspect of this usability problem is that of implementing application programs to control and interface with external devices such that the application programs can intelligently interoperate during concurrent execution. As an example of the need to coordinate concurrently-executing application programs, consider a scenario where a PC user has launched a telephone application that monitors the user's telephone line for incoming calls and is, at the same time, either watching a television program on the PC or listening to a recorded music CD that is being played by the PC. An incoming telephone call may cause the telephone application program to signal the incoming call to the PC user through either a simulated ringing sound, some sort of graphically displayed indication, or both. These audio or visual signals from the telephone application may interrupt or interfere with the user's watching of the television program. For example, the telephone application may bring up an information window that displays options for the user's response to the incoming telephone call, including answering the call directly, ignoring the call, or forwarding the call to the answering machine. If this display window overlaps or conceals the window through which the television program is being broadcast, the user may miss a portion of the broadcast, and may be required to manipulate the mouse or keyboard in order to respond to the telephone application program or in order to bring the television window back to the forefront of the display screen. In similar fashion, any of the many possible concurrently-executing application programs may respond to outside events, or to user or program-generated events, in such a way as to interfere with other concurrently executing applications.
It is theoretically possible to build integrated applications that can detect each others' runtime activities in the PC and attempt to coordinate those activities. Practically, however, constructing such integrated applications is nearly impossible. Applications may be developed by many different entities, such as individuals or companies. These different development entities generally have no way of knowing what kinds of activities to expect from application programs developed by other entities, and the development entities generally have no means for establishing communications between the various application programs at runtime. A need has therefore been recognized for a technology that can be employed to coordinate the activities of concurrently-executing application programs so that they do not interfere with each other during execution and so that the concurrently executing programs cooperate one with another to provide a unified and easily managed system of cooperating application programs to the PC user.
SUMMARY OF THE INVENTIONEmbodiments of the present invention provide a method and system for coordinating the concurrent execution of computer programs on a computer system. In one embodiment, a set of key events that describe certain states and conditions that can be generated during execution of the computer programs are stored in a database, along with a set of commands for each computer program that can be accepted and executed by that computer program in response to each of the key events. When a computer program generates a state or condition during execution that corresponds to a key event, the computer program sends a notification of the occurrence of the key event to a control module. The control module then retrieves from the database the commands to be executed by each of the computer programs and sends the retrieved commands to the computer programs for execution. A computer user may interact with a graphical user interface to configure the system of concurrently executing computer programs by choosing one or more commands to be executed by each computer program upon the occurrence of a key event.
Embodiments of the present invention provide a method and system for integrating and managing application programs running on a computer system that comply with simple interface standards expected by the integration and management system. These embodiments provide a computer system user with the ability to configure interactions between compliant application programs so that they interoperate in a manner desirable to the user. These embodiments allow a computer system user to examine a list of compliant applications programs installed on the computer system. The list includes, for each application program, a sublist of the key events that may arise during execution of the application program, and a sublist of various tasks or commands that the application can perform at the request of the below-described integrated application management system (“IAMS”) that represents one embodiment of the present invention.
These lists of compliant application programs, including the commands that each application program can perform and the key events that can arise during execution of each application program, may be displayed to the user through a graphical user interface that allows the user to specify the commands that each application program should perform in response to the occurrence of each key event. For example, if a telephone application program may receive incoming phone calls, the occurrence of an incoming phone call may appear as a key event associated with the telephone application program. The user may specify that the telephone application program perform an answer command in response to the incoming phone call key event. The user may also specify that an MPEG movie viewing application perform a stop or pause command in response to the incoming phone call key event. When the user is later watching a movie displayed on the computer system and a phone call is concurrently received by the computer system, the IAMS issues an answer command to the telephone application and a stop or pause command to the MPEG movie viewing application. As a result, the system responds to the incoming phone call in the user-friendly manner that the user specified earlier through the graphical user interface, namely, the MPEG movie pauses to allow the user to accept the incoming phone call. The IAMS thus runs in the background, coordinating interoperation of the various compliant applications concurrently running on a computer system.
The IAMS may be hard-coded to contain a list of compliant application programs, along with sublists corresponding to each entry in the list of compliant application programs that contain the key events generated, and commands implemented, by each application program. Alternatively, the IAMS may identify each compliant application program and the key events generated, and the commands implemented by, each of the identified compliant application programs at run time. This information obtained at run time may be retrieved by the IAMS directly from compliant application programs through standard run time interfaces supported by each of the compliant application programs. As a third alternative, this information may instead be placed in the Windows registry by each compliant application program and subsequently retrieved by the IAMS from the Windows registry. The Windows registry is provided by Microsoft Corporation's Windows operating system. The latter two alternatives provide great flexibility to the user, allowing the user to incorporate a new compliant application program into the coordinated system of application programs managed by the IAMS without requiring the user to obtain a new IAMS or performing a complicated reconfiguration of the IAMS.
The IAMS comprises a main user interface (“MUI”), a user preference application (“UPA”), an application control module (“ACM”), and a number of cooperating applications that include a minimal amount of logic and interprocess communication support for interfacing to the ACM. The MUI allows the user to launch one or more of the compliant application programs and to launch the UPA. Using the UPA, a user is able to configure a cooperating application program to respond in certain well-defined ways to internal key events generated by the application program as well as to external key events generated by other, compliant application programs. While the application programs are executing, they export internally generated key events to the ACM and receive from the ACM, in return, commands that indicate to the application programs how they should respond to the events. Thus, the IAMS provides to a user the ability to configure the various compliant application programs to respond in certain well-known ways to each different type of key event that can be generated by that application program, or any other compliant application program, and the ACM provides a mechanism by which each application program is notified of the responses to key events that are expected of that application during its execution.
The embodiment described below is implemented to run on personal computers under the Windows operating system and makes use of the Microsoft Component Object Model (“COM”) (“Inside OLE,” 2nd Edition, Kraig Brockschmidt, 1995), to communicate between application programs and the ACM. An integrated application management system (“IAMS”) can, however, be implemented on many different types of multitasking operating systems and hardware platforms.
The ACM functions as a central hub within the personal computer through which application programs communicate with one another and through which a user configures and controls the behavior of the application programs. A user is thus able to configure and control the entire system of communicating applications primarily through the single graphical user interface presented by the IAMS. In a computing environment lacking an IAMS, the user is required to individually control and configure each application program through graphical user interfaces tied specifically to each application program, and applications programs, in general, have no way for coordinating their own activities with those of other application programs. In such environments, the user cannot specify coordinated, system-wide application program behavior.
The MUI provides a single user interface through which a user can launch the compliant applications and launch the user preference application (“UPA”).
The configuration information for the various application programs within the IAMS is stored within a database. In one embodiment of the IAMS, the configuration information is stored in the Windows registry, a hierarchical database implemented within the Windows operating system. The configuration information consists essentially of pairs of key events and commands. A key event is specified by the name of the application program that will receive the key event appended to the name of the key event. This application program/key event designation is associated in the Windows registry with the name of the command that the receiving application program is configured to execute in response to the key event.
Thus, in the registry, the name of a command is stored for each key event received by each application program. For example, the telephone application may generate a “Telephony Voice Ring In” key event corresponding to detection of an incoming telephone call. Each application that will run under the IAMS will then have, in the registry, a value for the “Telephony Voice Ring In” key event that consists of a command that that application should execute upon notification by the ACM of the occurrence of a “Telephony Voice Ring In” key event. The CD playing application may, for example, be instructed to execute a pause command in response to the “Telephony Voice Ring In” key event. In that case, the registry will contain the following name-value pair: CD player/Telephony Voice Ring In-pause. The telephone application, on the other hand, may be configured to answer incoming calls. In this case, the registry will further include the following name-value pair: telephone/Telephony Voice Ring In-answer call.
The current configuration for the application programs is stored within the registry within a named hierarchy such as “current configuration.” Additional configurations can be stored in separate files or under separately named hierarchies within the registry as named alternative configurations that can later be designated as the current configuration by the user.
The above-described configuration information is specified by a computer user through the user preferences application (“UPA”) that is launched by selection of the setup selection from the main menu.
By clicking on one of the tabulated form headings, the user can display the commands associated with the corresponding application program. For example in
When the user selects an event from the dropdown list 801 on the setup graphical user interface, a list 1101 of possible key events that can be generated by all of the application programs included in the IAMS is overlaid on top of the setup window, as shown in
A user may use the mouse to click on any of the commands displayed on the tabulated form for a particular application. A selected command is indicated by a small black dot appearing in the radio button associated with the command, as, for example, in
Table 1, below, shows examples of the various different application programs that may be in the IAMS.
In Table 2, below, are shown the various key events generated by each of the application programs described in Table 1, as well as the commands supported by each of the application programs. Each application program may also generate a “status” key event so that the ACM can synchronize its display with the application programs.
Table 3, shown below, includes an example configuration that may be specified by a user.
The communication between the application programs and various internal components of the ACM are indicated by double-lined arrows, like, for example, arrow 1606. These communications are implemented using the Microsoft COM. COM essentially allows a program to export one or more interfaces to other programs. A interface comprises one or more function pointers through which a process can call a function supported and executed by another process. COM also provides general function calls (i.e., QueryInterface) through which one process can inquire about the interfaces supported by another process and can determine the nature of each function within each interface. Thus, COM allows a process, at run time, to determine the exported functions provided by another running process and to call those functions. COM also allows processes to call other processes running on remote machines. Although the currently described embodiment employs COM, other object models supported by other vendors on other platforms could be utilized for implementing the ACM.
The ACM comprises a number of different, simultaneously-executing threads, a synchronization object, and command receiving and communications logic residing in each of the cooperating applications. That portion of the ACM residing in a cooperating application program is called the client ACM 1608–1611. The client ACM is responsible for sending indications of the occurrence of key events from an application program to internal ACM components. In addition, the client ACM receives commands from other ACM internal components and passes those commands on to the main logic of the application program for execution. The client ACM may be implemented as one or more COM interfaces. For example, the interface exposed to the internal ACM components might consist of a simple “receive—command” function that takes a single integer argument indicating a particular command from the set of commands supported by the associated application. The client ACM might have an additional interface consisting of one function “send—event” that takes a single integer argument and calls an interface function exported by an ACM internal component for receiving a key event from a client ACM. In such an implementation, each key event and each command is uniquely identified by an integer.
The internal components of the ACM include an event object 1612 and a registrar 1614 and a receiver 1615 that execute in a main thread 1613, which is an apartment thread. Apartment threads are associated with a Windows message queue and are obliged to process Windows messages. A free thread, on the other hand, is not associated with the message queue and does not process Windows messages. For each application program, there is a separate free thread running within the main ACM process called a deliverer 1616–1619. The deliverers are queued together on an event queue associated with the event object 1612. In addition, the ACM includes the setup program, described above, and a help program that guides a user through instructions on how to operate the MUI. The setup program and help program can alternatively be considered to be separate programs, apart from the ACM, or considered to be components of the MUI.
The registrar thread within the main thread is responsible for receiving startup notifications from an application, tracking that that application is currently running, and creating and associating a deliverer free thread with that application. Thus, the registrar exports to application programs a COM interface comprising two functions that allow the application program to register itself when it starts up and to unregister itself when it terminates.
The receiver thread running within the main thread is responsible for receiving indications of key events from running application programs. The receiver thread exports to the application programs an interface comprising a single function for receiving key events. Alternatively, the two functions of the registrar and the single function of the receiver can be combined into a single COM interface with three functions.
The event object 1612 is a Microsoft-supported semaphore-like object on which free threads can be queued to wait for the occurrence of a key event and which can be signaled by the receiver thread when the receiver thread receives an event from an application program. When the event object is signaled, the event object sequentially releases each delivered free thread in turn for execution. Each deliverer free thread calls the single function exported by the client ACM for receiving a command, passing to each client ACM the key event that caused the receiver thread to signal the event object. Thus, the ACM operates, in general, as a communication hub into which any application program can pass a notification of the occurrence of a key event. In response to that key event, each application program in the system, including applications that pass in a notification of the occurrence of a key event, receive a command from the ACM indicating the expected response of that application to the key event.
Although the present invention has been described in terms of one embodiment, it is not intended that the invention be limited to this embodiment. Modifications within the spirit of the invention will be apparent to those skilled in the art. For example, the ACM and the IAMS can be implemented on top of many different hardware platforms and operating systems, can employ a variety of different remote procedure call facilities for interprocess communications, and can employ a variety of different databases or file system objects for storing configuration information. The tasks supported by the ACM may be divided between internal ACM components in a different fashion and different numbers and types of internal ACM components might be used. The MUI may be differently implemented and have a different style for presenting selections and information to the user. One skilled in the art will appreciate that a compliant application program preferably can execute in a normal manner when the IAMS is not executing. In one embodiment, the ACM may provide a user interface describing the current state of the application programs, such as which application programs are currently executing. The user interface of the ACM may also allow the user to launch application programs and send commands to the application programs. The scope of the present invention is defined by the claims that follow.
Claims
1. A method in a computer system for management of concurrently running computer application programs, comprising
- providing an application control module that includes a registrar, a receiver, a number of deliverers, and an event object, where the registrar and receiver are both apartment threads running within the context of a main control module process and the deliverers are free threads running within the context of a main control module process, and where the application control module runs separately from an operating system and concurrently with at least a first of a plurality of client application programs, the application control module being configured to receive an indication of an occurrence of an event from the first client application program, each of the client application programs being configured with a client application control module that communicates the indication of the occurrence of the event generated or detected by the first client application program to the application control module, wherein at least one of the plurality of client application programs is not configured to respond to the event generated or detected by the first client application program;
- mapping the event generated or detected by the first client application program to a corresponding command to be executed by a second client application program, the mapping of the event to the command being stored in a repository accessible by the application control module;
- sending the indication of the occurrence of the event from the client application control module for the first client application program to the application control module;
- sending an indication from the application control module to the client application control module for the second client application program to execute the corresponding command mapped to the event; and
- executing the corresponding command under control of the second client application program.
2. The method of claim 1 wherein providing the mapping from the event to the corresponding command further comprises:
- obtaining a list of possible events generated by each client application program;
- obtaining a list of commands that can be performed by each client application program; and
- providing a user interface through which a user can select the event generated or detected by the first client application programs and select the corresponding command to be performed by the second client application program, and through which the user can map the selected event to the selected command.
3. The method of claim 2 wherein the lists of events and commands are hard-coded in computer code.
4. The method of claim 2 wherein the lists of events and commands are built at run-time by directing inquiries to each client application program through standard interfaces supported by each client application program.
5. The method of claim 2 wherein the repository is a registry, and wherein the lists of events and commands performed by the client application programs are stored by the application control module in the registry and retrieved from the registry by the user interface.
6. The method of claim 1 wherein the repository is a database, and the events and commands are stored, for subsequent retrieval, in the database.
7. The method of claim 1 wherein each client application program that generates an event sends a notification of the occurrence of the event to the control module which then forwards a command for execution to all the concurrently-executing client application programs.
8. The method of claim 7 wherein a computer user chooses one or more commands to be executed by each computer program upon the occurrence of the event from the sets of commands accepted and executed by each of the client application programs.
9. The method of claim 8 wherein the computer user interacts with a main graphical user interface to choose one or more commands to be executed by each client application program upon the occurrence of the event and to launch execution of a selected client application program when it is determined that the selected client application program is not concurrently executing.
10. The method of claim 9 wherein the control module receives notification from the selected client application program when the selected client application program begins to execute and, in response to the received notification, stores an indication that the selected client application program is running and establishes a connection between a client application control module for the selected client application program and the control module for passing notifications of the occurrences of events from the selected client application program to the control module and commands from the control module to the selected client application program.
11. The method of claim 9 further including, within the main process of the control module, executing the registrar, the receiver, and the number of deliverers, one deliverer for each client application program executing within the computer system.
12. The method of claim 11 wherein the registrar accepts notifications of the start of execution and termination of execution from the client application programs and establishes connections between the computer programs and the control module via the client application control module for each client application program; wherein the receiver receives notifications of the occurrences of events from the client application programs, and wherein the deliverers send the indications of the commands to be executed by the client application programs.
13. A system in a computer for coordinating concurrent execution of a number of computer programs, the system comprising:
- an application control module that includes a registrar, a receiver, a number of deliverers, and an event object, where the registrar and receiver are both apartment threads running within the context of a main control module process and the deliverers are free threads running within the context of a main control module process, and where the application control module runs separately from an operating system and concurrently with at least a first and a second client application program, the application control module being configured to receive an indication of an occurrence of an event from at least one of the client application programs, where at least one client application program is configured to generate or detect the event and at least one other client application program is not configured to respond to the event;
- a repository accessible to the application control module for mapping the event generated or detected by the first client application program to a corresponding command that is to be executed by the second client application program; and
- a client application control module within the first and second client application programs that is configured to send an indication of the occurrence of the event generated or detected by at least one of the client application programs to the application control module and to receive an indication of command to be executed that is sent from the application control module.
14. The system of claim 13 wherein the computer is a personal computer including the Windows operating system.
15. The system of claim 13 wherein the repository is the Windows Registry.
16. The system of claim 13 wherein the registrar receives notifications from a client application program when it begins to execute, stores an indication that the client application program is running, and creates a deliverer that is associated with the client application program.
17. The system of claim 16 wherein the receiver receives the notification of the event from a client application program.
18. The system of claim 17 wherein each deliverer receives the identity of the event, retrieves from the repository the command to send to the second client application program associated with the deliverer, and sends the retrieved command to the second client application program.
19. The system of claim 13, further including a graphical user interface that allows a computer user to specify for each event, a command to be sent to the second client application program and that allows the computer user to launch the second client application program if it is determined that the second client application program is not running.
20. A computer-readable medium containing computer instructions for coordinating computer programs concurrently executing on a computer system by:
- providing an application control module that includes a registrar, a receiver, a number of deliverers, and an event object, where the registrar and receiver are both apartment threads running within the context of a main control module process and the deliverers are free threads running within the context of a main control module process, and where the application control module runs separately from an operating system and concurrently with at least a first of a plurality of client application programs, the application coordination control module being configured to dynamically receive an indication of an occurrence of an event from the first client application program, each of the client application programs being configured with a client application control module that dynamically communicates the indication of the occurrence of the event generated or detected by the first client application program to the application control module, wherein at least one of the plurality of client application programs is not configured to respond to the event generated or detected by the first client application program;
- mapping the event generated or detected by the first client application program to a corresponding command that is to be executed by the second client application program; the mapping of the event to the command being in a repository accessible by the application control module;
- sending the indication of the occurrence of the event from the application control module for the first client application program to the application control module;
- sending an indication from the application control module to the client application control module for the second client application program to execute the corresponding command mapped to the event; and
- executing the corresponding command under control of the second client application program.
21. The computer-readable medium of claim 20 wherein defined events and commands are stored for subsequent retrieval in a database.
22. The computer-readable medium of claim 20 wherein a computer user is provided with the ability to choose one or more commands to be executed by each client application program upon the occurrence of the event from a set of commands accepted and executed by each of the client application programs.
23. The computer-readable medium of claim 22 wherein the computer user interacts with a graphical user interface to choose one or more commands to be executed by each client application program upon the occurrence of the event and to launch execution of the client application program if it is determined that the client application program is not concurrently running.
| 5315703 | May 24, 1994 | Matheny et al. |
| 5539886 | July 23, 1996 | Aldred |
| 5652888 | July 29, 1997 | Burgess |
| 5805886 | September 8, 1998 | Skarbo et al. |
| 5828882 | October 27, 1998 | Hinckley |
| 6226693 | May 1, 2001 | Chow |
| 6230160 | May 8, 2001 | Chan et al. |
| 6496872 | December 17, 2002 | Katz et al. |
| 6532498 | March 11, 2003 | Hager et al. |
| WO 94/23365 | October 1994 | WO |
- QUE Corporation, “ActiveX Programming with Visual C++”, 1997, Macmillan, Chapter 16—Single-Threading and Multithreading.
- Anonymous, “Customizing the LAN NetView Fix Action Table”, IBM Technical Disclosure Bulletin, vol. 37, No. 43, Apr. 1994, pp. 115-116.
Type: Grant
Filed: Jul 24, 1998
Date of Patent: Nov 29, 2005
Assignee: Micron Technology, Inc. (Boise, ID)
Inventors: Robert Williams (Minneapolis, MN), Robert Hoffman (Moundsview, MN), David M. Weightman (Shoreview, MN)
Primary Examiner: Meng-Al T An
Assistant Examiner: Li Zhen
Attorney: Dorsey & Whitney LLP
Application Number: 09/122,518
