EP1105786A2

EP1105786A2 - System and method for exchanging information relating to a target client application

Info

Publication number: EP1105786A2
Application number: EP99942206A
Authority: EP
Inventors: Steve Goldband; Ron Van Os; Jeffrey Barth
Original assignee: Aladdin Knowledge Systems Ltd; Preview Systems Inc
Current assignee: SafeNet Data Security Israel Ltd
Priority date: 1998-08-24
Filing date: 1999-08-17
Publication date: 2001-06-13
Also published as: JP2002524788A; EP1105786A4; WO2000014617A3; CA2341428A1; WO2000014617A2

Abstract

The present invention provides a transparent software monitoring/advisory mechanism, allowing for intelligent interaction with a user. A software agent causes hooks to be embedded into target client applications. Messages relating to user feature selection are hooked and sent to a monitoring process including a receiver and a primary thread. The receiver thread receives hooked messages and performs 'asynchronous message reflection' of these messages to the primary thread, which catalogs messages and updates feature usage counts. The agent established communication with a remote server via a 'virtual' Internet connection that is imperceptible to the user such as a LAN or dial-up connection. the server sends the agent command files that govern the agent's behavior. The agent retrieves resources from the server required to carry out commands contained within the command files and uploads selected information such as usage count information to the server in accordance with the command files.

Description

SYSTEM AND METHOD FOR EXCHANGING INFORMATION RELATING TO A TARGET CLIENT APPLICATION

BACKGROUND OF THE INVENTION

1. Field of the Invention The present invention relates to monitoring and augmenting computer programs.

2. State of the Art

In the past, computer programs have typically been static; i.e., once a user has learned a computer program, use of the program follows a pattern of command/response, command/response, the program presumably doing what it should and what the user expects it to but no more. More recently, means have been sought to make computer programs more dynamic, making them more useful and enjoyable.

Various mechanisms are known for monitoring and augmenting computer programs. U.S. Patent 5,432,940, incorporated herein by reference, describes a computer-based training (CBT) system that provides for interaction between a user and a target application. The system monitors various events of desired target applications. Messages from these events are trapped and reported as CBT messages to a Message Engine. The Message Engine dispatches the messages according to handlers specified by a Script Engine operating under the control of a script. A CBT script is organized as a collection of scenes, each scene describing the actions that take place at a particular point in the lesson. For example, a scene might instruct the CBT system to display a window containing some text when a particular menu item is chosen in the target application. As the lesson script proceeds, new scenes are performed. This process continues until the user chooses to exit the CBT system or until the lesson is finished.

International patent application WO 97/07656, also incorporated herein by reference, describes a system for selecting advertisements and other information from a computer network database based on user defined preferences and transmitting the selected advertisement in background mode over a communications link between the computer network and a local computer with minimal interference with other processes communicating over the communications link, and for displaying the selected advertisements on the user's computer. The system monitors the user's interaction with the advertisements and produces raw data on how may times a particular advertisement was accessed as well as the user's response to advertisements. Pertinent information is stored and sent back to a network server where it is made available to the advertisers. Other types of information content may also be transmitted, such as news, weather, stock quotes, sports scores, software updates or trip reservations information. The foregoing systems, however, may be quite obtrusive and have a significant impact on system performance.

SUMMARY OF THE INVENTION

The present invention, generally speaking, provides a transparent software monitoring/advisory mechanism, allowing for intelligent interaction with a software user. A software agent installed on a user machine causes hooks to be embedded into target client applications. Messages relating to user feature selection are hooked within the target client applications and sent to a hook monitor process including multiple threads including a receiver thread and a primary thread. The receiver thread receives hooked messages and performs "asynchronous message reflection" of these messages to the primary thread. The primary thread catalogs messages and updates feature usage counts based on the messages for future upload to a server. The primary thread also determines whether a particular message has an advisory associated with it, e.g., an advertisement, a survey, etc. If so, the primary thread calls a helper process to deliver the advisory. The software agent establishes communication with a remote server at intervals using a "virtual connection", i.e., an Internet connection that is imperceptible to the user. In the downlink direction, the server sends the agent command files that govern the behavior of the agent. The agent retrieves from the server resources, e.g. , advertisements, surveys, software updates, etc., required to carry out commands contained within the command files. In the uplink direction, the agent uploads selected information such as usage count information to the server in accordance with the command files. The "virtual" Internet connection may be a LAN connection or a dial-up connection. In the case of a dial-up connection, precautions are taken to avoid mistakenly causing dial-out. A transfer mechanism minimizes resource use and impact on primary traffic using the connection.

BRIEF DESCRIPTION OF THE DRAWING

The present invention may be further understood from the following description in conjunction with the appended drawing. In the drawing: Figure 1 is a generalized block diagram of the present system; Figure 2 is an illustration of an agent activation screen display; and Figure 3 is a more detailed block diagram of the agent of Figure 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to Figure 1 , the general architecture of the present system will be described. A user machine is assumed to include a run-time environment, provided by an operating system, a Web browser or the like, and to be running one or more computer programs. The computer programs may be software applications, system software or embedded computer programs. Systematic, individualized software interaction is made possible by equipping the user machine with a persistent client, or agent, that engages in two-way communication with a server. The agent may be installed concurrently with an application, may be pre-loaded on the user's machine, may be separately installed from a disk or download, etc. The connection between the agent and the server is a virtual connection, i.e., a connection that time-shares a physical communications channel with other communications. In an exemplary embodiment, the virtual connection uses spare bandwidth of intermittent Internet connections to communicate with the server. The agent can and typically does interact with the application without a concurrent Internet connection.

Communications between the agent and the server are voluntary. In an exemplary embodiment, when the agent is first activated on behalf of a particular application, it displays to the user a screen display such as that of Figure 2. In the example of Figure 2, the screen display is a "preferred customer enrollment" screen display. By clicking on the appropriate button, the user may accept or decline to participate in the preferred customer program. If the customer accepts, then the customer enters into an invited relationship with the software vendor and agrees to the software vendor maintaining personalized information about the configuration and use of the application in order to provide individualized service. Communications between the agent and the server are also two-way. In the uplink direction, the agent communicates control, configuration and usage information, registration information, survey information, etc. In the downlink direction, the server communicates non-executable content, executable content, or both, including control information, agent updates, etc. Non-executable content may include tips, offers, advertisements, surveys, etc. Note that non-executable content may nevertheless be active, i.e., contain HTTP links enabling the user to "click through" to related Web sites. Executable content may relate to the application or to the agent or both. Executable content related to the application may include updates, bug fixes, additional code modules, etc. Executable content related to the agent allows the agent to be transparently upgraded with new capabilities in the field, avoiding the potential problem of agent obsolescence. Referring to Figure 3, a detailed block diagram of the agent is shown.

In an exemplary embodiment, the agent follows a plug-in architecture. The agent process therefore includes a resident agent and various plug-ins that interface to the resident agent through a plug-in API. In an exemplary embodiment, the plug-ins include a command processor plug-in, a message plug-in, a survey plug-in, an Inet plug-in that handles virtual connections to the Internet, and a hook plug-in. The message plug-in, survey plug-in, and possibly other plug-ins are capable of taking actions within the process and User Interface (UI) space of the client applications. Other plug-ins may be included with the agent or added to the agent by download. If a plug-in needs the assistance of another plug-in, the agent will pass parameters transparently to the target plug-in. Persistent storage is provided for the plug-ins as well as for the resident agent, e.g., within the registry file system.

The modularity resulting from plug-in architecture of the agent is important from the standpoint of allowing for user-transparent operation. The core agent and the plug-ins are all small modules (typically less than about 12K bytes) that are easily downloadable. The time needed to download a module is typically only a few seconds.

Core tasks of the agent include the following: 1. Manage plug-ins and inter-plug-in communication.

2. Download content (command files) and determine an appropriate command interpreter for handling the command files. Retrieve the command interpreter plug-in from the server and invoke it with the downloaded command file. 3. Maintain state (e.g., the current command file) to survive system crashes and restarts. The operating system registry may be used for persistent storage of state information including the configurations of the plug-ins, the status of events and the registered client applications.

4. Monitor the system Internet connection and schedule uploads and downloads.

5. Track target applications and determine their usage. From this information and the command file data, schedule actions to be taken in the target applications user interface (UI) space through the plug-in interface.

6. Change its level and type of activity, including becoming inactive in response to a server.

The agent is capable of interacting with software applications in all respects without modification of the application itself. In particular, a small hook (e.g., a DLL) is inserted into parent tasks of display windows displayed on a user machine. Information identifying target client applications is stored in persistent storage (e.g., the operating system registry) where it is accessible to the hooks. Each hook determines whether it is embedded in a target client application, by determining the module's executable name and using an agent-maintained client lookup table stored in the registry. If it is embedded in a target client application, the hook remains. If not, the hook requests that it be removed.

The hook determines if any relevant "feature selection" actions are happening within a monitored application and if so, passes this information to the hook plug-in. In particular, the hook places the message, through a POST, in the hook plug-in message queue. The hook plug-in is designed to not degrade the user's system performance or application performance. More particularly, in an exemplary embodiment, the agent when it first launches loads the hook plug-in, which starts execution of a separate receiver thread, Trx. This receiver thread is designed to be high-availability in order to interact with the client application hooks. Using a separate thread ensures that processing of the messages of the client application are not noticeably slowed down. The agent will only place one hook per active UI thread in the client application, ensuring that only a single hook is placed. (Note, however, that a single client application can have multiple hooks placed if multiple active threads are present in the client.) The placed hooks cannot call one another, so recursion cannot happen. The receiver thread receives hooked messages and performs "asynchronous message reflection" of these messages to a primary thread, Tpri. The primary thread catalogs messages and updates feature usage counts based on the messages for future upload to a server. The primary thread also determines whether a particular message has an advisory associated with it, e.g., an advertisement, a survey, etc. If so, the primary thread calls a helper process (advertisement plug-in, survey plug-in, etc.) to deliver the advisory.

Latency between detection of a user action and an advisory message timed to immediately follow the user action is minimized to convey the impression that the advisory content is actually part of the application. In a preferred embodiment, a dialog may be loaded in less than about 50ms. This quick response may be achieved by preloading dialogs into memory and, when the appropriate event notification is received, calling the operating system to display the selected dialog.

An advisory dialog may be "attached" to a pre-existing window by "subclassing the window." The advisory dialogs are modal such that user focus is removed from the client application until the user takes some action with respect to the dialog.

The primary thread, besides maintaining usage counts and causing presentation of advisory messages, may also track user activity as a function of time, e.g. , when an application was launched and when it was shut down, how long the application had user focus, and how much of the time the user was actually doing something. In an exemplary embodiment, for purposes of the latter measure, if at least one event is received during the course of one minute, then the user is deemed to have been actively using the application during that minute. The Inet plug-in is responsible for handling all Internet traffic. In an exemplary embodiment, it supports various types of Internet transactions, including registering an agent with the server and obtaining a user ID, retrieving a command file using the user ID, uploading data to the server, and downloading resources from the server. Data may be exchanged using POST and GET commands, for example, as in the HTTP1.1 protocol. The Inet plug-in is designed to gracefully fail if any transaction is not completed across the Internet.

The command processor plug-in is responsible for converting the command file into tangible actions. For example, it scans the command file and schedules all resource downloads required by the command file, expands any macros, and generates a clean version of the command file. It then processes the command file, merges it with existing command files, removes all completed events from the command file, and schedules all events and actions to be taken by the agent. Finally, it marks the command file as active in persistent storage and uploads a command line status update that allows the server to track the execution of events in the client application.

An agent control panel applet enables user interaction with the agent to control prospective operation of the agent, although typically the user will not have occasion to use the control panel. As described previously, the user may accept or decline the invitation to activate the agent. The user may be provided with additional control beyond this initial decision. For example, the user may choose at a later time to modify the degree of interaction, the type or amount of information transmitted, or withdraw entirely and discontinue all communications between the agent and the server. The user may wish instead to continue uplink operations (e.g., monitoring by the agent to facilitate conventional kinds of customer service) but to discontinue downlink operations. Alternatively, the user may wish to continue uplink operations and a limited subset of downlink operations, e.g., upgrade notification. Various other options may be provided.

Instead of a control panel applet, a mechanism may be used to dynamically add a menu entry to the client's menu bar, which functions to allow the user to control the agent functionality within that client. Dynamically adding a menu entry may be accomplished in the following manner:

2. The agent finds the client adds the menu item to the client menu bar. 2. When the user clicks this menu, the agent (through the hook(s)) is notified of this event and a plug-in shows in the client UI controls for controlling various agent features.

In an exemplary embodiment, the resident agent includes a scheduler/manager, a remote dial-up monitor, and a command file pre-processor. The resident agent also includes a client map, an event map and a plug-in map. The resident agent is responsible for dynamically maintaining the configuration and status of active plug-ins, the registered client applications and the events working on the client applications. A command queue contains actual event information and is processed upon each agent start. In an exemplary embodiment, the agent is started by a machine start table within the registry of the operating system.

The scheduler/manager is responsible for establishing periodic Internet connections with the server, through the Inet plug-in. If a connection becomes available, each client object is allowed bandwidth to service the client's needs.

Subsequently, all pending POST operations are processed. The scheduler/manager can be invoked either via an event driven method, in the case of dial-up Internet access, or at periodic intervals in the case of direct (or proxied) LAN -based Internet access. In the case of dial-up access, different dial-up access methods may be used depending on the software configuration of the user machine. The remote dial-up monitor determines which dial-up access method is used and establishment of an Internet connection is detected accordingly.

More particularly, in the case of a dial-up connection, the registry is read in order to identify a specialized client application used for dial-up. The agent then hooks that application. The hook, by reading the registry, determines that its purpose is to monitor dial-up and therefore only passes messages relating to dial-up events. These messages are received by the remote dial-up monitor. When a normal sequence of dial-up events is detected, the remote dial-up monitor starts a counter. After the counter has timed out, if the dial-up application is still active, the remote dial-up monitor will schedule a connection.

In some instances, the remote dial-up monitor may be fooled into "thinking" that a connection exists when one does not. For example, dial-up may have been started by cancelled. Because the agent depends on periodic checks ins with the server, the likelihood of an existing connection is sufficient to cause the agent to attempt a connection. To avoid the possibility of mistakenly initiating a connection where none exists (violating user transparency), the system is momentarily switched from dial-up access mode to LAN access mode, the TCP stack— in a small percentage of cases in which it may not have already been initialized— is initialized, and the system is switched back to dial-up access mode. Only in one instance does the time-out expire and an Inet access attempt is scheduled which, if no dial-up protection were implemented, would cause the dial-up dialog to appear. This is when the user cancels out of a dial-up attempt and does not exist the dial-up manager. If the user exists the dial-up program before the time-out expires, no Inet access is attempted. The dial-up protection mechanism is needed for the following reason. If the system is in dial-up (RAS) mode, the Inet access request will be serviced in either way. As a result of a multi-point tunneling protocol used by the Windows operating system (NT and 95/98), for example, an attempt will be made to connect across the LAN, while also establishing a dial-up connection. The first successful connection will be routed to the client which originally made the request. When the system is in LAN mode, without a LAN connection, and an Inet access request is made, the TCP stack will be initialized and eventually time-out. Even if the system has a modem, it will not be used. Therefore, by switching to LAN mode prior to any connection attempt, dial-up is avoided.

In the case of both LAN and dial-up connections, agent traffic is scheduled at low priority relative to other traffic, ensuring no user-perceptible impact on performance. Alternative methods of achieving "polite" connection are inferior insofar as they involve monitoring the TCP/IP stack, which requires loading of support DLLs and therefore increases the memory footprint.

The client map, event map and plug-in map together operate to establish "client channels" though which interaction between the clients and the server occurs. The client map consists of one or more client objects. At a minimum, a privileged client object is present that is allowed to add clients to and remove agents from the client map and to add agents to and remove agents from the plug-in map. All other client channels can only be used to schedule events and direct the agent to download content from a server. A client object within the client map has a corresponding event object within the event map and a corresponding plug-in object within the plug-in map. The event map in combination with the client map causes user interactions in the client applications UI space.

Note that preferred support for copies of applications already in the field can be added simply by instructing the agent to add the new application module name to the client lookup table. Subsequently, the agent will check-in on behalf of the new client and receive command information.

The agent checks in with the server when a check-in interval for the application has elapsed. The agent may receive back a command file from the server, which the agent then interprets. The interpretation of the command file may cause the agent to fetch resources from the server and/or place information back onto it. The agent may also be instructed to check-in for another command file. The privileged client is also considered an application for the agent. Therefore the agent checks in with the appropriate server on a check-in interval separate from the check- in intervals of other applications. Also, an application's command file may cause the privileged client to check in, or vice versa.

When the agent has acquired the resources and commands from the server to actually do some work, it can be instructed to immediately display appropriate messages to the user, or (more commonly) to wait until the target application is running, and work in the context of the application. The agent converts system event data into tangible actions events for the attached plug-ins, with messages appearing to the user as coming from the vendor, within the application's screen window and only while the application is running. There results a sense of connectedness and trust between the customer and the vendor. A typical sequence of events is as follows:

1. The hook determines that a new application has launched or gotten the user's focus.

2. The agent queries its client objects to see if the application is a client. If it is not a client, the agent remains dormant. 3. A valid client with user input will cause the agent to instruct the hook to start detailed monitoring of the application and route selected application messages through the hook plug-in. 4. The hook plug-in will reflect the message asynchronously to the agent, which will catalog the events under the current user's name. 5. The agent queries its client event map to look for a match.

6. If a match exists, the event is executed, which could include invoking a plug-in to undertake action in the application's UI space. If visible content is shown in the application's UI space, the client application is temporarily disabled and cannot receive user focus. 7. If any uploadable content is generated during this event, it is passed to the Inet plug-in, which will either send it or schedule it to be sent the next time bandwidth is available.

8. After completion of the event, the user focus is set back to the client application.

9. The agent returns to Step 4 above until the client application loses focus. When the client application loses focus, the agent transfers any client application-related data to persistent storage, at which point the agent reverts to Step 1 above.

Having described the structure and function of the agent, the server will now be briefly described.

The essential job of the server is the delivery of an appropriate command file to particular agent. The command files in the agent determine the action that the agent is going to take— which of the various kinds of activities it will carry out, at what time, with respect to what user operation, etc. The server maintains a record for every single user of an application. When the agent working for one of its user's connects to the server, it consults a table of rules that determines which, if any, of the potential command files that the server has for that application are appropriate for that agent. Those rules are predicates that are based on all the data in the database relative to that user.

An example of a rule might be "If installation of this application took place 60 or more days ago, send Command File A," which causes the agent to perform some action, "and if installation took place less than 60 days ago, send Command File B," which takes some other action. The two actions would differ with respect to the degree of experience that particular user has with the program. For example, in the case where an upgrade has become available, a publisher may choose to send one upgrade message to experienced users, more appropriate to their experience level, and another upgrade message to less experienced users, more appropriate to their experience level. The determination of experience level may be based, for example, on the time elapsed since installation.

The server applies rules that have been created in a table sequentially to determine which if any of those rules are true for a particular agent that is querying the server at a particular point in time. Upon discovering that one or more of those rules "fires," i.e. is true, then the corresponding one or more command files are downloaded to the agent. The publisher therefore enjoys very "fine-grain" control of the activities of an agent based on the attributes of that agent. Very sharp targeting results in which particular information is sent to particular agent based its characteristics and its history.

It will be appreciated by those of ordinary skill in the art that the invention can be embodied in other specific forms without departing from the spirit or essential character thereof. The presently disclosed embodiments are therefore considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalents thereof are intended to be embraced therein.

Claims

Claims:

1. A method of exchanging information relating one or more target client applications between a computer platform, having an operating system, on which the target client application runs, and a remote server, the method comprising the steps of: intercepting at least one of messages passed and functions called between the target client application and the operating system; performing asynchronous message notification of selected activity from a target client process to a second process for further processing; and in response to said notification, causing transfer of information relating to the target client application to or from said second process.

2. The method of Claim 1, further comprising performing activities perceived the user to be related to the client process without inserting messages into a message queue of the target client application.

3. The method of Claim 2, wherein causing exchange of information relating to the target client application comprises scheduling exchange of information between the computer platform and the remote server.

4. The method of Claim 3, further comprising establishing a virtual connection to the remote server and transmitting information relating to the target client application to the remote server, whereby said exchange of information relating to the target client application is substantially imperceptible to a user of the target client application.

5. The method of Claim 4, wherein establishing a virtual connection comprises: detecting that a process has initiated a connection; initiating a transfer process; and setting a priority of the transfer process to a lower priority than the process that initiated the connection.

6. The method of Claim 5, wherein the second process is an agent process and said transfer process transfers incremental small amounts of data which are aggregated by the agent process.

7. The method of Claim 2, wherein causing exchange of information relating to the target client application comprises causing presentation of information within a user-interface space of the target client application.

8. The method of Claim 7, further comprising adding a menu entry to the target client application.

9. The method of Claim 8, wherein the menu entry controls at least one aspect of the exchange of information.

10. The method of Claim 7, further comprising, during presentation of said information, removing user focus from the target client application.

11. The method of Claim 10, wherein causing presentation of information and removing user focus comprises attaching a modal dialog to a window of the target client application.

12. The method of Claim 7, further comprising, prior to presenting information within the user-interface space of the target client application, establishing a virtual connection to the remote server and transmitting information relating to the target client application, causing presentation of information, to the computer platform, transmission of said information being substantially imperceptible to a user of the target client application.

13. The method of Claim 12, wherein establishing a virtual connection comprises: detecting that a process has initiated a connection; scheduling a transfer process; and setting a priority of the transfer process to a lower priority than the process that initiated the connection.

14. The method of Claim 13, wherein the second process is an agent process and said transfer process transfers incremental small amounts of data which are aggregated by the agent process.

15. The method of Claim 1, further comprising: detecting a process on the computer platform; identifying the process; and determining whether the process is a target client application for which information is to be exchanged between the computer platform and the remote server.

16. A method of exchanging information relating to a target client application between a computer platform, having an operating system, on which the target client application runs, and a remote server, the method comprising the steps of: intercepting messages passed between the target client application and the operating system; scheduling a transfer process for exchanging information relating to the target client application derived from said messages; and setting a priority of the transfer process to low priority.

17. The method of Claim 16, wherein said transfer process transfers small amounts of data that are aggregated by an agent process.

18. The method of Claim 16, further comprising establishing a

LAN-type Internet connection and executing the transfer process, execution of the transfer process being substantially imperceptible to the user.

19. The method of Claim 16, further comprising: detecting that a connection may have been initiated; and starting the transfer process; and setting a priority of the transfer process to a lower priority than the process that initiated the connection.

20. The method of Claim 19, further comprising: prior to executing the transfer process, disabling dial-up, and after execution of the transfer process has begun, enabling dial-up; whereby execution of the transfer process is substantially imperceptible to the user.