Method for monitoring user interactions with web pages from web server using data and command lists for maintaining information visited and

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

The present invention relates generally to a method and apparatus for coordinating access to Internet web sites by a group of web browsers that are being run at a group of user terminals.

It is known that users can retrieve information from web sites (network sites) via the Internet. The basic model for retrieving information from web sites is user initiated information searching. Specifically, a user interacts with (via a terminal) a web browser to send a request to a web site. In response to the request, the web server for the web site retrieves the information requested and sends the web browser the information arranged in so called web page (HTML) format. One of the unique features of this model is the feature of "hyper-text links" embedded in web pages that have been retrieved. This feature enables a user in searching for information to "navigate" from one web page to another. In order to provide services (or assistance) to users (or customers) via the Internet, it is desirable to provide a mechanism to track activities performed to the web pages among a group of browsers.

One method of tracking web pages navigated is to install a monitoring program at a web site. When a terminal sends requests to a web site, the monitoring program at the web side collects the URLs for the requested web pages and sends the URLs to a server. However, under this method, the monitoring program is not always able to monitor the requests from the terminal, because when the terminal retrieves web pages from its browser cache space or from a proxy server, the requests are fulfilled locally and are never sent to the web site. As a result, the URLs are not accurately tracked.

Another method of tracking web pages navigated is to install a monitoring program together with a browser at a terminal. The monitoring program constantly communicates with the web browser. When the browser sends requests out, the monitoring program collects the URLs for the web pages requested by the browser and sends the URLs to a server. However, this method requires designing and installing monitoring programs that are capable of communicating with the different browsers. At the current time, different web browsers are manufactured by a variety of vendors, including: Netscape.RTM., Microsoft.RTM., Sun Microsystem, IBM, and others. For a programmer to design such a monitoring program, it requires him/her to know the details of a proprietary web browser, and it may require updating the monitoring program whenever a proprietary web browser is updated. In addition, a monitoring program designed for a web browser manufactured by one vendor is typically not portable to another web browser manufactured by another vendor because browser interface mechanisms are proprietary. Moreover, users may perceive it as intrusive to be required to install a specialized application capable of collecting and reporting the information about the web pages retrieved from all other web sites.

Therefore, there is a need for an improved method to provide more dependable web page tracking.

There is another need for an improved method to provide web page tracking without requiring knowledge of the details about the web navigation software.

There is yet another need for an improved method to design web page tracking software that is portable to different software environments.

The present invention meets these needs.

SUMMARY OF THE INVENTION

In one aspect, the invention provides a method for tracking interactions with pages that have been loaded from a web server to a terminal, and for storing information about the interactions to a page tracking server. The method comprises the steps of:

(a) loading a first page from the web server, the first page being associated with a page locator for indicating a location of the first page in the web server, and the first page containing location information for indicating a location of a program;

(b) loading the program from the web server based on the location information, and executing the program;

(c) the program monitoring interactions with the page; and

(d) the program sending information about the interactions to the page tracking server.

In another aspect, the invention provides a method for tracking interactions with pages that have been loaded from a web server to a terminal, and for storing information about the interactions to a page tracking server. The method comprises the steps of:

(a) loading a page from the web server, the page being associated with a page locator for indicating a location of the page in the web server, and the page containing a program;

(b) executing the program;

(c) the program monitoring interactions with the page; and

(d) the program sending information about the interactions to the page tracking server.

The present invention also provides corresponding system for the respective aspects mentioned above.

BRIEF DESCRIPTION OF THE DRAWINGS

The purpose and advantages of the present invention will be apparent to those skilled in the art from the following detailed description in conjunction with the appended drawing, in which:

FIG. 1 shows a system includes N terminals, a network, and a web site, in accordance with the present invention;

FIG. 2 shows a situation where each of the N terminals has downloaded its respective Master Applets, DTS Applets, and SessionID Applet, in accordance with the present invention;

FIG. 3 shows the process the (consumer) Master Applet, DTS Applets, and SessionID Applet being downloaded into a terminal, in accordance with the present invention;

FIG. 4 shows the process the (consumer) Master Applet, DTS Applets, and SessionID Applet being invoked, in response to loading a subsequent web page, to perform the operations in accordance with the present invention, when these Applets have been previously downloaded and cached in a terminal;

FIG. 5 shows the process of the (consumer) Master Applet, DTS Applets, and SessionID Applet being invoked, in response to loading a subsequent web page, to perform the operations in accordance with the present invention, when both these Applets and the web page have been previously downloaded and cached in a terminal;

FIG. 6 shows a session table in greater detail, in accordance with the present invention;

FIG. 7 shows how an agent (or supervisor) can create a session interface by downloading an agent page (or a supervisor page) from administration page repository 149, in accordance with the present invention.

FIG. 8A shows an agent session interface, in accordance with the present invention;

FIG. 8B shows a browser supervisor session interface, in accordance with the current invention;

FIG. 8C shows a supervisor agent session interface, in accordance with the present invention;

FIG. 9 shows a flowchart illustrating the operation of joining a session by an agent, in accordance with the present invention;

FIG. 10 shows a screen display containing two browse instances, in accordance with the present invention;

FIG. 11 shows a flowchart illustrating the operation of web page synchronization, in accordance with the present invention;

FIG. 12A shows a web page containing five data fields, in accordance with the present invention. FIG. 12B shows a web page that is similar to that of FIG. 12A, except that the data in one of the five data fields is changed, in accordance with the present invention;

FIG. 13 shows a flowchart illustrating the operation of data synchronization, in accordance with the present invention;

FIG. 14 shows a flowchart illustrating the operation of web page tracking, in accordance with the present invention;

FIG. 15 shows a flowchart illustrating the operation of data tracking, in accordance with the present invention;

FIG. 16 shows a flowchart illustrating the operation of joining a session by a supervisor, in accordance with the present invention.

FIG. 17, there shows three browser instances for a supervisor, in accordance with the present invention;

FIG. 18 shows a flowchart illustrating the operation of re-browsing a web page previously viewed in a session, in accordance with the present invention; and

FIG. 19 shows a flowchart illustrating the operation of re-browsing all web pages previously viewed in a session, in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiment(s) will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiment(s) shown, but is to be accorded with the broadest scope consistent with the principles and features disclosed herein.

Referring to FIG. 1, there is shown an exemplary web page synchronization system 100, in accordance with the present invention.

As shown in FIG. 1, the system includes N terminals (104A, . . . , 104K, . . . , and 104N), a network 129 (the Internet, or a combination of the Internet and an Intranet), and a web site 134. Each of the terminals has a telephone set (102A, . . . , 102K, . . . , or 102N) installed in its vicinity. Each of the terminals can be a PC computer, a workstation, a Java station, or even a web TV system.

Web site 134 includes a WTS (Web Tracking and Synching) gateway 142, a WTS server 144 containing a session table 145 and a user class table 147, a database processing application 148, an HTTP (Hyper Text Transfer Protocol) server 152, and a hard disk unit 154 for storing consumer page repository 146, administration page repository 149, and database 156. All the components in web site 134 can be installed in one or more computer systems. Each of the computer systems includes a processing unit (which may include a plurality of processors), a memory device, and a disk unit (which may include a plurality of disk sets).

Each of the terminals (104A, . . . , 104K, . . . , or 104N) includes a processor unit (not shown) and a memory area (115A, . . . , 115K, . . . , 115N), and runs a Java enabled web browser (114A, . . . , 114K, . . . , or 114N). Each of the memory area (115A, . . . , 115K, . . . , or 115N) is maintained by its respective browser (114A, . . . , 114K, . . . , or 114N). Via network 129, each of the browsers (114A, . . . , 114K, . . . , or 114N) is able to send requests to and receive web pages from HTTP server 152, and to display the web pages received at its respective terminal. Each of the browsers (114A, . . . , 114K, . . . , or 114N) is able to run a Master Applet (124A, . . . , 124K, . . . , or 124N), a set of DTS (Data Tracking and Synching) Applets, a SessionID Applet, and an Agent Applet. As shown in FIG. 1, these Applets are stored in consumer page repository 146 and can be downloaded from consumer page repository 146 and stored in the memory areas of the terminals (104A, . . . , 104K, . . . , 104N).

Referring to FIG. 2, there is shown the situation where each of the terminals (104A, . . . , 104K, . . . , or 104N) has downloaded its respective Master Applets (124A, . . . , 124K, . . . , or 124N), DTS Applets (126A, . . . , 126K, . . . , or 128N), and SessionID Applet (128A, . . . , 128K, . . . , 128N), in accordance with the present invention.

In FIG. 2, each of the (consumer) Master Applet (124A, . . . , 124K, . . . , or 124N) is primarily responsible for: (1) in response to loading each web page at its respective browser, opening a dedicated socket, and establishing a socket connection to WTS gateway 142 via network 129 for its respective browser (114A, . . . , 114K, . . . , 114N), (2) communicating with WTS server 144 via the socket connection, from which WTS server 144 is able identify the origin (i.e. which browser, which web page, etc.) of the commands and information that are being delivered through, (3) monitoring the activities of its respective browser, (4) sending the information about its respective browser's activities to WTS server 144, (5) receiving and processing the information about other browsers' activities, (6) via the socket connection, providing a single communication path to WTS server 144 for DTS Applets (126A, . . . , 126K, . . . , or 126N), SessionID Applets (128A, . . . , 128K, . . . , or 128N), or any other consumer Applets embedded on the same page with the Master Applet, (7) sending commands to WTS server 144 to request services, for itself and for DTS Applets (126A, . . . , 126K, . . . , or 126N), SessionID Applets (128A, . . . , 128K, . . . , or 128N) , or any other consumer Applets embedded on the same page with the Master Applet, and (8) sending user class information together with the commands, to indicate that its respective browser is a consumer user.

Each set of DTS Applets (126A, . . . , 126K, . . . , or 126N) contains one or more individual DTS Applets, which are primarily responsible for: (1) displaying and monitoring the data activities (data inputs or data updates of data fields) on web pages that are being displayed by its respective browser, (2) sending the data activities to WTS server 144 via its respective Master Applet, (3) receiving the data activities from other browsers via its respective Master Applet, and (4) processing the data activities from other browsers for the web pages that are being displayed by its respective browser.

Each of the SessionID Applets (128A, . . . , 128K, . . . , or 128N) is responsible for retrieving, and for displaying on a web page the current SessionID.

As shown in administration page repository 149, Agent Applet (or Supervisor Applet) is responsible for creating a session interface, joining, monitoring, and controlling a session through the session interface. The(administration) Master Applet is primarily responsible for: (1) opening a dedicated socket, and establishing a socket connection to WTS gateway 142 via network 129 for the session interface created by Agent Applet, Supervisor Applet, or any other administration Applets embedded on the same web page with the Master Applet, (2) communicating with WTS server 144 via the socket connection, from which WTS server 144 is able identify the origin (i.e. from which session interface) of the commands and information that are being delivered through, (3) via the socket connection, providing a single communication path to WTS server 144 for Agent Applet, Supervisor Applet, or any other administration Applets embedded on the same web page with the Master Applet, and (4) sending user class information together with the commands, to indicate that its respective browser is an administration user.

WTS gateway 142 is responsible for maintaining all socket connections between Master Applets and WTS server 144. The connections between Master Applets and WTS gateway 142 take place using standard sockets. The connection between WTS gateway 142 and WTS server 144 takes place using RMI (Remote Method Invocation).

WTS server 144 is responsible for: (1) managing and tracking the activities of all browsers participating in active sessions, exemplary activities including: loading of, interacting with, and unloading of web pages, (2) recording the information about the activities, (3) managing the synchronization of the activities for all browsers participating in the active sessions, (4) creating a session when a consumer user (via a browser) sends a request to web site 134 for the first time, (5) defining the session length intervals, (6) purging sessions that have been inactive for more than the specified session length intervals, (7) adding and deleting participants to a session, and (8) providing services to all commands from consumer Applets, such as: (consumer) Master Applet, DTS Applets, SessionID Applets, and administration Applets, such as: (administration) Master Applet, Agent Applets, and Supervisor Applet.

Consumer page repository 146 stores the web pages and Applets for consumers. Consumer Applets can be selectively embedded into consumer web pages. Exemplary consumer Applets include: (consumer) Master Applet, DTS Applets, SessionID Applet, etc.

Administration page repository 149 stores the web pages and Applets for call center administration users, including: administrator, supervisor, agent, etc. Administration Applets can be selectively embedded into administration web pages. Exemplary administration Applets include: (administration) Master Applet, Agent Applet, Supervisor Applet, etc.

To better describe the present invention, the Applets stored in (or downloaded from) repository 146 can be referred to as consumer Applets, and the Applets stored in (or downloaded from) repository 149 can be referred to as administration Applets. For example, the Master Applet stored in (or downloaded from) repository 146 can be referred to as consumer Master Applet, and the Master Applet stored in (or downloaded from) repository 149 can be referred to as administration Master Applets. HTTP server 152 contains a security application that allows consumer users to get access only to the web pages stored in consumer page repository 146, and allows administration users (such as administrator, supervisor, agent, etc.) to get access to the web pages stored in both consumer page repository 146 and administration page repository 149.

Session table 145 is responsible for maintaining the information for all active sessions.

Class table 147 is responsible for keeping records of user classes assigned to different users. Listed are exemplary user classes: administrator, supervisor, agent, and consumer.

Based on user classes (administrator, supervisor, agent, and consumer), WTS server 144 provides the following services:

(1) creating a session (consumer);

(2) storing data received from a session participant (supervisor, agent, and consumer);

(3) listing active sessions (administrator and supervisor);

(4) listing the information associated with active sessions (administrator, and supervisor);

(5) listing current users (administrator);

(6) joining a session (supervisor and agent);

(7) terminating a session (supervisor);

(8) monitoring a session (supervisor and agent);

(9) configuring a session parameters (administrator); and

(10) sending commands and information to a consumer Master Applet or an administration Master Applet in a participating browser (supervisor, agent, and consumer).

Database 156 is responsible for storing data collected in session table 145.

HTTP server 152 is responsible for processing the requests issued by one of the web browsers, retrieving the web pages from either consumer page repository 146 or administration page repository 149, and sending the web pages to the browsers that have generated these requests.

Database processing application 148 is responsible for writing the data collected in session table 145 into database 156.

Referring to FIG. 3, there is shown the process of how the (consumer) Master Applet, DTS Applets, and SessionID Applet being downloaded into terminal 104A from HTTP server 152 in response to loading an initial web page, and then being invoked to perform the operations in accordance with the present invention.

As shown in FIG. 3, a (consumer) Master Applet, a set of DTS Applets, and a SessionID Applet are embedded into web page 204 by using a set of applet tags 208. Web page 204 is associated with a specific URL indicating the location of web page 204 in HTTP server 152.

As indicated by dotted line (1), web browser 114A sends a request including the URL of web page 204 to HTTP server 152 via network 129. As indicated by dotted line (2), in response to the request, HTTP server 152 retrieves web page 204 from consumer page repository 146 and sends it to web browser 114A via network 129. Web page 204 contains a set of applet tags 208, which indicate the location of Master Applet, DTS Applets, and SessionID Applet in HTTP server 152. As indicated by dotted line (3), web browser 114A loads web page 204. As indicated by dotted line (4), since Master Applet, DTS Applets, and SessionID Applet have not been downloaded, web browser 114A sends requests via network 129, to download these Applets based on applet tags 208. As indicated by dotted line (5), HTTP server 152 sends Master Applet, DTS Applets, and SessionID Applet to browser 114A via network 129. As indicated by dotted line (6), browser 114A stores Master Applet 124A, DTS Applets 126A, and SessionID Applet 128A into memory area 115A of terminal 104A, and initializes and invokes these Applets. After being invoked, these Applets are running together with web browser 114A, to monitor and process the activities for which they are assigned to be responsible. As indicated by line (7), Master Applet 124A opens a dedicated socket and establishes a socket connection to WTS gateway 142 for browser 114A and web page 204. Via the socket connection, Master Applet 126 sends WTS server 144 a command, together with an ID unique to browser 114A. In response to the command from Master Applet 126, WTS server 144 creates a session for browser 114A based on the unique ID, and issues a time stamp (loading time) indicating the time at which the command was received, and stores the URL and time stamp of web page 204 into the session created for browser 114. As will see in the description in connection with FIG. 6 following, the URL, command, and loading time are stored in a URL history list and a command list created for the session.

Referring to FIG. 4, there is shown the process of the (consumer) Master Applet 124A, DTS Applets 126A, and SessionID Applet 128A being invoked, in response to loading a subsequent web page 214 (subsequent to web page 204), to perform the operations in accordance with the present invention, when these Applets have been previously downloaded and cached in terminal 104A.

As indicated by dotted line (1), to download web page 214, web browser 114A sends a request including the URL of web page 214 to HTTP server 152 via network 129. Before loading web page 214, the following events occur: (a) browser 114A instructs Master Applet 124A to run a stop routine, (b) via the socket connection established for browser 114A and web page 204, Master Applet 124 sends a command to inform WTS server 144 that web page 204 has been unloaded, and disconnects the socket connection established for browser 114A and web page 204, (c) WTS server 144 issues a time stamp (unloading time) indicating the time the command was received, and (d) records the URL and the time stamp of web page 204 into the session created for browser 114A. As will be seen in the description in connection with FIG. 6, following, URL, command, and unloading time are stored in a URL history list and a command list created for the session. As indicated by dotted line (2), HTTP server 152 retrieves web page 214 from consumer page repository 146 and sends it to browser 114A. Like web page 204, web page 214 contains a set of applet tags 208 for indicating the location of Master Applet 124A, DTS Applets 126A, and SessionID Applet 128A. As indicated by dotted line (3), web browser 114A loads web page 214. As indicated by dotted line (4), in response to the loading of web page 214, web browser 114A locates Master Applet 124A, DTS Applets 126A, and SessionID Applet 128A (based on the indication of applet tags 208) that are cached by browser 114A in memory area 115A, and initializes these Applets and then invokes them. As indicated by line (5), Master Applet 124A opens a dedicated socket and establishes a socket connection to WTS gateway 142 for browser 114A and web page 214. Via the socket connection established for browser 114A and web page 214, Master Applet 126A sends a command, together with the ID unique to browser 114A and the URL of web page 214, to inform WTS server 144 that web page 214 has been loaded. WTS server 144 issues a time stamp (loading time) indicating the time the command was received and stores the URL and time stamp of web page into the session created for browser 114A. As will be seen in the description in connection with FIG. 6, following, URL, command, and loading time are stored in a URL history list and a command list created for the