Field of the Invention : The invention pertains to systems and methods for facilitating interactions on communications networks. More particularly, the invention pertains to such systems and methods usable to provide interactive real time communications between a user and another party while the user is viewing a page or pages of a web site.

Background of the Invention : A service of the Internet, the WorldWide Web, has evolved as a readily available source of worldwide information. In addition to merely providing information, numerous companies have established web sites through which are offered a variety of goods and services.

A visitor perusing a page or pages of a selected site selects those goods or services of interest and arranges to pay for them using a credit or debit card for example. While there has been great interest in this form of electronic commerce and many companies have established web sites for the purposes of marketing their products and services, some limitations have been encountered.

One limitation that has been encountered has been an inability of visitors, who have expressed an interest in the products or services by their presence at the site to easily obtain answers to questions about the products or services. Another limitation that has been noted is an inability of the organization whose web site is being viewed to monitor the progress of the user and to initiate communication, substantially in real time, with the user during the viewing session.

In known systems, it has been necessary for the site visitor or potential customer to initiate an interaction. Not all visitors take this step.

Another form of known, interactive, network based communications is the so-called chat room. Chat rooms enable individuals having a common interest to interact substantially in real time concerning any subject that might be of interest to them. While facilitating interactive communications, chat rooms have not as yet had a substantial effect on web based commerce. One reason for this may be that persons visiting chat rooms may not have any interest at that time in buying goods or services of a type associated with the chat room. A second reason may be that chat rooms are multi-person forums that do not readily lend themselves to 1 : 1 interactions. Another reason is that a user must take steps to join a chat room in order to participate. A monitoring party could not bring a visitor into a chat room to initiate an interaction.

There thus continues to be a need for interactive communications capabilities which can be used to facilitate web based commerce. It would be desirable to enable a site representative to proactively engage a visitor. It would also be desirable if such capabilities could be incorporated into web sites or pages which offer goods or services. In a preferred system, it will not be necessary to download to the user any applets,"cookies", software modules or the like.

Preferably, such interactive communications could be implemented using, at the user's site, nothing more than a standard commercial browser such as those available from Microsoft Corporation or Netscape.

Summarv of the Invention : The presence of a visitor at a web site that offers goods or services is an indication that the visitor is interested enough in the goods or services to be a potential customer. This is a self-screening process. In effect, the visitor's presence is a statement of interest in the subject goods or services.

The visitor's presence at a given commercial site is also a statement that"this is a good time"to consider obtaining the offered goods or services. In accordance with the present invention, a representative of a web site is provided with the tools to proactively contact a visitor in an appropriate business-like fashion to open an interactive dialog to offer to assist or help the visitor by answering

questions or offering suggestions. The dialog can be carried out interactively in real-time.

The proactive capability is analogous to having a knowledgeable sales person approach and initiate a dialog with a potential customer in a store.

Questions can be answered and additional suggestions can be made to the customer in real-time.

Systems and methods for facilitating electronic commerce make it possible for a visitor who has access to a web site to review the pages of that web site. While reviewing the pages, the visitor can be contacted by a representative of the proprietor of the site for purposes of initiating an interactive interchange, a conversation, with that visitor. The present systems and methods make use of the frame-based functionality of the visitor's browser. No applets, cookies, modules or other software need to be downloaded to the visitor's computer.

In another aspect, the visitor's movement through the pages of the site can be tracked and recorded. The list of tracking information for respective visitors can be stored for later review and follow-up. The tracking information can be presented in real time to the representative to facilitate the communications process.

In yet another aspect, a dialogue box can be opened on the visitor's display for purposes of initiating a text-based interactive conversation. At the initiating end of the conversation, a display can be provided of both sides of the conversation.

Alternatively, a graphical symbol or icon can be provided on the visitor's display. Triggering or clicking on the symbol or icon enables the visitor to open a conversation with a representative of the site. The representative can then respond to the visitor's inquiries on a real time basis. Specific questions can be answered and any concerns raised by the visitor about the goods or the services can be addressed immediately.

In yet another aspect, the present systems and methods can be implemented with respect to web sites that use HTML coded pages. This

implementation, which makes use of HTML frame tags supported by currently available browsers, is especially desirable. Only the pages associated with a selected web site need be supplemented with additional frame and link tags. No applets,"cookies"or other modules need be downloaded to the visitor's computer.

All that is required at the visitor's end is that the respective browser be capable of responding to frame tags.

In yet another aspect, where a visitor logs onto a web site a unique identifier is assigned to that visitor. This identifier can be used to track the progress of the visitor through the pages of the site. Unlike an IP address which can be associated simultaneously with a plurality of visitors to the site, the unique assigned identifier enables a representative of the site to initiate a 1 : 1 interactive conversation with the visitor.

The unique identifier also enables a web site proprietor to analyze either in rea time, or, off line patterns of usage of the site. High trafic, commercially effective paths can be identified and emphasized. Low traffic paths can be revised or discontinued.

Exemplary applications of the invention include : Providing a live sales person in the internet.

Example : A jewelry sales web site, where the site is organized to lead the visitor to one of a number of product categories (for example, rings, watches, necklaces, etc.). Sales oriented representatives watch the visitors move through the site. Once a visitor lingers on a product page for more than 3 minutes, a representative engages that visitor and offers assistance. If the visitor responds favorably, the representative attempts to close a sale. If the visitor requests to be left alone, the representative terminates the conversation.

Matching a user who has a specific question with an expert representative.

Example : A technical support web site, where the site is organized to lead the visitor through a series of choices defining the nature of the visitor's problem before presenting a button encouraging the visitor to"Click here to speak

to a live support representative". When the visitor clicks on the button, a pool of support representatives is notified of the contact request. Each representative views the visitor's page history to determine the nature of the problem, and the representative most familiar with the problem engages the visitor. The representative and the visitor hold a text-based conversation regarding the problem, and once it is solved, the Representative terminates the conversation.

Matching the correct regional sales agent with the correct customer.

Example : A property rental web site monitored by three pools of representatives, each with a geographic area to service. The web side is organized by location (North, Central, and South) and each area is subdivided by property type (house, apartment, office). Each representative monitors only the portion of the web site which corresponds to their geographic region. As the visitor moves throughout the pages on the site, the appropriate representative is able to watch the visitor's page selections and engage that visitor already knowing that the visitor wants, for example, a 3-bedroom apartment in the Central region.

Correct and validate the customer choices in a user- configurable product order system.

Example : A computer sales web site where web visitors configure the system they wish to purchase. The visitor selects the components they want, then submits the list to a validation program. If the validation program categorizes the system as poorly designed, a representative notified and engages the visitor in a conversation to talk them through and correct their choices.

Numerous other advantages and features of the present invention will become readily apparent from the following detailed description of the invention and the embodiments thereof, from the claims and from the accompanying drawings.

Detailed Description of the Preferred Embodiments : While this invention is susceptible of embodiment in many different forms, there are shown in the drawing and will be described herein in detail specific embodiments thereof with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the invention to the specific embodiments illustrated.

Exemplary iContact Implementation Requirements 1. When clients (visitors) log into the web site, their Financial Consultant (FC) is notified that they are on the site.

2. Clients (visitors) can determine whether or not their FC is monitoring the web site and available to assist them.

Solutions for Meeting Requirements Requirement 1 The following steps show how iContact can determine the Visitor's FC and notify the FC that one of their clients is presently on the web site. Please refer to Diagram 1 while reviewing the following steps.

(1) When a web visitor first accesses the web site they are registered into iContact. iContact returns a frame set to the visitor's browser that will stay with the visitor during their visit. The frame set allows iContact to track and identify the visitor. Since they have yet to login to the web site, and be identified, they are not displayed on any of the FC's workstations.

(2) The visitor logs into the web site. Upon successfully logging into the system, a page associated with the visitor's FC, in this case M. Owens, is returned to the visitor's browser.

(3) The returned page immediately requests a page from the iContact server. The requested page's title is the iContact system identifier assigned to the FC when their account was created, in this case"mowens" (actual identifier is numeric).

(4) The page request notifies the iContact system that this visitor has requested a page with the title of"mowens".

The page is returned to the visitor's browser and the request is passed on to the NetRep client applications installed on the FC's workstations.

(5) The visitor's iContact assigned system identifier (25736) and the title of the page they requested ("mowens") is sent to all the FCs logged into the system. Each client application will determine if they are allowed to monitor this individual. This is done by checking if the page title (a. k. a. FC's system identifier) is in their filter list or the visitor's identifier is in their active list.

(6) In this case the page title is in M. Owens'filter list, so the visitor will now appear in his NetRep client application's Visitor List. M. Owens can also be notified by any combination of audible and visual indicators generated by the NetRep client application. At this point, M. Owens has the option to proceed and engage the visitor and starting the conversation via iContact.

(7) The visitor can continue surfing through the web site normally. M. Owens will not be aware of which page they are viewing, only that they are still on the site.

(8) If it is determined that knowing the specific page (or section of the web site) the visitor is viewing is necessary then the request for the specific page (or first page of the section) will be made through iContact. iContact will return the requested page to the visitor's browser and pass the request on to the NetRep client applications.

(9) The visitor's system assigned identifier (25736) and the title of the page they requested ("quotes") is sent to all the FCs logged into the system. Each client application will determine if they are allowed to monitor this individual. They do this by checking if the page title (a. k. a. FC's system identifier) is in their filter list or the visitor's identifier is in their active list.

(10) In this case the visitor's identifier is in M. Owens'active list, so the entry in M. Owens'Visitor List will be updated. M. Owens can also be notified by any combination of audible and'visual indicators generated by the NetRep client application if this new page is in his page notification list.

Requirement 2 The following steps show how visitors can determine whether their FC is monitoring the site and available to assist them. Please refer to Diagrams 2A & 2B while review the following steps.

Contacting their registered FC Diagram 2A <BR> <BR> <BR> (1) The visitor decides they want to communicate with their FC using iContact. They click a"Contact a Financial Consultant"link which displays a list of available FCs. The link can be distributed throughout the web site. The list will contain all the FCs registered to use iContact or it can also include unregistered FCs with a list of alternative contact methods like telephone number, email, or an automatic call back form.

(2) The visitor selects his/her FC from the list and clicks their name, in this case"M. Owens".

(3) This sends a request to the iContact system for M. Owens. The request consists of the visitors unique identifier, the FC's identifier, and the URL of a page with the title of"mowens".

(4) iContact checks to see if the requested FC,"mowens", is logged into the system by checking the NetRep status list on the iContact server.

(5) If M. Owens is logged into the system, then a page requesting the visitor to"Please Wait for Contact"will be returned to the visitor's browser. Otherwise a message stating that the requested FC is not available will be returned. Alternate methods of contact can also be displayed at this time.

(6) If M. Owens is logged into the system, the visitor's iContact assigned system identifier (25736) and the title of the page they requested ("mowens") is sent to all the FCs logged into the system. Each client application will determine if they are allowed to monitor this individual. This is done by checking if the page title (a. k. a. FC's system identifier) is in their filter list or the visitor's identifier is in their active list.

(7) In this case the page title is in M. Owens'filter list and the system identifier is in his Active List. The visitor's entry in M. Owens'Visitor List will change its state from"Available"to"HI"designating that they have requested contact. M. Owens can also be notified by any combination of audible and visual indicators generated by the NetRep client application.

Contacting another registered FC Diagram 2B (1) The visitor decides they want to communicate with another FC if theirs is not available. They click a"Contact a Financial Consultant"link which displays a list of available FCs. The link can be distributed throughout the web site. The list will contain all the FCs registered to use iContact or it can also include unregistered FCs with a list of alternative contact methods like telephone number, email, or an automatic call back form.

(2) The visitor selects a FC from the list and clicks their na e, in this case"R. Lincoln".

(3) This sends a request to the iContact system for R. Lincoln. The request consists of the visitors unique identifier, the FC's identifier, and the URL a page with the title of"rlincoln".

(4) iContact checks to see if the requested FC,"rlincoln", is logged into the system by checking the NetRep status list on the iContact server (5) If R. Lincoln is logged into the system, then a page requesting the visitor to"Please Wait for Contact"will be returned to the visitor's browser. Otherwise a message stating that the requested FC is not available will be retumed. Alternate methods of contact can also be displayed at this time.

(6) If R. Lincoln is logged into the system, the visitor's iContact assigned system identifier (25736) and the title of the page they requested ("rlincoln") is sent to all the FCs logged into the system. Each client application will determine if they are allowed to monitor this individual. This is done by checking if the page title (a. k. a. FC's system identifier) is in their filter list or the visitor's identifier is in their active list.

(7) In this case the page title is in R. Lincoln's filter list, so the visitor will now appear in his NetRep client application's Visitor List with it's state set to"HI"designating that they have requested contact.

(8) In this case the system identifier is in M. Owens'Active List. The visitor's entry in M. Owens'Visitor List will change its state from"Available"to"HI"designating that they have requested contact.

Nlethodfor distinguishing individual Surfers on an Internet site As Surfers flow into an iContact enabled web site, the software automatically assigns a unique identifier to each visitor. As with most of the claims we are discussing, I believe that this is reliant on our ability to track and provide functionality without visitor instigation or the possibility of their interference (i. e. turn off"cookies", Java, or refuse to fill out a form).

First, because many Surfers dial-up through large proxy servers, a large number of visitors are identified by the same IP address. For exarnple, normal server logs will list all activity from AOL users in New York as essentially the function of the same user. Given that we need to distinguish between all individuals on an Internet site in order to enable one-on-one communication, we created a method to monitor in real-time the activities of each individual visitor to a site. By sending a periodic request to the web server ('heartbeat"), iContact allows live representatives to visually monitor each individual visitor's activity without concern for shared IP addresses.

There are other ways to attempt to distinguish individual visitors, however, iContact is unique because it does not require a Surfer to accept a downloaded piece of data or perform a user-initiated function. For example, if every visitor is asked to fill out a form or provide a username and password, the server can then distinguish between all Surfers.

Internet"cookies"can also be sent to each individual to allow the web server to monitor individual activities. The iContact software is unique in that visitors are not required to accept cookies (which is at a Surfer's discretion), fill out any type of registration or form, or perform any action beyond requesting an HTML page from a web server. It should be noted that iContact does not preclude the use of cookies, forms or logins ; it just does not require them.

Technically, this all takes place during steps, and 4 on DJ's Diagram One. I laid out instructions for six sample pages below that can be used to provide an example of what DJ was referring to. The pages will show a progression in HTML as a Surfer sees them : first as they arrive, then when they have a unique ID attached, and finally when a conversation has begun.

Figures 1-1 through 1-3 Figure I-la-New, uncaptured (unregistered) visitor to the site.

Figure 1-1b-NetRep Client with no visible (registered) surfers.

Figure 1-2a-Browser of uncaptured, but registered, visitor.

Figure 1-2b NetRep Client with uncaptured, but registered surfer.

Figure 1-3a-Conversation frameset with captured surfer.

Figure 1-3b NetRep Client engaged in a conversation with a surfer.

Display system for live NetReps that rationally exhibits carrent tf-affic activity of an Internet site The essential claim here is simple. Given that no one has ventured to proactively approach Surfers, no one has yet developed a system that organizes web activity into a "control panel"which allows NetReps to watch and dynamically communicate with Surfers. We have collected all the information that we can in real-time, and have built a graphical user interface (GUI) that provides NetReps with valuable tracking information about visitors before, during, and following communications. Although there are literally hundreds of reasons and uses for this GUI, we sought in the design to enable three basic functions.

I) Enable live NetReps to approach visitors based upon observed behaviors This is perhaps the most important function of the GUI. In the same way that a good vantagepoint allows a retailer to gauge their store's activity, iContact provides a web site owner with a clear view of their virtual business. Live NetReps can visually monitor each visitor's current location, the amount of time each has spent on that page and the site in total, and a list of the last ten pages that each visitor has viewed. By providing businesses with this information they can proactively approach any number of visitors in order to react to or capitalize on observed Surfer behavior. The analogy is simple : retailers have always watched their stores and approached people based on what they did once they got inside. They ask the person wandering aimlessly if they can help them find something, and they approach people when they pause to examine an item in order to spurn the sales process. The iContact software translates server information into a GUI that allows businesses to provide the same dynamic sales and service assistance to their Internet visitors.

The simplest example involves a NetRep monitoring the transaction area of a site. In order to complete a purchase, most web sites first ask Surfers to fill out a form with all of their personal and payment information. The Surfer then submits this form and waits until the transaction is cleared or rejected. Live NetReps could watch the transaction area and approach Surfers who either aborted the transaction or who were sent to the denial page.

Figures 2-1 through 2-6 Figure 2-7-NetRep Client with four uncaptured visitors. Two are on the purchase page, two are elsewhere on the site.

Figure 2-2-Surfer on the Ordering section of the site. Figure 2-3-NetRep Client with the same uncaptured visitors. One visitor's order has been denied while the other's has been accepted.

Figure 2-4-The Surfer's screen after his/her order was denied. Figure 2-5-The surfer is engaged by a NetRep who notices that the surfer's order has been denied. The conversation frameset appears. Figure 2-6-NetRep Client now with three uncaptured visitors. The engaged visitor is the surfer whose order was denied.

NetReps could also approach Surfers who appear lost. If a NetRep observes a Surfer quickly moving through multiple pages without spending the time to stop and examine any content, they can assume that the visitor has not located the desired information. The software then enables a NetRep to approach that Surfer with the same type of polite assistance that is offered in retail environments :"Hello, I noticed that you appeared a little lost, can I help you find something specific".

Figures 3-1 through 3-6 Figure 3-1-NetRep Client with three uncaptured visitors. Two are on the site. the other is elsewhere on the site. Figure 3-2-NetRep Client with same uncaptured visitors. One of the visitors previously on the catalog page has now moved to the employment page. Figure 3-3-NetRep Client with same uncaptured visitors. The visitor previously on the employment page has now moved to the main page. Figure 3-4-NetRep Client with same uncaptured visitors. The visitor previously on the main page has now moved to the site map page.

Figure 3-5-The observant NetRep now captures the aforementioned surfer. He/she offers to help with navigation.

Figure 3-6-The engaged surfer tells the NetRep that he/she is looking for the Order Page. The NetRep sends a link in the conversation frameset that points to the order form.

2) Provide a svstem and GUI that gathers the information needed to prioritize and logicallv direct NetReps to approach and respond to individual Surfers The massive size and scope of Internet sites makes i. increasingly important to direct the most appropriate representative to different sections of the site. IContact displays all people on a site within a queue that shows the information for each Surfer laid out earlier (i. e. current page, time, etc.) As Surfers leave the site or are engaged by a NetRep, they are removed from the queue. We have a system that allows a flexible level of monitoring, of all or part of a site, by any number of NetReps. One of the unique attributes of this system of display is the ability to manage NetReps'time and focus their work scope.

For example, an online brokerage firm could use three different types of NetReps on their site. Brokers in charge of specific clients, lower level brokers in charge of recruiting new business, and hourly-wage customer service agents. The iContact software makes it possible to limit or open the"view"that each NetRep sees. Experienced (and expensive) brokers who take care of existing clients could only view the transaction pages and other activity behind a username and password login. This way they would only spend their time with people who have demonstrated their client status. The brokers in charge of recruitment could then monitor the"research"area. Here investors read through the company's reports and recommendations. This free research is available to non-members, and is a logical place to direct these NetReps. If brokers observe people spending the time to read through many reports, they could approach and begin a conversation with this perspective client. Finally, the customer service representatives could all have a view of the entire site. Whether they are tasked to respond to questions, or serve as back up for the whole site, our system enables a company to change the view that any NetRep sees in order to direct and control the site.

3) Svstem that enable iVetReps to respond to Surfers requests for assistance with important information about the visitor The iContact software makes it possible to respond to Surfers armed with a great deal of information about them. There are many types of software that allow a Surfer to make a request for a live communication. Our system's display is unique because NetReps can respond armed with a great deal of information about the Surfer. Our NetRep GUI first informs NetReps of a request for communication with an audio tone and a color change of that Surfer in the queue. In the seconds or minutes before the NetRep prompts the conversation, they have access to all the pages that the Surfer has viewed, any previous discussions they have had with NetReps. and any amount of data that is available about the Surfer requesting help. This allows them to manage their time more efficiently for a variety of reasons.

For example, during busy times, NetReps can respond immediately to the member's area, and choose to ignore requests from people who have been taking up NetRep's time without the hope of a sale. NetReps can also approach prepared with the information that a Surfer is likely to request. If a Surfer requests help from a specific product page, the NetRep can call up all of the information about that product before they respond. While all other products require NetReps to respond based on time waiting or when the next available rep is free, iContact's visual display system allows companies to be discerning.

In short, our monitoring system makes it possible for NetReps to spend their time with the most potentially fruitful Surfers.

Example : NetRep Assistance Figures 4-1 through 4-9 Figure 4-1-Web visitor has a question about the iContact client, however the web visitor cannot find the answer on the web page. The visitor decides to ask a NetRep and request assistance by"clicking"the NetRep icon.

Figure 4-2-The NetRep identifies the web visitor with a question. The NetRep prepares a message"Can I help you"and sends it to the web visitor.

Figure 4-3-A conversion starts between the NetRep and web visitor.

Figure 4-4-The conversation continues.

Figure 4-5-Information relating to the web visitor and the conversation between the visitor and the NetRep is captured in two ways. The iContact server automatically creates a database which is populated with the conversation, date, time, between the NetRep and the web visitor for future reference.

Figure 4-6-The client software can also be populated manually with data that is also saved in a database on the iContact server. In this case the NetRep populates a Notes Field on the client software. A page visited history is also created of web pages that have been visited by the web surfer.

The information in the database can help facilitate future sessions. For example, our web visitor may decide that he has enough information. The initial conversation is concluded.

However, the web visitor realizes that he ahs another question He again requests for help.

Figtere 4-7-The conversation starts.

Figure 4-8-The surfer request additional information, reminiscent to the previous conversation. However, the NetRep notices that the web visitor was previously captured and checks the databases on the server. The NetRep can review the previous conversation and also review the pages that that the web visitor has looked at recently.

Figure 4-9-The NetRep recognizes that the web visitor had a previous question about the client software. He prompts the web visitor if he has any additional questions about the client software.

System of communication that enables live NetReps to manage multiple unique communications with individual Internet visitors There are two distinctions that can be drawn between iContact and existing technologies. First, chat rooms can enable communication between a human monitor (NetRep) and any number of Surfers who request a"chat room". There are other products that allow NetReps to communicate one-on-one with people requesting help. The iContact software makes it possible for a NetRep to carry on any number of one-on-one communications with any number of Surfers. We have limited it temporarily to five concurrent conversations, but is an artificial limit based on our experiences with NetRep overload.

The reality is that our NetRep GUI allows a person to balance the needs of many Surfers using the capabilities inherent within the system.

When a NetRep has many people engaged simultaneously, those people all appear in a list. The NetRep can then"click"on any Surfer to send a message to, or view the messages that that Surfer has sent. It is possible to use pre-set messages, as well as the ability to simultaneously send one message to any number of Surfers, in order to deal with the most visitors possible. The NetRep GUI keeps the history of all conversations making it possible for a NetRep to move between conversation without confusing individual Surfers. For example, if a NetRep has four people engaged and two are asking for the same piece of information, the rep can look on the pre-set list and send the same message to both Surfers with two"clicks".

Figures 5-1 through 5-10 Figure 5-1-A NetRep is currently monitoring the site with three web visitor. The NetRep selects a preset message"weather"tc send to all three.

Figure 5-2-The same conversation however viewed by the initial web visitor, Jill.

Figure-3-The same conversation however viewed by the initial web visitor, John.

Figure 5-4 - The same conversation however viewed by the initial web visitor, Jack.

Figure 5-5 - Jack replies that the weather is terrible in Miami.

Figure 5-6 - Jill's response.

Figure 5-7-John's reponse.

Figure 5-8-The NetRep view of Jill's response.

Figure 5-9-The NetRep view of John's response.

Figure 5-10-The NetRep view of Jack's situation. iContact technical description Diagram land Diagram 1-b The following steps show how iContact processes a system initiation and a new page request. The solid lines trace the system initiation and the dashed lines trace the new page request. Please refer to Diagram 1 while reviewing the following steps.

System initiation <BR> <BR> <BR> (1) The visitor clicks on a treated link that calls a npage function call through iContact's ISAPI server extension. The parameters for the function call are the LRL of the requested page and the visitor's id which defaults to the entry in the title tag of the current page.

(2) The server extension notifies the capture server that a new visitor has requested a page.

(3) The capture server creates a new visitor id for the visitor and returns the id to the server extension.

(4) The server extension returns the un-captured frame set to the visitor with the visitors id imbedded in the title tag of the frame set.

(5) The requested page is targeted to the content frame of the un-captured frame set.

(6) The capture server notifies the NetRep server that a new visitor is on the site. The notification includes the visitors id and current page.

(7) A new session is created in the database for the visitor which includes the visitor's current page, browser strings, and IP address.

(8) The NetRep client application is notified of the new visitor.

New page request <BR> <BR> <BR> (1) The visitor clicks on a treated link that calls a npage function call through iContact's ISAPI server extension. The parameters for the function call are the LRL of the requested page and the visitor's id which was stored in the title tag of the current page.

(2) The server extension notifies the capture server that a visitor has requested a new page. The notification includes the requested LRL and the visitor's id.

(3) The capture server returns a confirmation to the server extension.

(4) The server extension returns the un-captured frame set to the visitor with the visitors id imbedded in the title tag of the frame set.

The The requested page is targeted to the content frame of the un-captured frame set.

(6) The capture server notifies the NetRep server that a visitor has requested a new page. The notification includes the visitors id and current page.

(?) The page history gets updated in the database for the visitor.

(8) The NetRep client application is notified of the page change.

Diagram 2 The following steps show how iContact processes a proactive engagement (NetRep initiated) and a release.

The solid lines trace the proactive initiation and the dashed lines trace the release. Please refer to Diagram 2 while reviewing the following steps.

Proactive engagement <BR> <BR> <BR> (1) The NetRep initiates an engagement with a visitor. The initiation includes an introductorv message to the visitor is sent to the NetRep server.

(IA) The database is updated with the new status and introduction message.

(2) The capture server is notified that the NetRep is engaging a visitor. The NetRep id, visitor's id, and initial message is sent as parameters.

(3) The heartbeat function from the hidden frame asks the ISAPI extension if this visitor is engaged or not.

(4) The extension asks the capture server if this visitor is engaged.

(5) The capture server notifies the extension that this visitor is engaged.

(6) The hidden frame receives a response that the visitor is engaged.

(7) The hidden frame requests a full reload of the browser window.

(8) The extension returns the captured frame set to the browser.

(9) The requested page is targeted to the content frame of the captured frame set.

Release (1) The NetRep initiates the release of the visitor.

(IA) The database is updated with the new status.

(2) The capture server is notified that the NetRep is releasing a visitor. The NetRep id and visitor's id are sent as parameters.

(3) The heartbeat function from the hidden frame asks the ISAPI extension if this visitor is engaged or not.

(4) The extension asks the capture server if this visitor is engaged.

The The capture server notifies the extension that this visitor is not engaged.

(6) The hidden frame receives a response that the visitor is not engaged.

(7) The hidden frame requests a full reload of the browser window.

(8) The extension returns the un-captured frame set to the browser.

(9) The requested page is targeted to the content frame of the un-captured frame set.

Diagram 3 The following steps show how iContact processes a reactive engagement (Visitor initiated). Please refer to Diagram 2 while reviewing the following steps.

(1) The Visitor initiates an engagement with a NetRep. A request contact function call is sent to the ISAPI extension with a page URL and the visitor's id (2) The server extension returns the waiting for contact frame set to the browser (3) The server extension notifies the capture server that a visitor has requested contact.

(4) The request for contact is forwarded to the NetRep server (5) The NetRep server notifies the NetRep clients that a visitor is requesting contact.

(6) The NetRep initiates an engagement with a visitor. The initiation includes an introductorv message to the visitor is sent to the NetRep server.

(7) The database is updated with the new status and introduction message.

(8) The capture server is notified that the NetRep is engaging a visitor. The NetRep id, visitor's id. and initial message is sent as parameters.

(9) The heartbeat function from the hidden frame asks.. he ISAPI extension if this visitor is engaged or not.

(10) The extension asks the capture server if this visitor is engaged.

(11) The capture server notifies the extension that this visitor is engaged.

(12) The wait frame receives a response that the visitor is engaged.

(13) The wait frame requests a full reload of the browser window.

(14) The extension returns the captured frame set to the browser.

(15) The requested page is targeted to the content frame of the captured frame set.

Diagram 4 The following steps show how iContact processes messages being sent from the NetRep to the visitor and from the visitor to the NetRep. The solid lines trace the visitor to the NetRep path and the dashed lines trace the NetRep to the visitor path. Please refer to Diagram 5 while reviewing the following steps.

NetRep to visitor (1) NetRep selects a visitor to send a message to and sends a message.

(2) The database is updated with the nevy status and the text of the message.

(3) The message is forwarded to the capture server.

(4) The capture server updates the CNV Hie associated with the visitor. The C5V files contains the text of the message being sent.

The The hidden frame asks if the visitor has received a new message.

(6) The extension asks the capture server if a new message has been received.

(7) The capture server notifies the server extension that the visitor has received a new message.

(8) The hidden frame receives a response that the visitor has received a new message.

(9) The hidden frame requests that the NetRep message frame be reloaded with the updated CNV file. t 10) The server extension reads the CNV file and convents it to HTML.

(I1)) The NetRep message frame is updated.

Visitor to NetRep (1) The visitor send a message to the NetRep.

(2) The message is sent to the Capture server.

(3) The capture server updates the CNV file associated with the visitor. The CNV files contains the text of the message being sent.

(4) The server extension reads the C5V file and converts it to HTML.

(5) The Visitor message frame is updated with the new text.

(6) The message is forwarded to the NetRep server.

(7) The database is updated with the new status and the text of the message.

(8) The message is sent to the NetRep Diagram 5 The following steps show how iContact can deremune which NetRep is assigned to the Visitor and notify the NetRep that one of their clients is presently on the web site. Please refer to Diagram 5 while reviewing the following steps.

(1) When a web visitor first accesses the web site they aie registered into iContact. iContact returns a frame set to the visitor's browser that will stay with the visitor during their visit. The frame set allows iContact to track and identify the visitor. Since they have yet to login to the web site. and be identified, they are not displayed on any of the NetRep's workstations.

(2) The visitor logs into the web site. Upon successfully logging into the system, a page associated with the visitor's NetRep, in this case NI. Owens, is returned to the visitor's browser.

(3) The returned page immediately requests a page from the iContact server. The requested page's title is the iContact system identifier assigned to the NetRep when their account was created, in this case "mowens" (actual identifier is numeric).

(4) The page request notifies the iContact system that this visitor has requested a page with the title of "mowens". The page is returned to the visitor's browser and the request is passed on to the NetRep client applications installed on the NetRep's workstations.

(5) The visitor's iContact assigned system identifier (25736) and the title of the page they requested ("mowens") is sent to all the NetReps logged into the system. Each client application will determine if they are allowed to monitor this individual. This is done by checking if the page title (a. k. a. NetRep's system identifier) is in their filter list or the visitor's identifier is in their active list.

(6) In this case the page title is in Ní. Owens'filter list. so the visitor will now appear in his NetRep client application's Visitor List. vu. Owens can also be notified by any combination of audible and visual indicators generated by the NetRep client application.

(7) The visitor can continue surfing through the web site normally. \í. Owens will not be aware of which page they are viewing, only that they are still on the site.

(8) If it is determmed that knowing the specific page (or section of the web site) the visitor is viewing is necessary then the request for the specific page (or first page of the section) will be made through iContact. iContact will return the requested page to the visitor s browser and pass the request on to the NetRep client applications.

(9) The visitor's system assigned identifier (25736) and the title of the page they requested ("quotes") is sent to all the NetReps logged into the system. Each client application will determine if they are allowed to monitor this individual. They do this by checking if the page title (a. k. a. NetRep's system identifier) is in their filter list or the visitor's identifier is in their active list. <BR> <BR> <BR> <P>(10) In this case the visitor's identifier is in M. Owens'active list, so the entry in M. Owens'Visitor List will be updated. M. Owens can also be notified by any combination of audible and visual indicators generated by the NetRep client application if this new page is in his page notification list.

Diagram 6 The following steps show how visitors can determine whether their NetRep is monitoring the site and available to assist them. Please refer to Diagrams 6A & 6B while review the following steps.

Contacting their registered NetRep <BR> <BR> (1) The visitor decides they want to communicate with their Netrep using iContact. They click a"Contact a Company Representative"link which displays a list of available NetReps. The link can be distributed throughout the web site. The list will contain all the NetReps registered to use iContact or it can also include unregistered NetReps with a list of alternative contact methods like telephone number, email, or an automatic call back form.

(2) The visitor selects his/her NetRep from the list and clicks their name, in this case"M. Owens".

(3) This sends a request to the iContact system for M. Owens. The request consists of the visitors unique identifier. the NetRep's identifier, and the LRL of a page with the title of"mowens".

(4) iContact checks to see if the requested NetRep,"mowens", is logged into the system by checking the NetRep status list on the iContact server.

(5) If M. Owens is logged into the system. then a page requesting the visitor to"Please Wait for Contact" will be returned to the visitor's browser. Otherwise a message stating that the requested NetRep is not available will be retumed. Alternate methods of contact can also be displayed at this time.

(6) If M. Owens is logged into the system, the visitor's iContact assigned system identifier (25736) and the title of the page they requested ("mowens") is sent to all the NetReps logged into the system. Each client application will determine if they are allowed to monitor this individual. This is done by checking if the page title (a. k. a. NetRep's system identifier) is in their filter list or the visitor's identifier is in their active list.

(7) In this case the page title is in NI. Owens'filter list and the system identifier is in his Active List. The visitor's entry in Owens'Visitor List will change its state from"Available"to"HI"designating that they have requested contact. Owens can also be notified by any combination of audible and visual indicators generated by the NetRep client application.

Contacting another registered NetRep <BR> <BR> <BR> (1) The visitor decides they want to communicate with another NetRep if theirs is not available. They click a"Contact a Company Representative"link which displays a list of available NetReps. The link can be distributed throughout the web site. The list will contain all the NetReps registered to use iContact or it can also include unregistered NetReps with a list of alternative contact methods like telephone number, email. or an automatic call back form.

(2) The visitor selects a NetRep from the list and clicks their name. in this case"R. Lincoln".

(3) This sends a request to the iContact system for R. Lincoln. The request consists of the visitors unique identifier, the NetRep's identifier. and the LT-L a page with the title of"rlincoln".

(4) iContact checks to see if the requested NetRep,"rlincoln", is logged into the system by checking the NetRep status list on the iContact server If If R. Lincoln is logged into the system. then a page requesting the visitor to"Please Wait for Contact" will be returned to the visitor's browser. Otherwise a message stating that the requested NetRep is not available will be returned. Alternate methods of contact can also be displayed at this time.

(6) If R. Lincoln is logged into the system. the isitor's iContact assigned system identifier (25-36) and the title of the page they requested ("rlincoln") is sent to all the NetReps logged into the system. Each client application will determine if they are allowed to monitor this individual. This is done by checking if the page title (a. k. a. NetRep's system identifier) is in their filter list or the visitor's identifier is in their active list. <BR> <BR> <BR> <BR> <P>(7) In this case the page title is : ^. R. Lincoln's filter list, so the visitor will now appear in his NetRep client application's Visitor List with it's state set to"HI"designating that they have requested contact.

(8) In this case the system identifier is in M. Owens'Active List. The visitor's entry in M. Owens'Visitor List will change its state from"Available"to"HI"designating that they have requested contact. iContact technical description Diagram 7 The following components are used in a large scale custom implementanon. Please refer to Diagram 7 while reviewing the following steps.

Enterprise Components (1) ISAPI Server ExtensionFilter pair-Each ISAPI server extension uses its own set of template files. This provides the ability to manage separate/distinct web sites, separateidistinct sections of a web site. and individual groups of pages as separate entities with their own sets of template files. Each extensions can be replaced with 2 filters. The filters will allow the imbedding of the unique identifier without requiring extensive page modification.

(2) Capture Server-Vfanages one or many server extensions or filter pairs. Multiple capture servers allow for load distribution. Capture servers can run on multiple servers.

(3) NetRep Server-Manages NetRep client applications through multiple message servers. Also distributes information to and from databases.

(4) Messaging Server-Manages the distribution of messages between NetRep client applications and ti. e NetRep serxer.

Used for load balancé.

The NetRep admmistration m. : oy manaees NetRep groups, preset messages, and tour guide locations. Tour Guide locations are used to push pages to web visitors who have been engaged.

(6) Database Controller-Vfanages access and control to the iContact and other associated databases.

(7) NetRep client application.

(S) Web site Administration - Used to manage the configuration of the server extensions, filters and the capture servers.

Diagram 8 The following steps show how an HTTP server deveioped by Contact Dynamics would be used to manage multiple separate and distinct web sites by an out sourced call center. The use of a custom server provides the following benefits : 1. Minimum to no modification of the call center's client's web pages.

2. The call center can tum off the web monitoring and direct the client's web site to function normally, bv not going through Contact Dynamics'server without affecting the web pages on the site.

Please refer to Diagram 8 while reviewing the following steps.

New page request (A) Visitor requests a page. The request is received by the iContact servet.

(B) The iContact server notifies the NetRep server of the page request.

(C) The NetRep server notifies the appropnate group of NetReps. A messaging server may or may not be used.

(D) The iContact server requests the page from the appropriate web server The web server may be located anyvhere on the Internet.

(E) The web server returns the requested page to the iContact server.

(F) The iContact server compares the creanon date of the returned page with the processed page cached on its hard drive. If the page has been updated the server will process the page and replace the old processed page with the new page. If the page has not been updated the server discards the new page.

(G) The iContact server returns the processed page to the visitor's browser.

(H) The Visitor's browser requests the graphic files directly from the web server.

(I) The web server retums the graphic fiies.

Diagram 9 Each frameset returned to a Surfer contains a hidden heartbeat function as part of the content. Two heartbeat functions are used-one for Engaged Surfers and one for Unengaged Surfers. The logic flow of each is shown in diagrams 9-a and 9-b. pagel.html Regular untreated page. (Local Installation) <HMTML> <HFAD> <TITLE>Page1</TITLE> </HEAD> <BODY> <A HREF="page1.html">Link 1</A> <br> <A HREF="page2.html">Link 2</A> <br> </BODY> </HTML> pagel_icx.html Treated page. (Local Installation) <HTML> <HEAD> <BR> <BR> <TITLE> ? agel</TIT 7E><BR> <BR> <BR> <BR> </HEAD> <BODY> <RD_DONE01> <1--<a href="page1.html">Link 1</A>--> <script language="JavaScript"> <!-- document.write("<a href='/bin/icx.dil?npage?%2Fpage2%2 Ehtm'&"+ top.document.title + "' target='_top'>") document.write("Link 1") document. wrice ( // --> </script> <noscript> <a href="/bin/icx.dll?npage?%2Fpage1%2Ehtml&-1" target="_top" >Lnk k 1</a> </noscript> </RD_DONE01> <br> <RD DONE01> < !--<a href="page2,html">Link 2</A>--> <script language="JavaScript"> <BR> <BR> c !--<BR> <BR> <BR> document. wriae ("<a hr6f='/bin/'icx. dll ? npage ? % 2Fpage2% 2<BR> <BR> <BR> <BR> <BR> Ehtml&" +<BR> <BR> <BR> top.document.title + "' target='_top'>") pagelicx.html document, w-te ("Link 2") document.write("</a>") // --> </script> <BR> <BR> <noscript><BR> <BR> <a href="/bin/icx.dll?npage?%2Fpage2%2Ehtml&-1" target="_top" >Link 2</a> </noscript> </RD_DONE01> <br> </BODY :.

</HTML> page2icx. html Treated page. (Redirection) <BR> <BR> <BR> <BR> <BR> <BR> <BR> <HTML><BR> <BR> <BR> <BR> c HEiN <TITLE>Page2</TITLE> </HEAD> <BODY> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <RE_DCNfi<BR> <BR> <BR> <BR> < !--<a liref ="http ://192. 168.1.1/page1.html">Link 1</A>--> <script language="JavaScript"> <!-- document.write("<a <BR> <BR> href='/bin/iex.dll?npage?http%3A%2F%2F192%2E168%2E1%2E1%2Fpa ge1%2Ehtm1 &"+ top.document.title + "' target='_top'>") document.write("Link 1") document.write("</a>") // --> </script> <noscript> <a href="/bin/icx.dll?npage?http%3A%2F%2F192%2E168%2E1%2E1%2Fp agel%2Ehtml&-1" target="_top" >Link 1</a> </noscript> </RnDONE01> <br> <RD_DONE01> <!--<a href="http://192.168.1.1/page2.html">Link 2</A>--> <script language_"JavaScript"> <!-- document. write ("<a href='/bin/icx.dll?npage?http%3A%2F%2F192%2E168%2E1%2E1%2Fpa ge2%2Ehtml &"+ top. document.title'"'target='top'>") document.write ("Link 2") page2_icx.html document.write("</a>") // --> </script> <BR> <BR> <noscript><BR> <BR> <a href="/bin/icx.dll?npage?http%3A%2F%2F192%2E168%2E1%2E1%2Fp age2%2Ehtml&-1" target="_top" >Link 2</a> </noscript> </RD_DONE01> <br> </BODY> </HTML> page2.html Regular untreated page. (Redirection) <HTML> <HEAD> <TITLE>Page2</TITLE> </HEAD> <BODY> <BR> <BR> <BR> <BR> <A HREF="http://192.168.1.1/page1.html">Link 1</A> <br><BR> <BR> <BR> <A HREF="http://192.168.1.1/page2.html">Link 2</A> <br> </BODY> </HTML> EXEMPLARY CONVERSATION N-Representative of Site S-Visitor at Site MESSAGE TEXT SENDER TIME & DATE Hi, I'm Sue with Contact Dynamics. I'm here live, can I help you? N 8/5/98 5:33:39 PM Good evening! N 8/5/98 5:34:04 PM If you look to your right and touch compose message and begin typing in N 8/5/98 5:34:09 PM the box, we can talk. I'm just trying this out as a demo. You probably get that a lot. S 8/5/98 5:34:48 PM ShopcyberMall, so nice of you to visit!! N 8/5/98 5:35:20 PM Thanks. We are currently using live chat on our web site, but we had S o/5/98 5 : 36 : 02 PM someone email us to look at you guys. Yes, I do, and it's my job, so I never mind. BTW, you have the hands n 8/5/98 5 : 36 : 07 PM down coolest catalog ! ! That's the consensus from our office ! ! l That was me N 8/5/98 5 : 36 : 16 PM Thanks ! ! S 8/5/98 5 : 36 : 25 PM No live chat, this is a powerful sales tool and lead generator, N 8/5/98 5:36:36 PM There are two models of Contact. Inbound and Outbound. I use both at N 8/5/98 5 : 38 : 53 PM the same time. Outbound allows you to see the surfers on the site, where they are, and N 8/5/98 5 : 39 : 17 PM how long they stay. With Outbound you can initiate a conversation with any surfer at any time. This is how I saw you enter the site and how I captured you ! ! It is unique to us atone. How are you saying that? How is this different from Interactive Express? S 8/5/98 5:39:21 PM 70% of all people who engage your commerce server do not finish the N 8/5/98 5:39:48 PM transaction. Our software can make a difference.

MESSAGE TEXT SENDER TIME & DATE Okay, but how is this different from your competitor XYZ's S 8/5/98 5:40:25 PM They can't engage a surfer. They have to wait for a request for N 8/5/98 5:40:27 PM assistance. We don't wait!! Oh, I see, When would you feel it necessary to interrupt a shopper? S 8/5/98 5:41:01 PM Let me show you our interface. Click direcdy on the next message I send N 8/5/98 5 : 41 : 07 PM you. Don't'think of it as interrupting, you're assisting, just like a high line N 8/5/98 5 : 41 : 49 PM department store would. Plus, we don't have to download any junk into your surfers machines N 8/5/98 5 : 43 : 12 PM No downloads, applets, cookies or plug ins N 8/5/98 5 : 43 : 28 PM Contact is a server extension browser driven. It uses NT. We can talk n 8/5/98 5 : 43 : 36 PM with any visitor that has a browser that was written within the last two years. I can conduct five individual conversations at one time on my station. N 8/5/98 5:43:53 PM Although I can actually see thirty surfers in the queue How do you contact them ? Does a window just open up in the middle of S 8/5/98 5 : 44 : 11 PM i their visit ? How can you tell who they are ? l Just like what you are looking at right now ! ! But, it can be customized N 8/5/98 5 : 44 : 42 PM however you would like. I can actually see them on my side. Want to see ? N 8/5/98 5 : 45 : 01 PM Sure S 8/5/98 5 : 45 : 17 PM I trace them to know who they are. N 8/5/98 5 : 45 : 22 PM Go to Contact Inbound or you can just click on my message to you and it N 8/5/98 5 : 45 : 57 PM will take you there. < a href="/out-zoom. htm" target"content"> Click here for a Netrep N 8/5/98 5 : 46 : 14 PM screen shot < a > You haven't moved yet. That's the other thing. I can see where the surfer n 8/5/98 5 : 48 : 03 PM goes and have a history of their last ten pages that they visited. You've got it now, and you can zoom on that picture to get a better look. N 8/5/98 5 : 57 : 16 PM Where do you see who I am ? S 8/5/98 5 : 58 : 07 PM Lower left are the surfers, and your IP number can be traced through a N 8/5/98 5 : 59 : 06 PM simple tracing program. I can get name and address of the company you are with from a static server AOL you just get numbers, can't trace those. ! 8/5/98 5 : 59 : 20 PM Figures-S 8/5/98 5 : 59 : 38 PM The captured surfers have unique identifier numbers between the two N 8/5/98 5 : 59 : 56 PM windows on the bottom So, Contact Dynamics is the surfer here ? S 8/5/98 5 : 59 : 58 PM Wow-I am impressed ! ! N 8/5/98 6 : 00 : 26 PM You are the first person that noticed N 8/5/98 6 : 00 : 39 PM Don't get too excite, that's my job. S 8/5/98 6 : 00 : 47 PM MESSAGE TEXT SENDER TIME & DATE Maybe I'm the 1st person who cares. S 8/5/98 6:01:07 PM Mine too, but it's also a lot of other peoples jobs that visit me, no one has N 8/5/98 6 : 01 : 34 PM got it yet. You must be a woman ! ! Please tell me I'm right ! ! Yes, you must be too. N 8/5/98 6 : 01 : 57 PM Hooray ! ! N 8/5/98 6 : 01 : 26 PM Hear us ROAR ! S 8/5/98 6 : 02 : 46 PM It's funny how this works, but I can even tell if a person is having a bad N 8/5/98 6 : 03 : 31 PM day on this. It's very intimate. The surfers get comfortable very quickly. The response was far greater than we ever dreamed possible. Neat. Do you have an information packet you can send to me ? You have S 8/5/98 6 : 04 : 39 PM my address... my name is Jane Doe. Director of commerce. Please advise. Yes, Jane, I do. Can you supply me with your address. I'll get it out in N 8/5/98 6 : 05 : 21 PM a flash ! ! Maybe you would even like an eval demo, huh ? N 8/5/98 6 : 05 : 42 PM I thought my address came up for you. S 8/5/98 6 : 06 : 12 PM Yep. S 8/5/98 6 : 06 : 23 PM Jane, I'm sorry, I did have that address. N 8/5/98 6 : 07 : 10 PM Well, I'll send you the info and if you wouldn't mind a call from a rep, I N 8/5/98 6 : 07 : 39 PM 0 can get you the eval. Okay, I'm going to go now. Phone number is 111-555-6789. I'll be out S 8/5/98 6 : 08 : 36 PM of town tomorrow and Friday and out of the office next week Tues. and Wed, and possibly Thur and Friday. Busy schedule! Later! Sarah, I'm so glad you stopped by. You've been a delight! N 8/5/98 6:09:33 PM Thanks! S 8/5/98 6:09:54 PM FYI-Our granddaughter's name is Jane. So, we have a kinship already ! ! N 8/5/98 6 : 10 : 12 PM

From the foregoing, it will be observed that numerous variations and modifications may be effected without departing from the spirit and scope of the invention. It is to be understood that no limitation with respect to the specific apparatus illustrated herein is intended or should be inferred. It is, of course, intended to cover by the appended claims all such modifications as fall within the scope of the claims.