text:
Systems and methods for monitoring usage of an electronic device are disclosed herein. A client component in stalled in a client device is operative to monitor usage of the client device in accordance with a monitoring profile, and to generate corresponding usage data. The monitoring profile typically includes information specifying which features of which application programs are to be disabled on the client device. A server component, installed on a server device in communication with the client device, provides the monitoring profile to the client device and receives the usage data from the client device.
1. A method for restricting computer usage comprising the steps of:
receiving at a client computer a monitoring profile which identifies prohibited usage of said client computer from a server computer;
reviewing said monitoring profile to identify restricted features of an application on said client computer;
detecting startup of an application program subject to prohibited usage in accordance with said monitoring profile;
identifying accessible objects associated with the application program;
when an identified accessible object corresponds to an identified restricted feature, identifying an associated control of the application program and restricting the control so as to be no longer capable of receiving user input, thereby disabling, in accordance with said monitoring profile, at least certain functionality of the application program executing on said client computer.
2. The method of
3. The method of
4. The method of
5. The method of
6. A system for restricting computer usage comprising:
a client component installed on a client device, said client component being operative to identify prohibited usage of said client device in accordance with a monitoring profile, to disable at least certain functionality of an application program executing on said client computer, and to generate corresponding usage data, the client component configured to communicate with a remote server component installed on a server device in communication with said client device, to said client device configured to receive said monitoring profile from said server component, said monitoring profile identifying prohibited usage of said client computer, said client computer configured to
review said monitoring profile to identify restricted features of an application program on said client computer,
detect startup of an application program subject to prohibited usage in accordance with said monitoring profile,
identify accessible objects associated with the application program,
when an identified accessible object corresponds to an identified restricted feature, identifying an associated control of said application program and restricting the identified control so as to be no longer capable of receiving user input,
the client component being further configured to provide said usage data from said client device to said server component.
7. The system of
8. The system of
9. The system of
10. The system of
11. The system of
12. A system for restricting computer usage comprising:
a server component installed on a server device configured for data communication with a remote client device, the server component configured to provide a monitoring profile to a client component operating in conjunction with said client device, said monitoring profile identifying prohibited usage of said client computer and including data and instructions to cause said client component to
review said monitoring profile to identify restricted features of application programs on said client computer,
detect startup of an application program subject to prohibited usage in accordance with said monitoring profile,
identify accessible objects associated with the application program, and
when an identified accessible object corresponds to an identified restricted feature, identifying an associated control of said application program and restrict the identified control so as to be no longer capable of receiving user input, and
generate corresponding usage data,
the server component further configured to receive said usage data from said client device.
13. The system of
14. The system of
15. The system of
16. The system of
The present patent document is a divisional of application Ser. No. 09/587,236 filed Jun. 2, 2000 and International Application No. PCT/US00/15299 filed on Jun. 2, 2000, which claims priority from provisional Application Ser. No. 60/139,915 filed on Jun. 17, 1999, which claims priority from provisional Application Ser. No. 60/137,788 filed on Jun. 3, 1999, which is incorporated herein in its entirety by this reference.
This invention relates to a system for monitoring usage of computers and other electronic devices, and, more particularly, to a system for collecting information concerning user interaction with application programs and the host environment in accordance with defined monitoring profiles.
Many commercial and governmental organizations are becoming increasingly reliant upon software applications to perform enterprise management and other functions. Expenditures relating to hardware, software and related support (collectively, �information technology�) now represent a significant portion of the capital improvements undertaken by many entities. Since it is not atypical for a large corporation to utilize software products from hundreds of different vendors, it is not uncommon for difficulties to arise because of overlapping program functionality. Usage of a multitude of software products also tends to complicate delineation of training and line management responsibilities.
An enterprise may be motivated to make investments in information technology for a variety of reasons. For example, information technology assets may be utilized to generate revenue for the enterprise by facilitating accomplishment of essential tasks. Investments in information technology may also be motivated by a desire to reduce costs by streamlining or simplifying certain activities. Information technology may also be acquired as a form of insurance against losses from system failures or breaches in security, irrespective of whether the acquired assets enhance revenue or reduce costs.
Although relatively clear motivations may exist for considering investments in information technology, the selection of particular assets for acquisition has become a complex process. A primary difficulty confronting managers responsible for acquiring information technology is determining an expected rate of return in connection with the proposed investment. This is a difficult task because current monitoring systems are not designed to selectively track measure and analyze user activity most pertinent to determination of such an expected rate of return. Responsible management must also decide which applications should be purchased, and when such purchases should be made. It must also be determined how users will be trained, and how subsequent performance will be measured. Current monitoring systems are also ill equipped to provide assistance in making these types of decisions.
Management of large enterprises are also becoming interested in determining the total cost associated with ownership of particular information technology assets. A rudimentary measure of the cost of such ownership is obtained simply by determining the expense required to furnish each user with required hardware and associated software. More sophisticated measures of such ownership costs will also take into account an expected rate of return on the investment in information technology by ascertaining the extent of any increase in user productivity. Existing computer use monitoring systems have unfortunately not been specifically designed to measure such user productivity, and thus have tended to be of minimal assistance in facilitating determination of an expected rate of return on investments in information technology. Decisions regarding investments in information technology are thus likely being made without the benefit of relevant information relating to user productivity and expected rates of return.
In one aspect the present invention comprises a system for monitoring usage of an electronic device. A client component installed in a client device is operative to monitor usage of the client device in accordance with a monitoring profile, and to generate corresponding usage data. The monitoring profile typically includes information specifying which application programs, and which features of such application programs, installed on the client device are to be monitored by the client component. A server component, installed on a server device in communication with the client device, provides the monitoring profile to the client device and receives the usage data from the client device. The system may also include a data management component disposed to store the monitoring profile and to store the usage data provided to the server device. A data analysis component determines usage statistics associated with application programs installed on the client device based upon the usage data. The usage statistics may include measurements of usage time, number of uses, and sequence of usage of specified ones of the application programs.
Another aspect the present invention relates to a method for monitoring user interaction with a web page downloaded to a client device from a remote location. Monitoring instrumentation is initially embedded within the web page in accordance with a monitoring profile. This embedding may be effected by, for example, incorporating scripting language into the web page. Events relating to such user interaction are monitored, and corresponding usage data is generated using the monitoring instrumentation. The usage data is then transmitted from the client device to a monitoring server.
In the accompanying drawings:
A preferred embodiment of the computer usage monitoring system of the present invention may be used in a distributed system 10 of the type shown in
In order to minimize complexity and facilitate orderly relations among the various monitoring components, each component is designed to have only limited awareness of the system environment. This limited awareness simplifies communication between system components, and eases system administration. In particular, each client monitoring agent 52 is preferably made to be aware of only its client service 50. Similarly, each client service 50 is aware of only its assigned server computer and of its client monitoring agents 52. As is indicated by
Referring now to
The profile builder 72 is an application program designed to provide a mechanism for creating a monitoring profile 76 composed of one more application profiles 78. Each application profile 78 determines the type of usage of an associated application program 79 which is to be monitored. For example, an application profile 78 may specify that use of certain editing functions (e.g., �Cut� and �Paste� operations) are to be recorded, and that periods of inactivity of greater than a predetermined duration are also be noted. The monitoring profile 76 also specifies the frequency with which usage data collected in accordance with the application profiles 78 is to be reported to the server module 22 on the server computer 14. Such usage data may include, for example, information relating to the use of mouse actions verses accelerator keys, the frequency with which key application features are used, and the sequences of actions taken within an application or between applications. Each monitoring profile 76 may be assigned to a particular user or group of users.
In a preferred implementation a set of default application profiles associated with well known application programs are stored within a database 80 for the server computer 14. Default monitoring profiles which use default application profiles may also be stored within the database 80. The default application profile provides a template from which monitoring profiles 76 and application profiles 78 tailored to particular users may be developed using the profile builder 72.
One principal feature of the profile builder 72 is the ability to create application profiles applicable to essentially any Windows-based application. As is described below, the profile builder 72 allows for creation of an application profile 78 through selection of various items from the user interface presented by the associated application program. Items such as buttons, text fields, menus, and the like from the applicable user interface may be selected. Application profiles 78 that have been created in this manner via the profile builder 72 can be saved within the database 80 via DBOB 74 and used in combination with other monitoring profiles 78 in order to construct various monitoring profiles 76. The DBOB 74, in conjunction with the database 80, collectively serve as a repository for all monitoring profiles 76. The profile builder 72 uses the DBOB 74 to access an object corresponding to a monitoring profile 76 desired to be viewed and/or modified. The database 80 is preferably implemented as a relational database.
The profile builder 72 will preferably provide a graphical interface allowing for inspection and modification of the monitoring profiles 76 stored within the database 80. In this regard each monitoring profile 76 can be visualized as a treelike structure consisting of a plurality of application profiles 78. Each constituent application profile 78 may be selected and its contents edited. As is described below, the profile builder 72 also allows for definition of particular classes of users, hereinafter referred to as �groups�. A particular monitoring profile 76 may be assigned to each such group, thereby allowing evaluation of the performance of each user in the group relative to the assigned monitoring profile 76. Groups are a mechanism to allow system administrators to easily define and maintain identical profiles for multiple users.
In a preferred implementation of the usage monitoring system of the present invention a monitoring profile 76 is associated with each user of a client computer 12. As is indicated by
When a user becomes logged on to a client computer 12, the client service 50 installed on the computer 12 requests a profile server 88 to deliver the associated monitoring profile 76. The client service then creates a client monitoring agent 52 and initializes it with the monitoring profile 76 (
As an initial step in identifying the appropriate monitoring profile for a given user, upon becoming logged on to client computer 12 it is determined whether the user has previously been assigned a monitoring profile. If not, it is determined whether the user is a member of any defined groups. If so, the monitoring profile for the applicable group is assigned to the user; otherwise, the profile for the default group is assigned to the user. Upon identifying the most specific monitoring profile applicable to the given user, the object corresponding to the identified monitoring profile 76 is provided by the DBOB 74 to the client monitoring agent 52 (via the server module 22 20) by the client service 50. The client monitoring agent 52 then begins monitoring user activity in accordance with the received monitoring profile 76.
As is indicated by
Each monitoring profile will typically specify the application programs, and the features in such programs, which should be tracked. Monitoring profiles by default record entry into and exit from each application program in order to measure the duration of usage of each application. Various monitoring profiles may also define a user inactivity threshold, which is compared to the duration of a user's inactivity. A user is deemed to be �inactive� when such user fails to interact with any application program for a period exceeding the inactivity threshold, and is otherwise deemed �active�. Information relating to the schedule (e.g., time of day, days of week) during which a given user is to be monitored will be included in each monitoring profile 76.
Also preferably included in each monitoring profile are specifications pertaining to the reporting of monitoring data from the client service 50 to the server module 22. These data reporting specifications will typically specify an upper limit to the size of the file (or memory buffer) containing the monitoring data held on the client computer 12. In a preferred implementation the client monitoring agent 52 informs the client service 50 when this upper limit is exceeded (i.e., when data is available for transfer from the client monitoring agent 52). In turn, the client service 50 signals the applicable server module 22, which in its discretion calls back to the signaling client service 50 to collect the cached data. In a preferred implementation a nominal data reporting interval, relating to the minimum frequency with which reports need to be provided to the server module 22, is included in the data reporting specifications of each monitoring profile. This parameter ensures that the server module 22 obtains timely updates from the client monitoring agent 52 (i.e., at least once per nominal data reporting interval), even during periods of low user activity.
Each client monitoring agent 52 is also capable of collecting, in accordance with the applicable application profile, data pertaining to usage of defined �features� of application programs. In the context of the present invention the term �feature� is intended to refer to the operation or function performed by a series of keystrokes or mouse clicks. For example, the keystrokes required to enter text into a file path field, or to enter text into a main application window, could each be defined to correspond to a particular feature.
In an exemplary implementation the client monitoring agent 52 is disposed to track the following application features:
As is described in detail below, the client monitoring agent 52 generally uses one or both of two primary methods of collecting information relating to usage of application programs. A first technique involves monitoring and filtering the message traffic associated with particular user interface events of Windows-based applications. This information is accessed via hooks in the applications and Windows operating system which are associated with particular user interface events (collectively, �Windows Hooks�). Data relating to this message traffic may be analyzed to ascertain the existence of activities deemed to be of significance within an application. Such activities could include, for example, rates of mouse and accelerator key events useful in computation of general productivity metrics.
In implementations of the present invention within systems governed by recent versions of the Microsoft Windows operating systems (e.g., Windows 95, Windows 98, or Windows NT 5.0), information concerning usage of certain application programs may also be collected via Microsoft Active Accessibility application programming interfaces (�Accessibility APIs�). These Accessibility APIs allow more extensive information to be collected regarding usage of various application features. In this context an application �feature� is defined by an Accessible Object of the application program, where the term �Accessible Object� is intended to have the meaning provided within the �Microsoft Active Accessibility Software Development Kit,� which has been made available at http://www.microsoft.com/enable/dev/msaa.htm. Accessibility APIs were designed primarily to provide limited internal access to an application program in order to facilitate utilization of alternative input and feedback mechanisms associated with third party applications.
Application programs incorporating Accessibility APIs create and destroy Accessible Objects during program execution. In a preferred implementation of the present invention the following process is employed to track usage of application features by monitoring associated Accessible Objects:
Since Accessible Objects are extinguished each time an application program is terminated, it is necessary to identify those of such objects corresponding to monitored features upon each subsequent invocation of the application program. TABLE I provides a list of attributes of Accessible Objects and accompanying explanations of the manner in which such attributes can assist in identifying objects corresponding to monitored features.
The client monitoring agent 52 examines the attributes of Accessible Objects set forth in TABLE I to identify objects corresponding to monitored features. However, examination of the four attributes listed in TABLE I will not always uniquely identify a monitored feature, although in most practical applications such an examination will suffice. As an example, consider the case in which the monitored feature consists of the Copy menu item on the Edit menu within Microsoft Word 97. The Copy menu item reports the following characteristics when examined through its accessible interface:
Unfortunately, these features are also reported by the Accessible Object associated with a Copy menu item appearing on the popup menu which arises in response to a �right click� in the text area of a document. Accordingly, merely examining the values for the attributes listed in TABLE I leads to an ambiguous result. TABLE II lists the values for the attributes of the Accessibility Object for the �Copy� feature from the popup menu along with the attributes associated with the �Copy� feature from the menu bar:
In the example of TABLE II, the values of the Window Class and Top Level Window differentiate between the two Copy items. Although it is believed that in most instances Accessibility Objects associated with specific features may be distinguished by inspection of the attributes described in TABLE I and TABLE II, the present invention provides a mechanism hereinafter referred to as �feature ancestry� for resolving any ambiguities.
The concept of feature ancestry may be appreciated by considering that every Accessible Object is a member of a tree structure of Accessible Objects stemming from a Top Level Window. In this context a given Accessible Object can generally be identified by a qualified name generated by concatenating the names of selected Accessibility Objects forming an ancestry of the given Accessible Object. It is noted that each potential ancestral Accessibility Object need not necessarily be used in the identification process. The following procedure may be utilized to determine the qualified name of an Accessible Object:
As an example of the above procedure, consider the case of the standard �OK� button commonly found on dialog boxes. In the case of Microsoft Word 97, examination of the attributes of the Accessibility Object for the �OK� button on the dialog box brought up via the �Tools/Options . . . � menu item yields the following: Object Name is �OK�, Role is ROLE_SYSTEM_PUSHBUTTON, Window Class is �bosa_sdm_Microsoft Word 8.0�. Examination of the Accessibility Object for the �OK� button on the dialog box brought up by �File/Print . . . � menu item yields exactly the same information. However, the ancestral Accessibility Objects for each of these �OK� buttons are different as indicated by TABLE III:
As is indicated by TABLE III, the Accessibility Objects for the two �OK� buttons described in the preceding example can be distinguished only by comparing their respective ancestral Accessibility Objects.
Each feature identified by the applicable monitoring profile is tracked according to whether the feature is �used� or not. When features are monitored via associated Accessibility Objects, the definition of usage for a given feature is dependent upon the nature of the role defined by its associated Accessibility Object. TABLE IV below provides exemplary usage definitions for roles assumed by various Accessibility Objects associated with features likely to be tracked. Again, the role of an Accessibility Object may be examined by way of the defined set of Accessibility APIs. TABLE IV also provides, for certain roles, examples of the manner in which usage of an application program affects the state of a given role.
In accordance with one aspect of the present invention, the AppFeature DLLs 102 internally use Windows Hooks in conjunction with Accessible Events to determine whether a feature is being used. Although the Accessibility API provides notification of occurrences of Accessible Events monitored by AppFeature DLLs 102, not all Accessible Objects generate notifications capable of being monitored by the AppFeature DLLs 102. Accordingly, the Windows-based events tracked by the Hooks DLLs 92 are used to trigger the AppFeature DLLs 102 to query the Accessibility API for information relating to the identity of the Accessible Object, if any, associated with the Window generating the event. The following is an exemplary sequence of Windows-based events capable of being monitored by an AppFeature DLL 102:
Further details regarding various preferred mechanisms for tracking user events in accordance with the present invention are described below with reference to
The DAT 114 provides the means to view and compare the data collected by the client monitoring modules 20. The DAT 114 uses the DBOB 74 to access the monitoring data within database 80. In addition, the reports engine 116 of the DAT 114 utilizes an Open Database Connectivity (�ODBC�) connection to the database 80 in connection with data retrieval (
In addition to facilitating acquisition of the type of usage information outlined above, the DAT 114 allows the monitoring data collected by the client monitoring modules 20 to be queried in a user-defined manner. This feature enables generation of usage reports focused upon user-defined usage parameters. In a preferred implementation the DAT 114 is also capable of providing various representations of historical usage activity for individual users.
An exemplary set of such presentations are described below:
The DAT 114 also preferably allows comparison of the histograms or other usage representations of two or more users through, for example, superimposing the histograms or representations on the same portion of a display screen. Each of the compared histograms or representations may constitute an average taken over many users.
The DAT 114 provides representations of the activity history associated with specific applications. This type of representation will typically be generated by the DAT 114 on the basis of the monitoring data collected from a group of users and reported by the client monitoring module 20. Set forth below are an exemplary set of such representations specific to a particular application:
Referring to
A primary purpose of the DBOB 74 is to deliver appropriate objects to other requesting system components and to act as a common gateway for the relational database 80. In a preferred implementation a single DBOB 74 serves many instances of server module 22 20 (potentially on separate platforms), and each such DBOB is capable of accessing the database 80. This arrangement permits maximum utilization of certain finite resources, such as ODBC connectors. The interfaces of the DBOB 74 define the manner in which data within the database 80 is manipulated. In providing access to, and managing the database 80, the DBOB 74 isolates the low-level storage and methods used to access the database from the client monitoring modules 20 and other �clients� of the DBOB 74.
The administration console 144 is disposed to display an active client list, which allows the system administrator to monitor usage of the client computers 12. The administration console 144 will preferably allow a system administrator to determine if the client service 50 associated with a particular client computer 12 is installed and running. In addition, the administration console 144 is capable of causing a new monitoring profile 76 to be sent, by way of the applicable server module 22 20, to a client service 50 specified by a system administrator. The client monitoring agent 52 associated with this client service 50 then begins collecting usage data in accordance with the new profile.
Referring again to
As was discussed above, the client monitoring agent 52 generally uses one or both of two primary methods of collecting information relating to usage of application programs. In particular, a first technique involves injecting Hooks DLL into each application program that has been activated by the user. The Hooks DLLs are monitor prescribed Windows Hooks in the application programs and desktop environment so as to determine when specific user input events have been performed. In a second approach, information concerning usage of certain application programs may also be collected via Accessibility APIs. These Accessibility APIs allow more extensive information to be collected regarding usage of various application features.
The present invention also contemplates utilizing these methods of tracking application feature usage to restrict usage of application features. Advantageously, such restriction may be effected without modifying the application program in which restriction is to take place. Use of certain application features, or even access to entire application programs, can be restricted on the basis of individual user identity or group membership. As is discussed below, the ability to recognize the startup of an application program and the pending activation of an application feature via injected Windows Hooks and AppFeature DLLs provides an opportunity to restrict activation of the feature.
Usage of �transient� controls may also be restricted. Examples of transient controls are the buttons upon dialog boxes, which are created and destroyed in connection with each display of the dialog box. By trapping the user event indicating creation of a dialog, the recursive feature detection described above may be applied to disable the newly created control (i.e., the dialog box button).
Dialogs themselves, as well as other top-level windows of application programs, may also be restricted. Specifically, creation of the Accessible Object corresponding to the top-level window to be disabled is detected using Hooks DLLs as described above. This top-level window is then immediately closed and a dialog displayed indicating that use of the window is restricted. In order to avoid interfering with the timely processing of events, the dialog informing the user of the feature restriction is preferably displayed using a separate, dedicated process.
The feature restriction capability of the present invention may also be invoked to ensure that application programs permit only certain desired usage paths. Such desired usage paths may be developed by, for example, using monitoring data collected in the manner above to identify patterns of efficient usage. Once such patterns have been identified, usage of all unrelated features is restricted. Alternatively, a user could be �guided� through operations comprised of multiple steps. This is done by permitting the application program to enable only those features relevant to a current task to be completed. By limiting the set of features available during each task, the navigation of complex application programs offering many feature options may be appreciably simplified.
In another aspect of the present invention, the monitoring technology described herein may be embedded in an internet browser on a client machine so as to enable tracking of user interaction with the browser. Usage data collected by the client monitoring agent incorporated within the browser would be transmitted to the location of the server module 22 via an HTTP protocol POST operation. The URL to which the data was posted could reference a Common Gateway Interface (�CGI�) script disposed to read the posted monitoring data and forward it to the applicable server module 22 using the data notification scheme previously described.
A different approach may be taken to facilitate the monitoring of web-based applications built with JAVA, HTML, DHTML, Java Script, XML and the like delivered to host browsers via the world wide web (the �Web�). In this approach the client monitoring technology (�Collection Agent�) is embedded within the HTML document provided to the host browser via the web. By configuring the Collection Agent as a Dynamic Link Library (�DLL�) rather than as an independent executable program, its functionality can be packaged as an ActiveX Control or Netscape Plug-in or the equivalent. A reference to the control or plug-in is preferably embedded directly within the HTML document provided to the host browser. When the HTML document is fetched and rendered by the host browser, the object reference to the plug-in or control is resolved and the appropriate installation process begun. Depending on the current security settings in use on the client machine, the user may be unaware that a Collection Agent in the form of an ActiveX control has been installed. However, installation Collection Agents realized as certain types of plug-ins (e.g., a Netscape Plug-in) causes generation of a dialog allowing the plug-in to be accepted or rejected. An exemplary sample of HTML source containing a reference to an embedded ActiveX control is provided below:
By embedding reference to a Collection Agent only within Web pages desired to be monitored, targeted monitoring of specific Web pages may be effected without undertaking a mass installation of monitoring software within each individual client. The targeted monitoring of Web pages via a downloaded Collection Agent is of significant potential value to entities engaged in �e-commerce� and �e-business�. For example, an installed Collection Agent can provide nearly instantaneous feedback concerning the manner in which visitors interact with the applicable site. Such feedback may indicate: (i) whether users encountered any difficulties in utilizing the site, (ii) whether users hesitated while performing a given process or task, (iii) whether users abandoned an operation or task, (iv) to what sites users go upon leaving the monitored site, and (v) the manner in which users leave the site (e.g., via advertisement selection, other URL, text typed in the GOTO box, etc.). Information of this type is generally incapable of being derived from the logs conventionally maintained by web servers. These logs typically include information relating only to requests for, and postings of, documents.
Usage data collected by the Collection Agent may be provided to a server module 22 as described above. That is, the usage data would be transmitted to the location of the server module 22 via an HTTP protocol POST operation. A CGI script at the URL to which the data is posted would then read the posted monitoring data and forward it to the applicable server module 22 as previously described.
An example given below describes the adding of the onload property to the document in order to complete the instrumentation and start the monitoring of a web page.
In cases where the web pages to be instrumented are dynamically constructed via CGI execution or completion of a document template by way of a data base query, the instrumentation will often be integrated into the server setup and web page construction process at the applicable web site. This integration of instrumentation into each web page may be straightforwardly effected by using the �server side include� operations currently supported by nearly all commercial web servers. Such operations allow a reference to a document to be embedded in other documents. When a document is served to a client the reference is resolved and additional content written from the other document is incorporated within the data stream provided to the client. This avoids the necessity of issuing secondary requests from the client to fetch the contents of the reference.
Transmittal of monitoring data can also be performed using what is commonly referred to as a �hidden FORM�. Such a hidden FORM is constructed using elements of a FORM defined with <INPUT TYPE=hidden>, which are not visible to the user. A FORM containing a single hidden element can be used to transmit data to a server without altering the appearance of the web page in which it is embedded. A simple example of a hidden FORM is shown below:
A script may refer to the data item as myform.mydata and set the value to a string containing a compressed stream of monitoring data. The METHOD tag in the form definition controls whether the data is sent to the server appended to the ACTION URL (GET) or sent in the body of the HTTP request (POST). Examples are provided blow expressed in HTTP protocol notation.
The �hidden FORM� approach to data transmission has certain advantages relative to data transmission using cookies. For example, in the hidden FORM approach the instrumenting script enables control over precisely when data is sent. Specifically, the data may be sent to the server at any time by invoking the submit( ) method of the FORM. This is significant since it is preferable to send monitoring data to the server during times when the user is not initiating any other server requests in order to avoid the impression of degraded performance. The data should preferably be sent during periods of inactivity (e.g., when a user pauses to view text or images after a document is loaded).
Usage data collected by a Collection Agent or client monitoring agent can form the basis for providing essentially real-time assistance to end users. This may be effected by passing usage data through a structure (e.g., a decision tree or similar model) designed to detect situations where a user is in need of assistance. User behavior evidencing long pauses in certain fields, rapid switching among fields, repeated changing of control values, or aimless searching for features are likely indicators of user distress. Under such conditions a short list of subjects related to a best guess at the user's intention would be created and provided to the user. The user would have the opportunity to select an intention from the list, and optionally could indicate that operations associated with the selected intention be automatically carried out.
Since in certain implementations the collected usage data may only be intermittently reported to a server module 22, the above analysis may be conducted at the client In order to enable real-time assistance to be provided continuously. The module responsible for delivering such functionality (�Help Module�) is preferably implemented as an adjunct to the standard client monitoring agent. The Help Module informs the client monitoring agent of the data items needed to discern a user's action/inaction as it occurs. The Help Module need not be highly integrated with the client monitoring agent, and may simply be disposed to receive a stream of specified data items.
The profile builder 72 manages five main object types via its user interface (
The profile builder 72 supports different views of the database 80. The view displayed is dependent on the type of object selected in the tree view. Selection of a root node in the tree view will present a list of all items contained beneath that node. In the �User's view� of
From within the User's view, a system administrator is able to do the following: (i) modify the name of the user, (ii) modify the user's group, and (iii) explicitly assign the user's monitoring profile. This will result in overriding of the monitoring profile obtained through the user's group.
The profile builder 72 makes use of the database object broker 74 to manipulate profile database objects.
Referring again to
The database object broker 74 manages the persistence of, and relationships between, several types of objects stored in the Profile database:
Clients of the database object broker 74 will generally interact with objects that are �owned� by the database object broker 74. Furthermore, these clients will normally be operating on remote machines. The interfaces of the database object broker 74 will preferably be crafted to allow remote clients to manipulate the objects as efficiently as possible. Nonetheless, the database object broker 74 operates to protect the internal integrity of the Profile Database at all times.
All profile data is preferably housed in the Profile Database. The Profile Database is typically implemented using a relational database. Part of the task of the database object broker 74 is to store the various profile objects (User, Groups, Monitoring Profiles and Application Profiles) to the Profile Database. This generally requires the database object broker 74 to be capable of translating between relational table rows and COM or C++ objects. The database object broker 74 preferably uses ODBC to access the Profile Database.
The relationships depicted in
The Profile Database typically includes two �Default� objects: (i) Default Group, and (ii) Default Monitoring Profile. In a preferred implementation of the Profile Database these objects always exist and cannot be deleted or re-named. These objects allow database integrity rules to be followed without forcing cascaded deletes during certain object deletion operations. When a group object is deleted, integrity rules dictate that the users assigned to the group must be deleted also. However, with the introduction of the Default Group it is possible to (optionally) re-assign the users to the Default Group rather than delete them.
The Default Monitoring Profile works similarly. Database integrity rules dictate that when a monitoring profile is deleted, the delete must cascade to groups using the monitoring profile, since groups are required to have a monitoring profile. With the introduction of the Default Monitoring Profile object, it is possible to (optionally) re-assign these groups to the Default Monitoring Profile, rather than deleting them.
Table VI describes an exemplary set of default responses to error results from COM interface methods used by the profile builder 72. Certain exceptions to these responses are described on a per method basis in the tables that follow.
Table VII describes the responses of profile builders 72 to error results from the implementation of the IProfileObjects interface through the database object broker 74.
Table VIII describes the responses of profile builders 72 to error results from the implementation of the IProfileserver moduleEdit interface through the database object broker 74.
The server side components most directly associated with the Profile Management Subsystem are the database object broker 74 and the profile database 72. It is one of the primary tasks of the database object broker 74 to provide access to profile data for both Profile Management and Monitoring. In addition, the Profile Monitoring Objects created and edited by the profile builder 72 are stored in the Profile Database via interfaces of the database object broker 74.
Client Service
The client service 50 uses the IClientMonitoringAgent interface of the client monitoring agent to initialize and control the monitoring agent. Commands received via the ISageControlSink are passed through to the client monitoring agent. These include Suspend/Resume Data Collection and Profile Update commands. Also the client service 50 will synchronize the client monitoring agent before logging off to ensure that all data has been sent to the server module. When the client monitoring agent is initialized it is handed a pointer to the ICollectionStatusSink interface of the client service 50. The client monitoring agent uses this interface to provide feedback to the client service 50 regarding its state as well as to signal the client service 50 when data is ready for transmission to the server module 22.
The foregoing discussion describes the monitoring system in a fully connected and steady state mode of operation. As is described below, other relationships between the components of the monitoring system are established during initialization and termination of such operation. In a preferred implementation the client Service executes on the Client continuously, even in the event that a user is not logged onto the client. The client service 50 watches for certain events in order to initiate a conversation with the server module 22. Table IX describes the operations performed by the client service 50 in response to certain events:
In addition to watching for system events (in order to notify the server module 22), the client service 50 listens to the server module 22's outgoing commands via the callback registry. The notifications possible, along with the client service 50's response, are described in Table X. These notifications can only occur while the client service 50 is listening to the server module 22, which implies that at least one user has logged on.
These notifications can be targeted to all or to specific users managed by the client service 50. The server moduleShutdown notification results in disconnecting all client monitoring agents as well as the client service 50 itself. When reconnected, all current client monitoring agents are re-initialized and connected to the server module.
Control of Client Services
Control of client service 50 is performed via the ISageControlSink interface:
Client Monitoring Agent
The client monitoring agent is a COM object supporting only one interface. A primary purpose of the client monitoring agent is to monitor a user's actions on a client machine and report the monitoring results to the server module 22. In a preferred implementation, one client monitoring agent is associated with each user logon. For a Windows95 or Windows NT workstation, there will typically be at most one client monitoring agent active on the client. In the case of a Window's Terminal server module in which many users may be logged on, there will generally be one client monitoring agent per active (logged on) user. When the user logs off, the client service 50 removes the client monitoring agent. Each client monitoring agent will typically be unaware of the applicable server module 22, and will be aware only of its associated client service 50.
Referring the
The client service 50 uses the IClientMonitoringAgent interface of the client monitoring agent to initialize and control the monitoring agent. Commands received via the ISageControlSink are passed through to the client monitoring agent. These include Suspend/Resume Data Collection and Profile Update commands. Also the client service 50 will synchronize the client monitoring agent before logging off to ensure that all data has been sent to the server module. When the client monitoring agent is initialized it is handed a pointer to the ICollectionStatusSink interface of the client service 50. The client monitoring agent uses this interface to provide feedback to the client service 50 regarding its state as well as to signal the client service 50 when data is ready for transmission to the server module 22.
In a preferred implementation the client service 50 run continuously on the applicable client computer 12 even when a user is not logged on. The client service 50 watches for certain events in order to initiate a conversation with the server module 22. Table XII below shows the events and the actions taken by the client service 50 for each:
In addition to watching for system events (in order to notify the server module 22), the client service 50 is listening to the outgoing commands of server module 22 via the callback registry. The notifications possible, along with the response of the client service 50 are shown in Table XIII below. These notifications only occur while the client service 50 is listening to the server module 22, which implies that at least one user has logged on.
The notifications described in Table XIII can be targeted to all or to specific users managed by the client service 50. The server module Shutdown notification results in disconnecting all client monitoring agents as well as the client service 50 itself. When reconnected, all current client monitoring agents are re-initialized and connected to the server module. It should be understood that the client service 50 controls the client monitoring agent via the IClientMonitoringAgent interface, but that the client monitoring agent does not interface with the client service 50.
Relationship of Client Monitoring Agent to Client Service
The IClientMonitoringAgent interface is used to control the client monitoring, and is described below and in Table XIV:
Data Packet
Each data packet is fetched from the client service 50 by the server module 22, but is built by the client monitoring agent. When the size of the packet being currently assembled by the client monitoring agent exceeds the maximum size specified in the Monitoring Profile, or the reporting interval specified in the Monitoring Profile is exceeded, the current packet is streamed to a file and the client service 50 signaled with ICollectionStatusSink::Synchronize( ). The client service 50 will report the presence of ready data to the server module 22 via IdataReport::SignalPacketReady( ). The data packet object (an implementor of IdataPacket) shown in the argument list of the server module's ISageControlSink::GetNextDataPacket( ) is defined as:
An IDataPacket contains between zero and �k� TPersistentDataItems. The structure TPersistentDataItem provides a means to operate on an individual DataItem (a record of some desktop event), as an object.
The role of the IDataHeader is to tag the IDataPacket with an RFC822 style header containing name value pairs that serve to identify the data. Information such as sample time, sample sequence number, software version, userid, client IP address, etc. should be included here, along with the content-type label of application/x-sagedata. Ultimately, security related information such as a certificate could also be placed here.
This method enables the caller to get a stream to which the serialized state of the packet has been written. Each DataItem contained in the DataPacket represents an occurrence on the desktop, specified for collection by the Monitoring Profile loaded by the client monitoring agent. The DataItem is reported as a Meta-Event instead of as the raw information generated by the Accessibility Callback or Win32 Hook Filter Procedure which trapped the message. Condensing raw events into meta events advantageously allows the volume of data to be reduced and facilitates a simplified data base schema.
Data Header
The server module 22 calls ISageControlSink::GetNextDataPacket( ) on the client service 50 to pick up the next ready data packet. From IDataPacket the server module 22 gets a content stream and streams the packet from the Client to the DBOB 74. The DBOB 74 enters the DataItems into the DBMS 80 and then returns. On a successful return the server module 22 will call IDataPacket::DeleteFile( ). TPersistentDataItem is defined in the IEnumDataItems interface as follows:
Note that the DataItem is a container for an opaque object. Each occurrence on the desktop that is recorded has a definition known only to the client monitoring agent and the DBOB 74. The modules which handle the data before it is actually entered in the DBMS (client service 50 & server module 22) are aware only of the TPersistentDataItem. The actual type of data item is indicated by the type member and used by the DBOB 74 to cast the data member to the appropriate final type. The dataSize member is used only for marshalling the structure. Use of an opaque data type keeps the Interface Definition Language simple and the source code extensible without violating COM conventions for interface versioning.
Server Module
The primary functions of the server module 22 are:
The server module 22 typically runs on a central NT server as part of the Monitoring Subsystem. Although the server module 22 appears to connecting clients as if it were always running, server module 22 may be implemented as a COM object and therefore only needs to be executing if at least one client monitoring agent or client service 50 is currently connected. COM will arrange to re-start the server module 22 at upon each attempt to establish such a connection. The server module 22 maintains the following state information:
By �maintain� it is meant that applicable information persists regardless of whether or not the server module 22 is active or not. In addition to serving the needs of its clients, the server module 22 also functions as a node in an ordered network of cooperating server modules. In order to keep network bandwidth use to acceptable levels and manage database transactions, cooperation among the server modules on the network with a minimum of negotiation and communications is desirable. The need to provide centralized and effective management of the network also dictates that the servers have limited awareness of one another.
These considerations have lead to development of the hierarchical network of
Referring to
Relationship of Server Module to DBOB
Access Method to Profile Service
This is in essence an indirect profile request as the monitoring profile to be applied is one of the arguments returned by the Login method. The server module 22 consults the Profile Service, which replies with the defined profile most specific to the requester.
Access Method to Monitoring Data
Handling of Monitoring Data
Like profile information, monitoring data is modeled on the network as an instance of an object. The object implements IDataPacket and is NOT passed by value. The packet contains a set of data items, each of which describes an event that occurred on the desktop. Access to the data items as well as the header information carried by a data packet is provided through the IDataPacket interface.
Because data packets may be streamed (the packet object extends IContentSource) they can also be easily saved to a file (serialized). Serialized data packets existing outside the DBMS should be saved with a unique file type, * .pkt. Files of type .pkt shall be given the MIME Type application/x-sagedata and be associated with the Data Analysis Toolkit (DAT) in the registry.
When a client monitoring agent has a read packet of data it serializes the packet to a file and signals its client service 50 (ICollectionStatusSink::Synchronize( )). The client service 50 in turn signals the server module 22 (IDataReport::SignalPacketReady( )). The SignalPacketReady( ) method places the packet information on the packet queue and signals the thread which services the FIFO queue.
Upon being signaled the packet processing thread services the packet queue until it is empty at which time the thread returns to a dormant state. For each entry in the queue, the packet processing thread will call back to the appropriate instance of the client service 50 and get the next ready packets IDataPacket interface via ISageControlSink::GetNextDataPacket( ). The server module 22 treats the packet as an opaque object and streams it to the DBOB. The DBOB inflates the packet instance using the serialzed state from the stream. The DBOB then enumerates the Data Items and enters them into the appropriate DBMS tables. When control is returned the server module 22 the return code indicates whether or not all Data Items were successfully entered in the DBMS, if so the server module 22 commands the Data Packet to delete itself. If packet processing failed or was only paritally successful the packet will be requeued at a later time by the client service 50.
Note that the server module pulls data from each client rather than each client �pushing� data to the applicable server module. This architecture advantageously provides for improved data throughput by distributing the tasks of data processing across all cooperating objects.
Threading of Monitoring Data
The server module's need to efficiently handle the data reporting transactions initiated by its many clients, requires that the process of loading the monitoring data into the DBMS be as streamlined as possible. Getting the data into the DBMS represents the biggest factor controlling performance, heavily influencing the number of clients that a given server can handle.
Streamlining the data reporting process begins with the client service 50, which employs an asynchronous data signaling scheme. In accordance with this scheme, a data packet is not passed by value from the client service to the server module 22. The monitoring agent passes information identifying the ready packet to the server module 22 via IDataReport. This method simply places the packet informat on a queue managed by another thread, signals the thread, and then returns. The server module is then free to accept the next client connection. The main �packet manager� thread of the server module services each packet streaming the packet from the client service 50 to the DBOB. This asynchronous reporting scheme with data �pull� prevents the server from being overloaded by many clients attempting to report data concurrently.
Relationship to Client Service
In addition to watching for system events (in order to provide notification to the server module), the client service 50 is listening on the outgoing notification interface of the applicable server module 22. An outgoing interface may be realized similarly to a JAVA listener interface, except the source and sink (listener) objects can be on remote machines. The notifications, along with the action taken by the client service 50 are described in Table XVIII below. In a preferred implementation these notifications can only occur while the client service 50 is listening on the outgoing interface of the applicable server module 22. In addition, the client service 50 is configured to listen only during the time a user is actually logged in.
Networked server modules collaborate through use of the ISageControlSink interface described above (the same callback interface implemented by the client service 50). The UI of the Admin Console provides a means to configure the server modules to repeat commands to all subordinate server modules. From any arbitrary server connection, the Admin Console can propagate commands up to the root server module, which then propagates notifications down the hierarchy to the clients via the ISageControlSink interface. This feature provides a means to centrally and concurrently administer sets of server modules. In a large deployment, the ability to map the network of servers and delegate management of certain areas to sub-administrators eases administration.
Data Reporting Interface (IDataReport)
The client service 50 has exclusive use of the IDataReport interface. Through this interface a client service 50 notifies the server module 22 of ready data collected by its Monitoring. The data items contained within a report packet are then inserted into the database via the DBOB 74.
Servicing the Clients (ISageserver Module)
Interface ISageserver module is used by instances of the client service 50 to contact their assigned server module 22.
Administration/Configuration (Iserver moduleAdmin)
Used primarily by the implementation of the Admin Console and other servers modules, the Iserver moduleAdmin interface is used to configure and control a server module 22 and certain behaviors of its clients. The interface also provides generalized features such as:
Subordinate Server Control (ISageControISink)
The server module 22 also implements the ISageControlSink implemented by the client service 50. This interface introduces a level of polymorphic behavior shared by all objects that populate the distribution tree. Iserver moduleAdmin provides navigational capability while ISageControlSink allows actions to be applied to any object (client or server) in a homogeneous fashion. Though the interface is the same, the behavior for the server module is subtly different from that of the client service 50 implementation. Typically the events received via this interface are propagated to the subordinate servers and the appropriate client services designated in the callback. Whether or not the commands are propagated to subordinate servers is controlled by the ISageAdmin interface from an instance of the Admin Console.
Register Server Control (ISageCall/back)
ISageCallback is implemented by the server module 22 to allow clients to sign up as listeners on the outgoing interface of the server module 22. ISageCallback provides essentially the same semantics as the standard OLE interface IConnectionPointContainer, but can be more efficiently implemented. This same interface is used to register subordinate servers to receive the same callbacks.
Data Analysis Toolkit
The Data Analysis Toolkit (DAT) provides the means to view and compare the data collected by the client monitoring agents. The DAT is independent of the rest of the system components (except for the DBOB) and may be installed separately. The DAT packages a set of database queries and resulting reports and graphs into a unified user interface that is easy to use. As is indicated by
Graphical Presentations by User
The monitoring system of the invention enables analysts to view a history of activity by a single user. This includes the following presentations:
Graphical Presentations of User Comparisons
The analyst can view a comparison of multiple users to each other, and to the �average user�. In an exemplary �histogram comparison�, the histograms of two or more users are overlapped in order to compare the activities of the users. Information such as the type of applications used, and for what duration of time, may be compared. One of the histograms can represent an average of many users.
Graphical Presentations by Application
The user can view a history of activity by a specific application. This includes the following presentations:
Computed Fields
The DAT can be used to review significant information items calculated from the raw data contained in the monitoring data database, such as:
In addition to the metrics described above, the DAT should provide a means to allow the user to construct a query against the DBMS. This feature allows the person responsible for evaluating the reported data to generate custom reports and graphics.
Integration with the Reports Engine
As explained in previous sections, the DAT is primarily a wrapper for the Reports Engine (Engine). The Engine is responsible for querying the database 80 and displaying the formatted results. The DAT functions only to provide a means to select and customize reports and manage the Engine. In a preferred implementation a Crystal Reports Designer, not the Engine, constructs report templates.
Each report template can be used by the DAT to create a report instance. Various template �parameters� can be used to customize each report instance. Perhaps the most important customization is the range or volume of data to be included in the report. This is done by manipulation of the �where� clause of the query that is part of the report. In addition, the Engine allows setting of various attributes of a report. Text items such as titles, chart types, header and footer items can be customized. However, the template and the associated query determine the basic layout and data schema of a report and cannot be changed within the DAT.
Handling of Data Analysis Reports
A significant aspect of the DAT architecture is that all report templates, report template parameters, and report property page specifications are held within the database 80 and read by the DAT. This makes it possible to extend the reports supported by the DAT simply by adding report specifications to the database 80. Table XXIII lists the components included within a report specification:
Exceptions and Error Handling
Table XXIV below describes the default responses to error results from COM interface methods used by the Data Analysis Toolkit. Any exceptions to these responses are described on a per method basis in the Tables that follow.
On the server side, the DBOB provides access to the Data Analysis Report objects that help to define the reports to be generated from the monitored data. Access to the actual monitor data is by direct access to the Monitoring Database via the Reports Engine.
The DBOB functions as a gateway to the Profile, Monitoring Data, and Report Template Databases. The DBOB represents data in each of these databases as independent objects. The DBOB provides a set of interfaces that support access and manipulation of these objects. The DBOB is ultimately responsible for the consistency of the objects relative to the data in these databases. The interfaces of the DBOB completely define how the data within the databases may be manipulated.
In providing access to, and managing databases, the DBOB isolates the low-level storage and methods used to access these from its clients. Clients of the DBOB see the data objects in a way that is natural to the client, rather than as database rows and columns.
Because the Profile builder requires read/write access to the Profile database, and multiple instance of the Profile builder may exist, the DBOB supports multiple simultaneous writers using a mechanism such as transactions or record locking.
Relationship to ODBC Data Base Management Systems
The DBOB isolates the use of ODBC to a single module and exposes the profile management interfaces as well as the data reporting IDataRepository interface. The DBOB is a public service available through the server module 22. The primary users are the server module 22 itself and the Admin Console. The Profile builder and Data Analysis Tool each make direct connection to the DBOB for access to the Profile and Report Template Databases.
The DBOB is primarily useful in connection with profile management, organization of data entry, and management of archived data. Queries are carried out via ODBC, using standard SQL queries serviced by the SQL server of the DBMS of choice. The DBOB is not involved in query operations. This makes it possible to employ commercially available graphing and analysis tools in the design of the Data Analysis Toolkit (DAT).
Relationship to Admin Console
Referring to
Relationship to Server Module
Referring to
Relationship to Profile Builder
Referring to
To support these requirements, the profile builder requires read-write access to data served by the DBOB. Furthermore, the DBOB is preferably prepared to handle multiple simultaneous profile builder clients as shown in
Relationship to Data Analysis Toolkit
Referring to
The DBOB also uses the Iserver moduleAdmin interface of the server module 22. The interfaces are explained in the following sections.
The IDataRepository is used put data items collected from client monitoring agents. It is defined as follows:
IProfileserver module
The IProfileserver module interface is used to retrieve a user's monitoring profile info. The definition is a follows:
The method, IProfileserver module::GetUserProfileInfo( ), is specifically designed to provide the server module 22 a means to retrieve the complete Monitoring Profile for a user. The DBOB resolves any profile assignment conflicts using the monitoring profile precedence hierarchy. It also merges any application profiles so that the features to be monitored are unambiguously defined. The resulting user profile info retrieved is current only for the time of retrieval. Subsequent changes to the user profile will require another fetch of the user's monitoring profile info. In other words, the retrieved COM object held by the DBOB is not synchronized with the Monitoring Profile database.
The IProfileObjects interface gives clients the ability to enumerate all the possible objects in the Profile Database. It is defined as follows:
The enumeration methods, IProfileObjects::EnumXXXs( ), each provide an enumerator the client can use to enumerate over each of the primary object types stored in the Profile Database. In each case, the type returned by the method is the same. It is an enumerator that delivers object IDs and Object Names for the object type being enumerated. The full declaration of IEnumProfileObjects is shown below.
As indicated by IEnumProfileObjects::Next( ), this enumerator allows the client to enumerate a series of structures, TProfileObjectDigest, that contain an ObjectType, ObjectID, and ObjectName and ObjectDescription. The ObjectType is an enumeration designating the type of profile object. The ObjectID is a unique number that identifies the object. It cannot change for the lifetime of the object. The ObjectName is a unique display name shown to human users. Although unique, the ObjectName can be changed during the lifetime of the object. ObjectDescription is a brief description of the object displayed to human users.
Profile Database Object Interfaces
Objects within the Profile Database are exposed to clients of the DBOB as COM objects. The profile database objects, and their interfaces are depicted in
All Profile Database objects have a name and ID. The name is intended to be displayed to users. Although the names are required to be unique within each object type, object names can change during the lifetime of the object. An Object's ID is a system-assigned, immutable, unique (within each type), identifier for the object. The interface below is the base interface for all profile database objects. It allows retrieval of the object ID and object name. It also allows the name to be changed.
The IAppProfile interface provides access to application and feature information for a specific application profile.
The enumeration method, Enum Features( ), provides an enumerator to access all features associated with the application profile. The full declaration of IEnumFeatures is shown below.
As indicated by IEnumFeatures::Next( ), the enumerator fills a structure, TFeatureDigest, that contains general information relating to the specific feature. Detailed information for the feature is obtained through the IFeature interface, as described in the next section.
The IFeature interface provides access to information obtained through Active Accessibility.
The enumeration method, EnumFeatureAncestors( ), provides an enumerator to access all ancestors associated with the feature. Ancestry information defines a hierarchy of user interface windows related to a specific feature. The full declaration of IEnumFeatureAncestor is shown below.
As indicated by IEnumFeatureAncestor::Next( ), the enumerator fills a structure, TFeatureAncestor, that contains information relating to the specific feature ancestor.
IProfileserver moduleEdit
IProfileserver moduleEdit allows creation, deletion and editing of all profile database objects. The complete interface is shown below:
Report Database Object Interfaces
Objects within the Report Database are exposed to clients of the DBOB as COM objects. The report database objects, and their interfaces are depicted in
To access a specific report object for a report digest enumerated above, the following interface is used:
The definition of the server module 22's IDataManagement interface is shown below:
The GetModel methods of IDataManagement allow the model dictating how and when data is condensed (archived) or truncated to be fetched and configured. The DBOB associated with a given server module 22 implements these interfaces but applies active data management only to data collected by the server's clients. In this way concurrency problems that arise when multiple threads attempt to groom the data are avoided.
Use of Iserver moduleAdmin
When a Profile changes, the DBOB may be instructed to (optionally) notify the root server module 22 installation in order to inform it of the users who have been affected by the profile change. The root server module 22 can then instruct all other server module 22 s in the system of the profile change.
In order to notify the root server module 22 of a Profile change, the DBOB will use the Iserver moduleAdmin::GetSuperiorserver module( ) method of its corresponding server module 22 to navigate to the root server module 22. Once at the root server module 22, the DBOB will use the root server module 22's Iserver moduleAdmin::RereadProfile( ) method to inform the server module 22 of the profile changes. It is then left to the root server module 22 to inform all subordinate server module 22 s of the change.
Exceptions and Error Handling
Table XXXIX describes the Database Object Broker responses to error results from the server implementation of the Iserver moduleAdmin interface.
System Administration Client Side Components
Admin Console
The Admin Console is a tool typically used by system administrators. Through the Admin Console, the administrator sets up and configures the network of server modules that collectively make up the monitoring system. Through the Admin Console the administrator can determine whether a specific system is running, and if so, if it is running a client service/client monitoring agent. This feature allows the administrator to identify when the monitoring process has been circumvented, and also enables debugging of configuration problems. As was discussed above, a server module is aware of its subordinate servers and it's superior. With appropriate permission, the administrator may traverse the tree of server modules and perform administrative tasks at any node.
Relationship Between Server Module and Admin Console
To ease the problems associated with administering a large network of servers, certain operations performed on a server via the Admin Console may optionally be repeated to all subordinates of the server to which the command was issued. The means to traverse the server tree, repeating a given command, is provided by the navigation methods of Iserver moduleAdmin. Such propagation of administrative commands through a server tree is illustratively represented by
Referring again to
Pinging Client Service to Determine Status
Periodically, an administrator may wish to dynamically inquire about the status of the client service 50 on a remote client machine 12. The client ping feature of the Admin Console does not use an ICMP ping packet, which would verify only the presence of the target machine on the network. Instead, the Admin Console implements a ping which verifies not only that the client machine 12 is up and running but also that the client side monitoring software is installed and running as well.
Referring to
Relationship to DBOB
UI Design
Through the Admin Console UI, the administrator manages the server modules and their associated DBOBs. The administrative tasks are divided among the following functional areas:
In a preferred implementation the Admin Console UI has a single top level window divided into two panes (side by side). A tree view is presented on the left, which is always visible. The right hand pane is occupied by a tab box, which allows the user to choose between the functional areas identified above. The data presented in each tab is a function of the server to which the Admin Console is currently connected.
Server Module Tab
Referring to
From within this tab the administrator may perform the following administrative operations:
Whether or not operations are applied recursively to the subordinate servers of the current server is a function of the �Repeats Operations on Subordinates� check box.
Data Management Dialog
Client Tab
Event Log Tab
Status information such as commands repeated by the applicable server module, as well as restart information and the like, may also be shown. The log depicted in
A primary goal of the web-based monitoring system of the present invention, hereinafter �NetEchoes��, is to produce a system capable of monitoring user interaction with the world wide web. While the implementation of NetEchoes� may be different from the implementation described above, a similar level of monitoring detail may be effected in each case. In comparison with the server log file analysis tools widely used today, both NetEchoes� and other implementations of the present invention facilitate collection of data in greater detail and production of entirely new categories of data metrics.
By implementing web-based monitoring in a language used to construct web-delivered applications, the monitoring system itself can be embedded in any web page. This negates the need for a separate installation step on the client and allows the sample of users monitored to grow almost without bound. Whenever a user loads a page containing the embedded monitoring, the browser responds by initializing the monitoring system (subject to the security settings of the browser).
The monitoring of web pages via an embedded JavaScript module is extremely valuable for e-commerce and e-business web sites. It allows for instant (realtime) feedback on how visitors are interacting with the site.
Questions such as:
This monitoring technology could also be applied to a sample of users who have intentionally elected to permit the monitoring system to monitor all web activity. The data collected could be used to produce ratings of web sites similar to the Nielsen system currently applied to select television viewers. This data would not be anonymous. The demographics of the users would be well known. This type of information is very valuable to advertisers. An internet service where advertisers could enter a description of their target audience and receive a list of the top ten recommended sites to place their add would likely be an enormous success.
User Monitoring vs. Server Module Monitoring
There are two general sources of web usage data; user data and server log file data. User data contains very detailed information regarding every site the user has visited and the type of actions performed by the user at those sites. Server module logs contain very granular information regarding activity of all users of a single site.
Many products exist to perform analysis of server log file data. The data is generated automatically by the server making it essentially free and the tools themselves are relatively inexpensive. The information in the logs is relatively easy to interpret and provides valuable information to the operator of a web site. For example, a web site operator can use server log data to:
An example of the contents of an HTTP server log is shown below. Each entry shows various information such as the requester, the time, the protocol operation (GET, HEAD, POST, etc.) the page requested and information regarding the browser which issued the request.
The server log contains a great deal of data about what requests (hits) were made of the web server, but does not contain any data about the users' experiences with the pages viewed. Analysis of the data can yield the answers to many important questions about the performance and page volume handled by a server but it can never provide much information about the users interaction with each page.
Data collection performed at the client within the browser yields all of the server-collected information, but can also yield a much richer stream of data that includes details of the user's interaction with a page. These details serve to fill in the gaps in the information offered by a server log and can be more accurate. One reason client side monitoring is more accurate is the ability of web browsers to �cache� pages so that a second, or subsequent visit to a page does not generate a �hit� to the remote server, but rather the browser simply pulls the page from its local disk cache. There are actually two kinds of page caching, caching by the browser and caching by a proxy server. The goal of both schemes is to improve performance from the perspective of the user. Caching has the effect of hiding page load activity from the server. Recent figures suggest that server log file analysis fails to show as much as 20 to 40 percent of a sites real traffic. Many ISPs such as America Online (AOL) operate massive caching schemes in order to deliver higher performance to their subscribers.
For many web site, tracking page view data is essential. Many sites generate revenue on advertising banner �impressions.� More accurate page view data tracking both cached and non-cached pages may result in additional revenue.
If an ad is placed at the bottom of a page there is a high likelihood that it will not be initially visible when the page is loaded and many users will not bother to scroll down to expose it. Data which could prove that an ad was actually viewed would be help the seller of ad space price their page �real estate� appropriately and assure a buyer that their money is not being wasted.
Web Documents
The producer of Web content develops a site using combinations of HTML, JavaScript, and embedded objects such as applets, Active-X controls, and plug-ins. The development of sites has continued to progress and advance with introduction of new technologies and techniques. These technologies on the client side have been packaged into what is now called Dynamic HTML or DHTML.
The following briefly defines the technologies used to build web content and their utilization in connection with NetEchoes�.
Hyper Text Markup Language
Hyper Text Markup Language or HTML provides hypertext links that allow the user to move to different pages. Originally, HTML allowed combinations of rich text and images to be viewed with a Web Browser with the content being retrieved from locations anywhere on the Internet, forming a World Wide Web. HTML has since progressed to provide a number of different ways that content can be presented. A plethora of new mark up tags have been introduced that control not only the content but also every aspect of content; presentation, location, indentation, font type, font size, font style, etc.
Besides anchors, two aspects of HTML presentation may be particularly useful in the context of NetEchoes��frames and forms. Frames allow content from different locations to be presented at the same time. Various issues surrounding the implementation of frames are described below.
Forms allow users to provide information via input elements such as buttons and text fields capable of being tracked by the web-based monitoring system. These are the items that must be observed and measured, and depending upon the browser, are presented as different window objects.
JavaScript can be included in an HTML document using the <SCRIPT> tag. It can perform functions on the client side without having to connect with the server. For example, forms can be verified to contain the correct entries before they are submitted to the server. Also with JavaScript, the page can respond to the user actions, such as changing the button image when the mouse pointer moves over the button, or the button is pressed.
JavaScript acts on objects that make up a Document Object Model. The DOM identifies what objects within a document can be observed by a script and what actions can be performed on these objects. Therefore, the actions that can be performed using JavaScript depend greatly on the DOM.
Applets are written in a platform independent language�Java. In particular, they can be included within the content on an HTML document without user interaction and in most cases without user notification. Applets operate with security restrictions that limit their scope to an HTML page and limits their communications to the originating server of the page. With JavaScript, using Netscape's LiveWire or Microsoft's Active-X technologies, scripts can interact with applets and vice versa. Therefore the scope of the applet has been extended to cover the document in which it is embedded and even allows applets within the same page to communicate.
Like other embedded objects, the challenge to NetEchoes� is observing and tracking the activity the takes place within the applet. The implementation of Java's Graphical User Interface objects can be different depending upon the operating system and browser.
Plug-ins and Active-X Controls
Like applets, Netscape Plug-ins and Microsoft Active-X Controls, are embedded objects within an HTML document that allow the user to extend the functionality of the document. Unlike applets, these components must be installed on the client prior to their activation within a Web page. They require user consent and action. Active-X controls can more or less be installed automatically after the user has given consent, and under certain circumstances, the user's consent is not necessary. Netscape plug-ins usually require restart of the browser before they can be used, and require considerably more interaction by the user.
Once installed, the plug-in or Active-X control is activated by an <EMBED> or <OBJECT> tag within the document, typically to handle a MIME type not handled by the browser itself. The embedded object is deactivated when the user moves to another page. Once activated, they have full run of the computer system, i.e. there is no security context around the object like that of a Java applet.
Like applets, Plug-ins and Active-X controls are open to full interaction with JavaScript and are enabling technologies for NetEchoes�.
Dynamic HTML
Dynamic HTML (DHTML) is an attempt to extend the document object model and separate once again style from content markup through Cascading Style Sheets (CSS). The DOM standardizes and extends the number of objects that can be observed and manipulated by a script, such as Java Script, JScript, even Perl.
CSS greatly extends the control of style aspects of presenting the content, while removing a number of tag attributes in current HTML. The cascading refers to the context of a style sheet�embedded specific to an instance, global effecting the entire document, user preference defined by a user, etc.
Document Object Model (DOM)
All scripts embedded within an HTML document operate upon a Document Object Model (DOM). The W3C is attempting to develop a standard model with both Netscape and Microsoft. This standard DOM would allow scripting languages to be embedded in HTML documents and have access to the same document objects. Currently each browser exposes both window and document objects that can vary from one browser to the next. These objects are referred to as the Web Browser Object Model (WBOM).
The insertion of attributes to capture events for NetEchoes� is referred to as instrumenting the HTML. Before addressing instnnnentation the objects that populate the DOM are presented. The following summarizes each object and the attributes and events associated with each object.
Window Object
The Window object represents the object itself and in particular, the content area of the document. From the highest or Top window, the browser state can be determined, and some aspects of the browser controlled. For example, new windows can be opened and the scrollbars controlled. For frames, the window object provides links to the parent window and to sibling windows.
Though windows can be created and their content scrolled, the ability to know what content is being display is curiously missing. DHTML does provide extensions in the window object allowing measurement of mouse position within an HTML page and the size of the viewing area.
The event model has been expanded in both Netscape 4.0 and Internet Explorer 4.0 to measure mouse events and keystroke events relative to targets objects within the page. Thus window events in general can be monitored from <BODY> or <FRAMESET> tags without having to instrument all tags within an HTML page. This greatly simplifies the instrumentation having only to append attributes to the <BODY> or <FRAMESET> tags. An example of this instrumentation technique is presented in the section entitled �Instrumentation of Web Documents�.
Location Object
The properties of a location object can be changed as well as observed. This provides a mechanism for navigating via JavaScript as well as passing content back to the server.
History Object
The history is a protected or trusted object in Netscape requiring signed scripts and HTML to allow permissions to be granted by the client. With Universal Browser Read privilege, the script can access the entire list of sites visited during this session. With Universal Browser Mail privilege, used to generate a form letter to filled and sent from the client, the script can access the email address.
Document Object
The document object is the central or root object for accessing all the objects within an HTML page. Associated with the document are a number of methods that allow content to dynamically written to the browser.
Typically attributes are read only. The document's location is read only. However the window's location, which has essentially the same information, can be set causing the browser to load the new URL.
Note that in the list above, one gets a fairly complete view of the document including all tags or elements if necessary. Accordingly, the NetEchoes� implementation does not require objects to be probed for using Microsoft Active Accessibility (MSAA). Link, Area, Anchor Objects
Note that the Link and Area objects are implemented as Location Objects allowing links to be manipulated.
Form Object
The form object is important since it represents, aside from the link, the most user action intensive aspect of an HTML page. From the Form object the user entries for each element and the submit and reset buttons are observed.
The form elements are listed with the form object and the following gives the properties and events that can be observed for each element.
With DHTML, every HTML element and its attributes can be accessed. What can be done with these objects varies between Netscape4 and IE4. In both cases, the Style using <STYLE> tags can be applied to these objects to effect any aspect of the element style�including fonts-type, font-size, borders, padding spaces, etc. JavaScript supporting the generating of the <STYLE> tags on the run and also changing the presentation of the element during runtime.
Embedded Objects
In a cooperative environment, where the producer desires specific measures to be performed, the embedded objects that must be monitored can be instrumented to provide the measures such that the monitoring and measurement can be integrated via JavaScript and other embedded controls.
For example, suppose a producer wants to measure whether or not specific places within his web site are viewed by a customer. By inserting a �cooperative� applet that reports number of paints, one can determine whether an area is exposed and for how long, and by measuring mouseovers, one can determine if the user even anticipated following a link. For Java applets, additional instrumentation can be added to measure activity within the applet either through instrumented packages for observables, an �accessibility� API, or even �wrapping� existing Java objects.
If the producer wishes to encourage and extend monitoring of its content, a more direct means of measurement can be incorporated. If the presentation of the content depends upon popular plug-ins or ActiveX Controls that have already been installed by the customer, then via JavaScript and Java wrappers, the functions of these embedded controls can be monitored as well.
NetEchoes� Overview
Steps involved in Producer/Browser/NetEchoes� server module relationship.
NetEchoes� Client
This section describes the technology employed on a NetEchoes� client within and HTML page loaded by a browser.
Event Handling within the DOM
In the previous sections tables were presented identifying event handlers like onmouseover as properties of an object of the DOM. These properties may be assigned by a script or they may be expressed as the values of HTML attributes belonging to an object in the DOM. For example, the onload event handler can be specified with the onload attribute of the <BODY> tag and the on Reset event handler can be specified with the on Reset attribute of the <FORM> tag. This synergy between the HTML markup language and JavaScript reflect the integration of scripting with the DOM. The value of an event handler may be set to an arbitrary string of JavaScript code but typically a function is defined and the handler assigned to the function definition.
Table XXXXXV presents the least common denominator events that exist between the Netscape and IE implementations of JavaScript. The third column indicates the object or objects which support the event type.
In addition to the event handlers discussed above a more generalized event processing exists in both the IE and Netscape versions of JavaScript. Both Netscape and IE have the concept of an extension to the core client-side event model commonly referred to as the �fourth generation� event model. This name refers to the appearance of an Event object in IE 4 and Navigator 4.
Table XXXXXVI outlines the properties of the Event object and the differences in the object's properties between IE and Netscape.
Access to the Event object in Netscape is via an argument passed to the event handler. In IE the Event object is available via the global variable event.
As mentioned previously, reconciling these two different event models is not difficult; it requires some code to detect the browser and take different action depending on it. An example of an event handler which functions equally well in both the Netscape and IE environments is show below:
The last major difference between the Netscape and IE event handling models is how events propagate through the hierarchy of objects occupying the DOM. Netscape uses an event �capture� model while IE uses an event �bubbling� scheme.
The Netscape model introduces new methods on the Window and Document objects to allow specified events to be captured, giving the script a chance to process an event before the object which actually generated it. When handled, the event can be inspected and then either discarded, forwarded to the source object, or rerouted to another object or handler.
Because IE 4 includes all HTML elements in its DOM event handlers exists on all the elements. The presence of consistent event handlers on all objects in the DOM allows events to be generated and then propagate up through all containing HTML elements to the Document and Window object. At any point during this process the propagation of the event through the DOM can be halted by setting the Event's cancelBubble property.
The richness of the JavaScript event model and the synergy between JavaScript and the objects occupying the DOM, allows for the creation of a script which can interrogate the DOM for its constituents and then set handlers which provide feedback on the user's interaction with the document. This process is referred to as instrumentation.
All of the properties of any element within a page are available and can be modified regardless of how the page was generated or customized. This means that the instrumentation can be performed during and after download on the client. No server instrumentation is required except the incorporation of the NetEchoes� script in the page somewhere in the <BODY> of the document to be instrumented.
NetEchoes� �Tag�
An HTML document is instrumented by the placement of a <SCRIPT> tag (indicating the presence of a JavaScript) within the body of the document. One of the important aspects of this tag is that the JavaScript referenced can be delivered from an alternate web server�it need not be the one that delivered the other document content. The HTML fragment below illustrates the general pattern of the tag and its placement within the document:
In this fashion, the script is delivered from an alternate web server (distinct from the content server), potentially by a partner the producer works with.
Instrumentation of SSL-Delivered Pages and NetEchoes� �Smart Tag�
Most commonly used web pages are delivered using the HTTP protocol. By default the NetEchoes� instrumentation script and collected data are sent using HTTP. However, frequently data is deemed sensitive and transmission using a Secure Sockets Layer (SSL) is commonly used. SSL transmission sends only encryption data across the internet. It the primary method used to deliver sensitive information such as credit card numbers and user passwords across the internet. In the case of SSL delivered pages, the NetEchoes� tag embedded on the page must reference the instrumentation script using SSL and the script must deliver the data using SSL. To simplify this process a �smart� NetEchoes� Tag has been developed which is suitable for use on both secure (SSL-delivered) pages and unsecure pages. The general pattern of the tag is illustrated below:
This smart tag detects the protocol of the page upon which it is embedded: either secure (https) or unsecure (http) and adjusts the URL and script delivered appropriately.
Instrumentation of the Document
Dynamic Augmentation of Existing Event Handlers
In the following, we use the �onload� event of a document to illustrate to concept of Dynamic Augmentation of Existing Event Handlers, but the concept applies to dynamically augmenting the handler for any event.
The event handlers of a page can be set up by the producer in one of two patterns. The first is as a attribute of an HTML tag, the second is as the setting for a JavaScript property. These are illustrated in
Event handlers are commonly specified in commercial web pages using both of these methods. In dynamically augmenting these handlers, NetEchoes� must replace the existing handler (in this case on LoadHandler( )) with a new event handling method that both preserves existing behavior and adds the necessary NetEchoes� behavior.
Assume for the moment that NetEchoes� behavior is embodied in the JavaScript method netEchoesOnLoadHandler( ). Then, in the augmented case, the onload event must execute both the existing on LoadHandler( ) and the new netEchoesOnLoadHander( ).
The Dynamic augmentation arranges for this to occur by dynamically creating a third, anonymous function according to the following pattern:
This new function replaces the original handler (on LoadHandler( )) as the new handler by setting the appropriate JavaScript property:
This example is a simplification of the dynamic augmentation process. Other aspects that must be addressed include:
The JavaScript source for the complete handler augmentation is listed below.
In a preferred implementation NetEchoes� is designed to accommodate users of phone modems with speeds as low as 28.8 kbps. Accordingly, the size of profiles downloaded to clients from the server module need to selected appropriately. In addition, the HTTP protocol is �connectionless�, and thus requires that a new connection to the remote HTTPD server be made for each request. A request for a user profile therefore requires a new connection across the internet and the download of a potentially large document. Note that the instrumentation of the document takes place immediately after the document is loaded. From the user's perspective, any additional data transfer at this point would have a noticeable effect on the response time of the browser. In light of these issues, the NetEchoes� product either collects all features and organizes them through post processing or performs a variation on profiling by using a custom instrumentation script that instruments only the portions of the document that are of interest.
Instrumentation of Applets, Plug-ins and ActiveX Controls
Regardless of the JavaScript implementation, embedded objects such as ActiveX controls and applets are accessible via the document object arrays. The document object has array properties which contain references to applets, embedded objects (ActiveX controls) and in the case of Nets cape, plugins.
Feature Tracking
Within HTML pages, features (UI controls) can only appear within the context of HTML forms. Tracking features then, is the same tracking controls on forms. In general, the controls generate JavaScript events when they are used. This makes is especially easy for NetEchoes� to track the details of what goes on in forms. Table XXXXXVII presents the possible form controls along with the properties and events available from within JavaScript.
As Table XXXXXVII illustrates, most controls have a value and name, plus events such as onclick( ) or onchange( ) that make the use of them inherently trackable.
Standard Data Collection
Table XXXXXVIII below lists the client-side data that is collected by the standard instrumentation script.
From these collected measures, all the questions first proposed can be answered:
Transmitting the data collected by the instrumentation script back to a remote server elsewhere on the internet poses several problems. First, in order to pass through the intervening appliances on the net such as firewalls and routers, the connection must be made on an open port. The solution to this problem is to use port 80, the HTTP protocol port. It is on this port that the user fetched the instrumented page in the first place. It is therefore the logical means to send the collected data back.
These three alternatives are described below. The most promising of these is the data transmittal by 1�1 pixel image request. This method is currently in use for NetEchoes�
Data Transmittal by 1�1 Pixel Image Request
Generally speaking, a JavaScript operating within an HTML page has very little networking privileges. It cannot arbitrarily send data across the network. In fact, the only networking capabilities available to JavaScript is the ability to request an image from a remote server. A JavaScript fragment illustrating this capability is shown below:
The above fragment makes network request of the http server at www.keylimesoftware.com to obtain the image file logo.gif.
Interestingly enough, an inherent capability of URL requests is that they can be accompanied by a parameter specification also known as a �query string� within the URL. The query string is set off in the URL by the use of a �?� character and is of unlimited length. (The details of a URL format can be found in the W3C committee HTTP 1.1 protocol specification.) Therefore, the JavaScript request for an image file can be accompanied by an arbitrary data payload disguised as a query string.
Using this technique, the previous JavaScript fragment used to request an image can be adjusted to deliver a data payload.
The web server at stats.klsoft.com can be adjusted in a number of ways to record the data payload sent along with the image request. The easiest way is to configure the web server to create logfiles containing the complete text for every URL requested. In this way, the payload data sent as part of the URL will appear in the server log files.
Data Transmittal with Cookies
Cookies are often used to give the illusion of persistence over the connectionless and stateless HTTP protocol. They were originally created to support CGI programming and are implemented as 30 an extension to the HTTP protocol. The data in cookies is automatically transmitted between the browser and the HTTP server without the knowledge of the user.
A cookie consists of a named value, plus four optional properties which control the lifetime, visibility and security of the cookie. The lifetime parameters are defined below:
The cookies associated with a particular page are made available to JavaScript through the cookie property of the document object.
Using cookies as a means to transmit data to the server requires that the data be sent in chunks with a size of 4 k bytes or less. The maximum size of a cookie, including the NAME of the cookie, is 4 k. Note also that the visibility of the cookie will have to be adjusted such that the value of the cookie is transmitted when a request is made for any document at the source site.
When the user leaves the site where the instrumented page was encountered, the last block of data must have the Expires property set in order to persist the value of the cookie on the client until the next time the user connects to the source site.
To avoid overflowing the 4 kb limit on cookie size, the instrumentation script could take advantage of compression as well as the use of multiple cookies. The maximum number of cookies that a browser is required to manage is 300, more than enough for the purposes of NetEchoes�.
Data Transmittal with Hidden FORM Fields
Transmittal of monitoring data can also be performed using what is commonly referred to as a hidden FORM. Elements of a FORM defined with <INPUT TYPE=hidden> are not visible to the user. A FORM containing a single hidden element can be used to transmit data to a server without altering the appearance of the HTML page in which it is embedded.
A simple example of a hidden FORM is shown below:
A script may refer to the data item as myform.mydata and set the value to a string containing a compressed stream of monitoring data.
The METHOD tag in the form definition controls whether the data is sent to the server appended to the ACTION URL (GET) or sent in the body of the HTTP request (POST).
Examples are provided blow expressed in HTTP protocol notation.
The hidden FORM approach to data transmission has an advantage over the cookie method in that the instrumenting script has control over when the data is sent. The data may be sent to the server at any time by invoking the submit( ) method of the FORM.
Controlling when data is sent is possibly more important than how. The script embedded in the instrumented page must strive to send monitoring data to the server at a time when the user is not initiating any other server requests otherwise the user has the impression of degraded performance. Ideally the data should be sent during periods of inactivity such as when the user pauses after a document has loaded to view text or images.
Customizing Data Collection
In addition to the standard metrics collected, the instrumentation script can be customized to collect any additional information (visible to JavaScript) for the page view.
Bag Of Tags
In addition to customization of the JavaScript, the basic script itself provides a way for producers to adjust the information delivered by interacting with the script on the page. Simply by setting a property, the client can deliver �free-format� data to the NetEchoes� server. More specifically, the producer can embed JavaScript like that shown below onto the page:
Statements such as these, give the �epulse-info� property values that are transmitted back to the NetEchoes� server module. The NetEchoes� server module can then take special, site-appropriate action with this data.
Segmenting Users Based on Behavior
Because the session model for contains all the details of the users segment, the DataMining server can include custom logic for each site that scans user sessions to identify desirable user behavior. Those quality behaviors can then be permanently associated with the user in question. In this way, when the user returns for successive sessions, the user's history (in terms of his quality behavior) can be queried from the DB. There is a variety of use for such information, including incorporation into personalization systems, reports, etc.
Complete NetEchoes� Instrumentation Script
Appendix A includes the complete Netlichoes� instrumentation script. Although potentially customized to collect additional data, all other scripts are derived from the basic pattern set forth in Appendix A.
NetEchoes� Server
The NetEchoes� server components are independent from both the Producer Web Site and the Browser. They are typically housed in a separate data operations center. The data operations center houses computer hardware that provides the NetEchoes� server capabilities. NetEchoes� server components provide a wide variety of capabilities, including serving up the instrumentation script, receiving the collected data, publishing reports showing real-time user activity, etc. However, a significant aspect of the NetEchoes� server is real-time modeling of user sessions:
Real-Time Modeling of User Sessions
As collected data is received from the Instrumentation Script, it is immediately loaded into the memory of the DataMining server (a NetEchoes� server sub-component). The purpose of the DataMining server is to take collected page view data and construct an in-memory model of each in progress user-session on the instrumented site. The in-memory model includes all of 3 the relevant information about the session including:
The information for all active (in-progress) user sessions is kept in-memory for as long as the session is active. However, as the session state changes (new information pours in from the client) the session state is also persisted to a relational data store. In this way, all the information modeled in-memory is also reflected in relational tables. Just as the in-memory session information is updated in real-time, so is the relational database. This is done so that all reporting functionality of the NetEchoes� server can run reports of the relational database and still reflect real-time producer site statistics.
Handling the session in-memory by active objects enables a variety of capabilities:
Although the above application has been described primarily in the context of a system in which client computers are linked to a server computer through a local area network or the internet, one skilled in the art can readily appreciate that the present invention is equally applicable to the monitoring of usage of other types of electronic devices (e.g., cellular phones, personal digital assistants) in wireless and other environments. Thus the application is meant only to be limited by the scope of the appended claims.
Patent Citations
Non-Patent Citations
Referenced by
Original Image