WO2002021312A2 - System and method for facilitating coordinated browsing of data objects - Google Patents

System and method for facilitating coordinated browsing of data objects Download PDF

Info

Publication number
WO2002021312A2
WO2002021312A2 PCT/US2001/026968 US0126968W WO0221312A2 WO 2002021312 A2 WO2002021312 A2 WO 2002021312A2 US 0126968 W US0126968 W US 0126968W WO 0221312 A2 WO0221312 A2 WO 0221312A2
Authority
WO
WIPO (PCT)
Prior art keywords
data object
target data
client
clients
application server
Prior art date
Application number
PCT/US2001/026968
Other languages
French (fr)
Other versions
WO2002021312A3 (en
Inventor
Yuval Nahon
Rami Winestock
Original Assignee
Vocaltec Communications Ltd.
Vocaltec Communications, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/797,420 external-priority patent/US20020049812A1/en
Priority claimed from US09/885,860 external-priority patent/US20020029245A1/en
Application filed by Vocaltec Communications Ltd., Vocaltec Communications, Inc. filed Critical Vocaltec Communications Ltd.
Priority to AU2001286912A priority Critical patent/AU2001286912A1/en
Publication of WO2002021312A2 publication Critical patent/WO2002021312A2/en
Publication of WO2002021312A3 publication Critical patent/WO2002021312A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/289Object oriented databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/954Navigation, e.g. using categorised browsing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/566Grouping or aggregating service requests, e.g. for unified processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2216/00Indexing scheme relating to additional aspects of information retrieval not explicitly covered by G06F16/00 and subgroups
    • G06F2216/15Synchronised browsing

Definitions

  • the present invention is related applications over Internet Protocol (IP) networks. Particularly, it is directed to methods and systems where client network browsers are synchronized, such that two clients can view the same web page or data object at the same time or "cobrowse", in a coordinated data collaboration session over a network, such as the Internet. More, particularly, the present invention is directed to methods and systems for supporting cosurfing applications where clients link to a server, that serves as an intermediary to the Internet, such that this server provides ail clients accesses to the Internet through a single channel or "pipe”.
  • IP Internet Protocol
  • Typical e-commerce applications are based on cobrowsing, where two users or clients browsers are coordinated, and typically synchronized, such that they can both view the same data object, typically a web page within a web document (collectively a "web page") at the same time.
  • This is typically achieved by both users or clients, commonly known as surfers, who are each connected to the Internet as well as a Data Collaboration (DC) Server.
  • the DC Server receives the Uniform Resource Locator (URL) of a user for the web page or data object being viewed by the client customer.
  • This URL is then transferred from the DC Server to the browser of a second user, typically the client agent, who then obtains the data object, e.g., web page, corresponding to the URL from the Internet or other suitable network.
  • URL Uniform Resource Locator
  • This signaling mechanism is typically in a footer to the web page, that signals the DC server by passing through a signaling application in the browser, commonly referred to as a "traffic cop".
  • This footer is typically code within Hypertext Markup Language (HTML), such as an HTML formatted file that an organization added to its web page on its server.
  • the traffic cop is, for example, a Java applet that holds a signaling interface to the DC server and monitors footers for events.
  • the customer will download the requisite software, code, etc., from this organization's, company's or the like (hereafter "organization) server, in order to perform transactions requiring cobrowsing.
  • organization This organization's, company's or the like
  • These software packages can be expensive, to a price point where an organization may find it unprofitable to facilitate e-commerce in this manner or this may be an entry barrier for e- commerce.
  • a footer installed on a web page interferes with regular browsing, as it searches for a "traffic cop" application, that is only present in cobrowsing and not present during regular browsing.
  • the footer must be recognizable to the traffic cop, as being an event of the same domain, if the URL of the web page is to be passed to the DC Server. Otherwise, the URL for the web page would be stopped by the traffic cop and not passed to the DC Server. Thus, should a linked web page of one domain be in the same series of frames with a traffic cop of a different domain, this web page can not be cobrowsed as the traffic cop will not pass its URL to the DC server. Rather, the sender will receive an error message that this operation is not possible. Likewise, if a web page from a different domain to that of the customer's (or client's) suddenly appears in the frames that have been customized to have the same number of domains, an error message will also appear. This often occurs when a web site or customer, has a link to a different web site, and the web page is taken from a different domain when the link is selected.
  • the present invention improves on the contemporary art by providing systems and methods for coordinating browsing or cobrowsing that employ an intermediate or proxy server between the clients (customer and agent) and the
  • This intermediate server is configured such that during a cobrowsing event between at least two clients, the network, such as the
  • Internet is accessed a single time through a single. channel or "pipe" for all clients of this cobrowsing event. Accordingly, once one cobrowsing client requests a particular target data object, typically a web page, only one HTTP request is generated, for example by a HTTP "post" command. From this single request and subsequent single retrieval of the web page through the single channel or "pipe", all clients will receive this target web page. In an e-commerce application, only one order would be generated, as the network, such as the Internet, would only have been accessed once, through a single channel or "pipe” for all cobrowsing clients.
  • this single channel or "pipe” network access results in faster transmissions of data objects, typically web pages to the clients, when compared to all clients accessing the same web page, each through their own separate channels. Additionally, in an e-commerce application, only one order would be generated, as a result of this single time, single channel access to the desired web page.
  • the intermediate or proxy server of the present invention eliminates the need for each organization to have its own cobrowsing application in or associated with its server, as instead, the organization need only have a link on their web page to the intermediate or proxy server. This is because the intermediate server is configured to pass a cobrowsing functionality to the recipient client in addition to providing a single channel or "pipe" to the Internet for all clients of a cobrowsing session.
  • One embodiment of the present invention is directed to a system for facilitating coordinated browsing of a data object or objects, typically a web page or web pages, from a web application server, between at least two clients.
  • This embodiment comprises, a first utility for opening a channel to at least one web application server on a network, typically the Internet, and retrieving at least one target data object from this at least one web application server through the opened channel in accordance with a request for this data object from a first client.
  • There is a second utility for providing the at least one target data object retrieved from the at least one application server to a storage medium.
  • There is a third utility for transferring this at least one data object from the storage medium to the first client, who requested this target data object (otherwise known as the requesting client).
  • This system can also include a fifth utility for changing the domain of the retrieved at least one target data object data to the domain corresponding to the first utility, and placing a command onto the retrieved target data object to access the first utility, when a second target data object is requested by any of the clients. Additionally, the system can be such that the first utility is responsive to a link on a web page, when this link is activated by at least one of the clients.
  • Another embodiment of the present invention is directed to a system for facilitating coordinated browsing of data objects, typically web pages, from a web application server, between at least two clients.
  • This system comprises a server for positioning intermediate the at least two clients and a network, typically the Internet.
  • the server comprises a storage medium and a processor.
  • the processor is programmed to: open a channel to at least one web application server on the network, and retrieve at least one target data object from this at least one web application server through the opened channel in accordance with a request for this data object from a first client; provide at least one target data object retrieved from the at least one application server to a storage medium; transfer this at least one data object from the storage medium to the first client; and transfer the at least one data object from the storage medium to a second client, in response to a corresponding request for the data object from the second client.
  • the processor is additionally programmed to change the domain of the retrieved at least one target data object to the domain corresponding to that of the server; and place a command onto the retrieved target data object to access the server, when a second target data object is requested by any of the clients.
  • the system may also include a web page having a link to the server, and also included may be a data collaboration server configured for holding and synchronizing cobrowsing events between the clients.
  • Another embodiment of the invention is directed to a method for coordinated browsing of data objects, typically web pages, from a web application server, between at least two clients.
  • This method comprises, opening a channel to at least one web application server on a network, typically the Internet, and retrieving at least one target data object, typically a web page, from the at least one web application server through the opened channel in accordance with a request for this data object from a first client.
  • This at least one target data object retrieved from the at least one application server is provided to a storage medium.
  • the at least one data object is transferred from the storage medium to the first client, and this at least one data object is also transferred from said storage medium to a second client, in response to a corresponding request for this data object from the second client.
  • the method may also include changing the domain of the retrieved at least one target data object to the domain corresponding to that of a network accessing component, such as a server, intermediate the clients and the network, for accessing the at least one web application server; and placing a command onto the retrieved target data object to access the intermediate server, when a second target data object is requested by any of the clients.
  • the method may also include accessing this intermediate server by a client activating a link on a web page, this link for directing the client browser to this intermediate server.
  • Another embodiment of the invention is directed to a method for facilitating coordinated browsing of data objects, typically web pages, from a web application server on a network, typically the Internet, between at least two clients.
  • the method comprises positioning a server intermediate the at least two clients and the network, opening a channel to the at least one web application server on the network, and retrieving at least one target data object (e.g., a web page) from the at least one web application server through the opened channel in accordance with a request for the data object from a first client.
  • the at least one target data object retrieved from the at least one application server is then provided to a storage medium.
  • the stored data object is then transferred from the storage medium to the first client and from the storage medium to the second client, this transfer to the second client in response to a corresponding request for the data object from this second client.
  • This method may additionally comprise providing a web page having a link to the server, with a client activating this link, as well as providing a data collaboration server for holding and synchronizing cobrowsing, typically in each cobrowsing event, between the clients.
  • Another embodiment of the present invention is directed to a method for facilitating coordinated browsing of data objects, typically web pages, from a web application server on a network, typically the Internet, between at least two clients, from the client side.
  • This method comprises a first client transmitting a first request for a target data object to a server intermediate the at least two clients and the network, for this intermediate server to retrieve the at least one target data object from a web application server on the network and this first client transmitting a second request to a second client to access this intermediate server, for retrieving the at least one target data object in accordance with the first request.
  • Fig. 1 is a diagram of an exemplary set up employing an embodiment of the present invention
  • Figs. 2a and 2b are a flow diagram of a process in accordance with an embodiment of the present invention for the initial cobrowsing event
  • Fig. 3a is a schematic diagram of frames as assembled into a web document in accordance with an embodiment of the present invention
  • Fig. 3b is a screen shot of a web document in accordance with an embodiment of the present invention
  • Fig. 4 is a diagram of the exemplary set-up of Fig. 1 in a subsequent cobrowsing event
  • Fig. 5 is a flow diagram of a process in accordance with an embodiment of the present invention for subsequent cobrowsing events
  • Fig. 6 is a diagram of the an alternate embodiment of the intermediate or proxy server in a system in accordance with the present invention.
  • Fig. 7 is diagram detailing the operation of the rule filter of Fig. 6.
  • Fig. 1 shows an exemplary set up employing an embodiment of the present invention.
  • Both the customer 20 and agent 22 clients are configured for connecting to a Data Collaboration (DC) Server 26 and an Intermediate or proxy server 30, respectively.
  • This Intermediate or proxy server 30, typically communicates with a network, such as a local area network (LAN) or a wide area network (WAN), typically the Internet 34.
  • Various web servers 36, 37, 38 are connected to the Internet 34.
  • These servers 36-38 are exemplary of the endless number of servers that are connected to the Internet 34.
  • the customer 20 has a multimedia workstation, such as a multimedia PC 20a (e.g., with a Pentium® CPU from Intel Corporation, Santa Clara, California 95052) with voice and data capabilities.
  • a cobrowsing application with voice and data capabilities may be used, such as any of the Surf & CallTM cobrowsing applications available from VocalTec, Herzlia, Israel.
  • the multimedia PC 20a employs an operating system such as Windows® NT® (from Microsoft Corporation, Redmond, Washington 98052) or the like, and is equipped with a suitable modem or other hardware for accessing the DC Server 26, intermediate server 30, and network, such as the wide area network (WAN), here the Internet 34.
  • Windows® NT® from Microsoft Corporation, Redmond, Washington 98052
  • network such as the wide area network (WAN), here the Internet 34.
  • WAN wide area network
  • the PC 20a is also loaded with software that operates as a browser for the Internet.
  • Exemplary browsers suitable for use here including Microsoft® Internet Explorer® (Microsoft Corporation, Redmond, WA) and Netscape® Navigator® and Netscape® Communicator, the later two from Netscape Communications Corporation, Mountain View, California 94043.
  • Microsoft® Internet Explorer® Microsoft Corporation, Redmond, WA
  • Netscape® Navigator® and Netscape® Communicator the later two from Netscape Communications Corporation, Mountain View, California 94043.
  • On the agent side is typically at least one web enabled agent 22. While one agent is shown and described, this is exemplary only, for any number of agents (one or greater) is permissible in accordance with the present invention.
  • the agent 22 is typically equipped with a multimedia workstation, such as a multimedia PC 22a with voice and data capabilities, and includes browsers, in accordance with those detailed above.
  • the agent 22 can also use regular (POTS) telephone for audio, typically voice.
  • POTS regular
  • the DC Server 26 is typically a server with software and or hardware arranged therein for holding and synchronizing cobrowsing sessions between clients, here for example, the customer 20 and the agent 22, described in detail below. It may also be connected to other servers, such as T-servers and the like, that support voice and data communications.
  • the intermediate or proxy server 30 is connected to the Internet 34 in a way that it accesses Internet and retrieves the requested data object, data stream or the like, that is typically a web page (and will be referred to hereinafter as "web page"), through a single connection (channel or "pipe"). This allows for the same web page, as retrieved through the single channel or "pipe", to subsequently be sent to both customer 20 and agent 22.
  • This Intermediate Server 30 typically includes a processor (P) 39 programmed such that in conjunction with software, hardware or both, accesses the Internet and retrieves any requested web page in communication with a storage unit 40 or other similar data storage device or storage medium with addressable memory units (A1-An).
  • the server 30 also includes hardware, software or combinations thereof, that in conjunction with the processor (P) 39, programmed accordingly, assembles web documents for both the customer 20 and agent 22. These web documents include at least the web page and a footer, typically both in frames. One web document is assembled to appear as a customer workstation on the monitor of the client customer 20 (detailed below).
  • This web document can be formed, for example, as the intermediate server 30 takes the retrieved web page and adds a footer to this page, a cobrowsing functionality, a traffic cop or signaling functionality, and optionally, a form sharing page functionality, for example Surf & ChatTM (VocalTec Communications Ltd., Herzlia 46733, Israel).
  • AH of these functionalities may be stored in the storage unit 40 of the intermediate server 30, or can be retrieved from various servers on the Internet 34. All of these functionalities are of the same domain, that of the intermediate server 30, such that the retrieved web page can be cobrowsed by both customer 20 and agent 22, as detailed below.
  • the cobrowsing functionality may for example, be any of the Surf & Call® applications, for example Surf & Call® CenterTM from VocalTec Communications Ltd., Herzlia 46332, Israel.
  • This Surf & Call® CenterTM includes an embedded plug-in for facilitating an Internet Protocol (IP) call between clients, here customer 20 and agent 22 along with a Cosurfer Data Collaboration (DC) Component, such as the VocalTec® Cosurfer DC ComponentTM (VocalTec Communications, Ltd., Herzlia 46332, Israel), for facilitating data calls to the DC server 26.
  • IP Internet Protocol
  • DC Cosurfer Data Collaboration
  • the footer is typically code that dynamically replaces the real target location (the URL) with the location (the URL) of the intermediate or proxy server 30. It also invokes a surf command, typically HTTP language, code, etc., for the recipient client (via their respective workstation) to go to the Intermediate or proxy server 30 and ultimately retrieve the real target web page from the Internet, or alternately, from the intermediate or proxy server 30, if the web page has been retrieved by a cobrowsing client prior to this.
  • Figs. 2a and 2b implementation of an initial cobrowsing processor event, in accordance with the present invention, will now be described in an exemplary e-commerce application.
  • the server operator here the server of the agent client 38
  • the link typically includes a surf command, such as an HTTP command- for the intermediate or proxy server 30 to retrieve the requested (target) web page from the Internet 34.
  • This command also instructs the retrieval of the real (target) web page by the intermediate or proxy server 30 to have an associated identifier, typically a unique identifier (UID), as detailed below.
  • UID unique identifier
  • the web page is placed into the storage unit 40 with this unique identifier.
  • this web page originates from the server operator's server, labeled 38.
  • this server 38 has a URL of http://www.abc.com, such that its domain is "abc”.
  • the web page of address abc.com will include a link to the intermediate or proxy server.
  • This link can appear on the web page as a hypertext block or the like, activated by clicking (pressing) a mouse or the like.
  • this hypertext block may be a text message such as, "DO YOU WANT HELP IN BROWSING?"
  • the client here the customer 20, now activates the link on this web page, at block 102, and the client customer's browser is routed to the Intermediate or proxy server 30, at block 104.
  • the Intermediate server 30 then opens a connection (channel or "pipe"), such as an HTTP connection, to the real (target) site and requests this URL (i.e., requests the web page corresponding to the URL) from the Internet 34, at block 106.
  • the web page corresponding to this URL is then retrieved, at block 108.
  • a unique identifier typically a series of numbers unique to this web page retrieval, that follows requests for this web page, is in place when the intermediate or proxy server retrieves the desired (target) web page from the Internet 34.
  • This unique identifier can be generated in the browser, intermediate or proxy server 30 or in any other server or the like along the Internet 34.
  • the specific UID for this first cobrowsing event is 33333.
  • the command to retrieve a web page from the intermediate or proxy server 30 also contains a command to attach the UID to this particular event.
  • the now-retrieved web page corresponding to this URL www.abc.com is stored in the storage unit 40, with the unique identifier in an addressable memory unit(s).
  • the retrieved web page will now become part of a web document, that will appear as a customer work station on the workstation 20a of the customer client 20.
  • the web document assembly occurs as the source web page address, here abc.com, is parsed to a source web document address, contacting the intermediate or proxy server address, here proxy.com.
  • the web page, here, abc.com is parsed and converted to a frame. Parsing involves embedding the web page's original URL, here abc.com, within an address containing the URL of the domain of the Intermediate or proxy server, here proxy.com. This ensures that the domain is now that of the intermediate or proxy server.
  • the unique identifier (UID) associated with the web page in the storage device 40 is attached to the page during the parsing process.
  • the parsed address here proxy.com
  • This command indicates connecting to the URL, abc.com, through the intermediate or proxy server 30 (the domain of the intermediate or proxy server 30 is "proxy") and a unique identifier, typically digits, here "33333".
  • This unique identifier is specific to the original client cobrowsing request for the web page, here the URL abc.com.
  • the above listed HTTP command is a surf command for a footer. This footer is added as a frame to the web page, as part of the web document being assembled.
  • FIG. 3a schematically shows the assembled web document 200, including frames for the web page 201, footer 202, cobrowsing application 203, traffic cop 204, and optionally, a form sharing application 205.
  • This assembled web document 200 is sent to the client, here the customer 20, at block 112. It appears on the monitor of the client workstation, as a customer workstation 200', shown in Fig. 3b.
  • the customer workstation 200' includes the web page frame 201', a footer frame (not shown), a cobrowsing application frame 203', for example any of the cobrowsing applications from VocalTec Communications, Herzlia, Israel, for example, the data collaboration (DC) component, that is part of the VocalTec® Surf & Call® CenterTM, a traffic cop frame (not shown), and optionally, a form sharing page frame (not shown). All of the frames in the assembled web document 200 and resultant customer work station 200', are of the same domain, here "proxy", the domain of the intermediate or proxy server 30.
  • proxy the domain of the intermediate or proxy server 30.
  • the cobrowsing application frame it can for example, work simultaneously with the Surf & Call® embedded plug-in, as represented by the Surf & Call® icon 203", should a Surf & CallTM application be employed.
  • the user here the requisite client, invokes the DC component together with the Surf & Call® plug-in by pressing a single button (clicking on the Surf & Call® icon 203").
  • the customer 20 can now activate the cobrowsing application at block 114, either manually, by clicking on the cobrowsing application frame 203', here, the Surf & Call icon 203", as detailed above, or the cobrowsing application will activate automatically (if the client customer 20 workstation is programmed accordingly, or if the requisite software has been downloaded).
  • the client customer 20 now waits for synchronization of his browser with the browser of the agent, at block 116, to enable the DC server 26 to connect the intended cobrowsing clients. If there is not synchronization between clients (customer and agent), at block 117, the wait continues until there is synchronization. Synchronization may be manual or automatic.
  • the URL of the web page to be cobrowsed and information in the footer (e.g., the command to go to the requested web page via the intermediate or proxy server 30 and the unique identifier) is sent to the DC server 26, from the client (here, the customer client 20), at block 120.
  • the client here, the customer client 20
  • the footer since all frames are of the same domain, here, proxy.com, for the intermediate or proxy server 30, the footer catches the event and the traffic cop functionality allows passage of the footer information to be sent to the DC server 26.
  • the DC server 26 then forwards this footer information to the agent workstation 22a, at block 122.
  • the agent workstation 22a then sends a request (as per the HTTP command) to the intermediate server 30 for the original web page, http://www.abc.com, at block 126.
  • the intermediate server 30 receives this request, the unique identifiers are matched at block 128.
  • the stored web page is retrieved from the requisite memory unit of the storage unit 40.
  • a web document of at least a web page and footer are then sent to the agent workstation at block 130 and received there at block 132.
  • the cobrowsing event is now in progress, at block 134, with the customer 20 and agent 22 in voice and data communication.
  • Fig. 4 details a diagram of the client 20 and agent 22 in an exemplary subsequent cobrowsing event.
  • This drawing figure is similar to Fig. 1 (detailed above), and will have the same components except where indicated.
  • both the client 20 and agent 22 have received the same web page and their browsers are coordinated and synchronized, in accordance with the initial cobrowsing event detailed above.
  • both client and agent workstations have received web documents with web pages 290 with footers 291 (in frames) from the intermediate or proxy server 30 from the preceding cobrowsing event.
  • this subsequent cobrowsing event is also shown in a flow diagram.
  • block 300 could be the cobrowsing detailed above (block 134 of Fig. 2b), from where this subsequent cobrowsing session begins. Alternately, this subsequent cobrowsing event can begin from any other cobrowsing event, where clients are cobrowsing.
  • a cobrowsing client customer or agent requests a different web page, than that of the first request, at block 302.
  • the customer although it could also be the agent, makes a surf command to its browser by requesting a different or new web page, www.xyz.com, such as by clicking (a mouse or the like) on a new link.
  • This request is assigned its own unique identifier (UID), here, for example 34343 (for this subsequent or new cobrowsing event), different from the unique identifier (33333) for the preceding cobrowsing session detailed above.
  • UID unique identifier
  • the surf command is sent to the other client, here the agent workstation 22a, through the DC server 26, with the same unique identifier, here 34343, at block 310.
  • the agent workstation Upon receipt of the command, at block 312, the agent workstation, by virtue of the footer serving as the cobrowsing facilitator (facilitating functionality), sends the URL of the new web page and the unique identifier to the intermediate or proxy server 30, at block 314.
  • the footer of the agent web document has been changed to include the received surf command (this surf command as detailed above).
  • the intermediate or proxy server 30 takes this first received request, at block 324, from the client, here, customer or agent, to the network, e.g., the Internet, by opening a channel or "pipe" thereto (as detailed above), and retrieving the new web page (as detailed above) at block 326.
  • the new web page is placed into the storage unit 40 with addressing therein in accordance with the new unique identifier at block 328.
  • the web page is sent to the workstation of the client whose request was received first, at block 330.
  • the customer would typically receive the web page first (typically as part of a web document detailed above), as his request typically reaches the intermediate or proxy server 30 first, since he initiated the subsequent cobrowsing to www.xyz.com. (Alternately, should the agent's request be received first at the intermediate or proxy server 30, the step above, as well as the steps below would be reversed for customer and agent).
  • the unique identifier in the request is used to find the stored web page of the same unique identifier, at block 334.
  • the web page is sent from the storage unit 40 to the second requesting client's workstation, at block 336.
  • This second request here, is typically from the agent 22, as the customer 20 request reached the intermediate or proxy server 30 first in this example, as detailed above. Cobrowsing continues with the new web page being cobrowsed by the clients, at block 338, and can continue in this manner for as long as desired.
  • Figs. 6 and 7 there is detailed another embodiment of the present invention.
  • This embodiment is directed to web pages, retrieved from various servers into the intermediate or proxy server 30 (detailed above), that are incompatible with the code lines or code portions or segments (collectively referred to herein as "code") for web pages in the intermediate or proxy server 30.
  • the retrieved web page or target data object may be incompatible with the frame arrangement of the intermediate or proxy server 30, or its embedded links are incompatible with the requirement of catching an event (mouse click or keyboard) by the footer in order to access (surf to) the intermediate or proxy server 30, both occurrences described above.
  • the intermediate or proxy server 30, as detailed above has been modified with a rule filter (RF) 400.
  • RF rule filter
  • This modified intermediate or proxy server 30' is similar in all aspects to the intermediate or proxy server 30 detailed above, except with respect to the rule filter 400, and it functions, for example, in conjunction with a system, including components, that has been detailed above and shown in Figs. 1-5.
  • the rule filter 400 is shown as internal to the intermediate or proxy server 30' of Fig. 6, but could also be an external or peripheral component thereto.
  • This rule filter 400 can be software, hardware or combinations thereof. It is used, for example, to change the code on the retrieved web page so that they function correctly in the environment of the intermediate or proxy server 30', or so that footers perform their intended functions.
  • the rule filter 400 includes a rule-based translator 402 that includes a reader 404, storage media 406 and a rule processor 408.
  • the reader 404 is typically a programmable device, such as a chip or card, programmed for recognizing and reading a rule key from the incoming data stream (indicated as Stream A). This stream typically includes the retrieved web page and the rule key is typically the URL of the web page indicating that a rule is associated with the particular web page.
  • the storage media 406 is any conventional data storage unit and typically includes files 410, where single or plural rules are stored. These rules are typically related to web pages, for example www.def.com and www.pqr.com, and are stored in files 410 accordingly. These individual rules are for example, instructions to replace incompatible code on the retrieved web page with alternative specified code. This alternate code is created based on the deficiencies of the original web page of the provider (provider web page), this provider utilizing the services and or functions associated with this intermediate or proxy server 30'. (The original or provider web page becomes the retrieved web page or target data object once accessed by the intermediate or proxy server 30', as detailed above).
  • code lines or code portions or segments from the original or provider web page(s) are obtained, and a corresponding rule or rules is created (and provided to the rule filter 400, typically programmed therein) to accommodate the incompatibility caused by a code lines or code portions or segments associated with the retrieved web page.
  • a corresponding rule or rules is created (and provided to the rule filter 400, typically programmed therein) to accommodate the incompatibility caused by a code lines or code portions or segments associated with the retrieved web page.
  • the retrieved web page is modified, for example, by augmenting, adding, changing, removing, deleting or replacing or any combination thereof, one or more code lines, code portions or segments, to compensate for the incompatible code lines code portions or segments, resulting in a compatible web page.
  • This now compatible web page is suitable for web document assembly in the intermediate or proxy server 30' in accordance with the process detailed for the intermediate or proxy server 30, as shown in Figs. 1- 5 and described above.
  • These rules are typically, for example, from three fields: a) a command, such as, add, replace or remove; b) a source-a regular expression or string on the web page to be, for example, replaced, added or removed; and 3) a destination-typically a code to be added to replace the source.
  • the rule processor 408 is typically a suitable hardware device, software application or combination thereof, configured and/or programmed to change the retrieved web page in accordance with the rule.
  • the rule modifies and/or changes the retrieved web page so that the required functionality can function in the new environment of the intermediate or proxy server 30', as detailed above (with respect to the intermediate or proxy server 30).
  • a web page is retrieved, it enters the rule filter 400 in a data stream (Stream A).
  • the reader 404 attempts to find a rule key, for example, the URL of a web page, from the data stream. If a rule key is not found, the web page is passed to the storage unit 40 of the proxy server 30' (as represented by the broken line arrow of Fig. 7), where it is assembled into a web document as detailed above (for the intermediate or proxy server 30).
  • the corresponding rule or rules file is located in the storage media 406.
  • the rule processor 408 modifies the retrieved web page in accordance with the requisite rule or rules, so as to be compatible with the pre-configured code (lines, portions and/or segments) of the intermediate or proxy server.
  • the modified web page is then placed into a data stream and sent to the storage unit 40 of the intermediate or proxy server 30', for placement into the web document as configured in the intermediate or proxy server 30', as detailed above (for intermediate or proxy server 30).
  • some web pages contain an instruction to place that web page as the top-most frame in a web browser. This would obscure the multiple frames (including the user toolbar/workstation) that the intermediate or proxy server constructs, as described above. Accordingly, when utilizing a rule key, for example, the URL of the web page, a rule is invoked which replaces the command to position the web page topmost (source) with a command that it occupy a regular frame within the user workstation constructed by the intermediate or proxy server functionality.
  • the rule In HTML is, for example, as follows:
  • the destination part of the rule may be left blank.
  • Another alternate may be, for example, when a functionality in a web page does not require an event (mouse click or keyboard), not affording the footer to catch the event and cause the link or functionality to execute via the intermediate or proxy server 30'.
  • the code responsible for the functionality is then replaced with code containing the functionality together with an added command to access (surf to) the intermediate or proxy server 30' to mimic the functionality which the footer would have added.
  • This is achieved with a suitable rule.
  • a Meta tag auto redirect
  • the footer described hereinabove is replaced with a browser plug-in, preferably an active-xTM .
  • This contains code not embedded in a web page but which is compiled.
  • the plug-in performs all the functions of the footer by identifying HTML document events such as mouse and keyboard clicks.
  • the plug-in may additionally identify any browser event including non-mouse/keyboard events. Thus, co-browsing based on the identification of an expanded number of browser events is possible.
  • the plug-in operates at a level lower than javascript and thus can capture a wide range of browser events.
  • the plug-in is downloaded to the client at an initial stage and is loaded on the client when the customer workstation is downloaded to the customer client 20, as described hereinabove (Figs. 2A,3A,3B ).
  • the plug-in is loaded utilizing an extra frame (plug-in frame) in the workstation (not shown) containing a HTML command to initiate (initialize) the spoofy.
  • the plug-in is downloaded and loaded (initialized) similarly on the agent side, utilizing an extra frame.
  • the plug-in communicates with the Traffic Cop through the plug-in frames in the customer workstation and the plug-in frame at the agent side.
  • the plug-in registers for browser events through its event manager through which browser events are passed - they may or may not be passed back to the browser later.
  • the event manager registers the event, identifies the event and passes it to an event handler which modifies (or does not modify) each event in accordance with its identification.
  • the event handler then passes these events to the Traffic Cop via the plug-in frame to invoke the co-browsing functionality for each event.
  • the plug-in at that side deciphers and executes the browser event in a similar way.
  • Non-limiting examples of the "events" which the plug-in catches are as follows:-
  • Meta tag auto redirect
  • ⁇ META HTTP-EQUIV Refresh
  • top.document.location this.location”> .
  • the plug-in will change the browser event so that the frame does not appear top-most.
  • Java Applets /ActiveX controls that surf the web i.e a navigation e.g from flash.
  • the plug-in catches floating windows (e.g Window.open ⁇ http://www.goto.com/index.html>), automatic filling of text fields in HTML forms (IE).
  • Window.open ⁇ http://www.goto.com/index.html>
  • IE HTML forms
  • Previous (back.forward) browser navigations are also captured and forwarded to the other side.
  • the plug-in by identifying a browser event not previously identifiable by the footer may remove the need, in certain cases, for the use of a rule with the rule filter 400 described hereinabove.

Abstract

There are disclosed systems and methods of coordinating browsing or cobrowsing that employ an intermediate or proxy server between the clients (customer and agent) and the network, such as the Internet. This intermediate server is configured such that during cobrowsing between at least two clients, the network, such as the Internet, is accessed a single time through a single channel or 'pipe' for all clients of this cobrowsing event. Also employed is a filter that receives a data stream with the retrieved target data object accessed from the Internet, and analyzes it for a rule key. If a rule key is not detected, the data stream is passed through the filter to a storage unit of the proxy server for its being provided to all cobrowsing clients. However, should a rule key be detected, the target data object is modified in accordance with a rule corresponding to the rule key. This modified target data object is then passed to the storage unit of the intermediate or proxy server for its being provided to all cobrowsing clients. There is also disclosed a browser plug-in for registering and identifying a browser event and forwarding it utilizing an intermediate server and a data collaboration server.

Description

SYSTEM AND METHOD FOR DIRECTING SHARED DATA
FIELD OF THE INVENTION
The present invention is related applications over Internet Protocol (IP) networks. Particularly, it is directed to methods and systems where client network browsers are synchronized, such that two clients can view the same web page or data object at the same time or "cobrowse", in a coordinated data collaboration session over a network, such as the Internet. More, particularly, the present invention is directed to methods and systems for supporting cosurfing applications where clients link to a server, that serves as an intermediary to the Internet, such that this server provides ail clients accesses to the Internet through a single channel or "pipe".
BACKGROUND OF THE INVENTION
The Internet has emerged as an effective way to speed transactions and provide service to an ever growing number of users, that by early 2000 is expected to exceed 47 million. Along with this growth in users, has come the growth of electronic commerce or "e-commerce", online transactions typically involving the sale of goods and services. Thousands of businesses have entered into e-commerce, realizing that lucrative profits can be gained by reaching this Internet user population with web-based services, advertising, product promotion and sales.
Typical e-commerce applications are based on cobrowsing, where two users or clients browsers are coordinated, and typically synchronized, such that they can both view the same data object, typically a web page within a web document (collectively a "web page") at the same time. This is typically achieved by both users or clients, commonly known as surfers, who are each connected to the Internet as well as a Data Collaboration (DC) Server. The DC Server receives the Uniform Resource Locator (URL) of a user for the web page or data object being viewed by the client customer. This URL is then transferred from the DC Server to the browser of a second user, typically the client agent, who then obtains the data object, e.g., web page, corresponding to the URL from the Internet or other suitable network. This conventional form of cobrowsing has several drawbacks when applied to e-commerce. Initially, since both the customer and agent must access the Internet, through their own separate channels or "pipes", an order could be made twice, once on the customer side and once on the agent side. This is especially true with dynamic web pages, that are separately generated for each Hypertext Transfer Protocol (HTTP) request. Accordingly, two requests are generated to the Internet, one from the customer and one from the agent, resulting from two postings of the HTTP request to the web server. This results in duplicate orders being made, when only one was intended. Additionally, an organization wishing to provide e-commerce services with cobrowsing must purchase a complete cobrowsing application, and install it on their server. This is due to the fact that cobrowsing requires a signaling mechanism from the browser of a client to the DC server, to enable a web page being viewed by a client to be simultaneously viewed by an agent. This signaling mechanism is typically in a footer to the web page, that signals the DC server by passing through a signaling application in the browser, commonly referred to as a "traffic cop". This footer is typically code within Hypertext Markup Language (HTML), such as an HTML formatted file that an organization added to its web page on its server. The traffic cop is, for example, a Java applet that holds a signaling interface to the DC server and monitors footers for events.
The customer will download the requisite software, code, etc., from this organization's, company's or the like (hereafter "organization) server, in order to perform transactions requiring cobrowsing. These software packages can be expensive, to a price point where an organization may find it unprofitable to facilitate e-commerce in this manner or this may be an entry barrier for e- commerce. Additionally, a footer installed on a web page interferes with regular browsing, as it searches for a "traffic cop" application, that is only present in cobrowsing and not present during regular browsing.
Another drawback to these conventional cobrowsing systems is that all of the frames, typically four, the web page itself, the footer, the cobrowsing function (for example, Surf & Call™ from VocalTec, Ltd. Herzlia, Israel) and a "traffic cop", that form the cobrowsing application for cobrowsing the data object, must be from the same domain. This allows the URL of the web page to be passed to the DC server for cobrowsing that web page.
Specifically, the footer must be recognizable to the traffic cop, as being an event of the same domain, if the URL of the web page is to be passed to the DC Server. Otherwise, the URL for the web page would be stopped by the traffic cop and not passed to the DC Server. Thus, should a linked web page of one domain be in the same series of frames with a traffic cop of a different domain, this web page can not be cobrowsed as the traffic cop will not pass its URL to the DC server. Rather, the sender will receive an error message that this operation is not possible. Likewise, if a web page from a different domain to that of the customer's (or client's) suddenly appears in the frames that have been customized to have the same number of domains, an error message will also appear. This often occurs when a web site or customer, has a link to a different web site, and the web page is taken from a different domain when the link is selected.
SUMMARY OF THE INVENTION
The present invention improves on the contemporary art by providing systems and methods for coordinating browsing or cobrowsing that employ an intermediate or proxy server between the clients (customer and agent) and the
-network, such as the Internet. This intermediate server is configured such that during a cobrowsing event between at least two clients, the network, such as the
Internet, is accessed a single time through a single. channel or "pipe" for all clients of this cobrowsing event. Accordingly, once one cobrowsing client requests a particular target data object, typically a web page, only one HTTP request is generated, for example by a HTTP "post" command. From this single request and subsequent single retrieval of the web page through the single channel or "pipe", all clients will receive this target web page. In an e-commerce application, only one order would be generated, as the network, such as the Internet, would only have been accessed once, through a single channel or "pipe" for all cobrowsing clients. Additionally, this single channel or "pipe" network access results in faster transmissions of data objects, typically web pages to the clients, when compared to all clients accessing the same web page, each through their own separate channels. Additionally, in an e-commerce application, only one order would be generated, as a result of this single time, single channel access to the desired web page. Moreover, the intermediate or proxy server of the present invention eliminates the need for each organization to have its own cobrowsing application in or associated with its server, as instead, the organization need only have a link on their web page to the intermediate or proxy server. This is because the intermediate server is configured to pass a cobrowsing functionality to the recipient client in addition to providing a single channel or "pipe" to the Internet for all clients of a cobrowsing session.
One embodiment of the present invention is directed to a system for facilitating coordinated browsing of a data object or objects, typically a web page or web pages, from a web application server, between at least two clients. This embodiment comprises, a first utility for opening a channel to at least one web application server on a network, typically the Internet, and retrieving at least one target data object from this at least one web application server through the opened channel in accordance with a request for this data object from a first client. There is a second utility for providing the at least one target data object retrieved from the at least one application server to a storage medium. There is a third utility for transferring this at least one data object from the storage medium to the first client, who requested this target data object (otherwise known as the requesting client). There is also a fourth utility for transferring the at least one data object from the storage medium to a second client, in response to a corresponding request from the second client for this data object. This system can also include a fifth utility for changing the domain of the retrieved at least one target data object data to the domain corresponding to the first utility, and placing a command onto the retrieved target data object to access the first utility, when a second target data object is requested by any of the clients. Additionally, the system can be such that the first utility is responsive to a link on a web page, when this link is activated by at least one of the clients. Another embodiment of the present invention is directed to a system for facilitating coordinated browsing of data objects, typically web pages, from a web application server, between at least two clients. This system comprises a server for positioning intermediate the at least two clients and a network, typically the Internet. The server comprises a storage medium and a processor. The processor is programmed to: open a channel to at least one web application server on the network, and retrieve at least one target data object from this at least one web application server through the opened channel in accordance with a request for this data object from a first client; provide at least one target data object retrieved from the at least one application server to a storage medium; transfer this at least one data object from the storage medium to the first client; and transfer the at least one data object from the storage medium to a second client, in response to a corresponding request for the data object from the second client. The processor is additionally programmed to change the domain of the retrieved at least one target data object to the domain corresponding to that of the server; and place a command onto the retrieved target data object to access the server, when a second target data object is requested by any of the clients. The system may also include a web page having a link to the server, and also included may be a data collaboration server configured for holding and synchronizing cobrowsing events between the clients.
Another embodiment of the invention is directed to a method for coordinated browsing of data objects, typically web pages, from a web application server, between at least two clients. This method comprises, opening a channel to at least one web application server on a network, typically the Internet, and retrieving at least one target data object, typically a web page, from the at least one web application server through the opened channel in accordance with a request for this data object from a first client. This at least one target data object retrieved from the at least one application server is provided to a storage medium. The at least one data object is transferred from the storage medium to the first client, and this at least one data object is also transferred from said storage medium to a second client, in response to a corresponding request for this data object from the second client. The method may also include changing the domain of the retrieved at least one target data object to the domain corresponding to that of a network accessing component, such as a server, intermediate the clients and the network, for accessing the at least one web application server; and placing a command onto the retrieved target data object to access the intermediate server, when a second target data object is requested by any of the clients. The method may also include accessing this intermediate server by a client activating a link on a web page, this link for directing the client browser to this intermediate server.
Another embodiment of the invention is directed to a method for facilitating coordinated browsing of data objects, typically web pages, from a web application server on a network, typically the Internet, between at least two clients. The method comprises positioning a server intermediate the at least two clients and the network, opening a channel to the at least one web application server on the network, and retrieving at least one target data object (e.g., a web page) from the at least one web application server through the opened channel in accordance with a request for the data object from a first client. The at least one target data object retrieved from the at least one application server is then provided to a storage medium. The stored data object is then transferred from the storage medium to the first client and from the storage medium to the second client, this transfer to the second client in response to a corresponding request for the data object from this second client. This method may additionally comprise providing a web page having a link to the server, with a client activating this link, as well as providing a data collaboration server for holding and synchronizing cobrowsing, typically in each cobrowsing event, between the clients.
Another embodiment of the present invention is directed to a method for facilitating coordinated browsing of data objects, typically web pages, from a web application server on a network, typically the Internet, between at least two clients, from the client side. This method comprises a first client transmitting a first request for a target data object to a server intermediate the at least two clients and the network, for this intermediate server to retrieve the at least one target data object from a web application server on the network and this first client transmitting a second request to a second client to access this intermediate server, for retrieving the at least one target data object in accordance with the first request.
BRIEF DESCRIPTION OF THE DRAWINGS
Attention is now directed to the attached drawings, wherein like reference numerals or characters indicate corresponding or like components. In the drawings:
Fig. 1 is a diagram of an exemplary set up employing an embodiment of the present invention;
Figs. 2a and 2b are a flow diagram of a process in accordance with an embodiment of the present invention for the initial cobrowsing event;
Fig. 3a is a schematic diagram of frames as assembled into a web document in accordance with an embodiment of the present invention; Fig. 3b is a screen shot of a web document in accordance with an embodiment of the present invention;
Fig. 4 is a diagram of the exemplary set-up of Fig. 1 in a subsequent cobrowsing event;
Fig. 5 is a flow diagram of a process in accordance with an embodiment of the present invention for subsequent cobrowsing events;
Fig. 6 is a diagram of the an alternate embodiment of the intermediate or proxy server in a system in accordance with the present invention; and;
Fig. 7 is diagram detailing the operation of the rule filter of Fig. 6.
DETAILED DESCRIPTION OF THE DRAWINGS
Fig. 1 shows an exemplary set up employing an embodiment of the present invention. Here, for example purposes, are shown two clients 20, 22, a customer client or customer 20 who seeks to cobrowse with an agent client or agent 22. Both the customer 20 and agent 22 clients are configured for connecting to a Data Collaboration (DC) Server 26 and an Intermediate or proxy server 30, respectively. This Intermediate or proxy server 30, typically communicates with a network, such as a local area network (LAN) or a wide area network (WAN), typically the Internet 34. Various web servers 36, 37, 38 are connected to the Internet 34. These servers 36-38 are exemplary of the endless number of servers that are connected to the Internet 34. From the customer side, the customer 20 has a multimedia workstation, such as a multimedia PC 20a (e.g., with a Pentium® CPU from Intel Corporation, Santa Clara, California 95052) with voice and data capabilities. In this way, a cobrowsing application with voice and data capabilities may be used, such as any of the Surf & Call™ cobrowsing applications available from VocalTec, Herzlia, Israel. The multimedia PC 20a employs an operating system such as Windows® NT® (from Microsoft Corporation, Redmond, Washington 98052) or the like, and is equipped with a suitable modem or other hardware for accessing the DC Server 26, intermediate server 30, and network, such as the wide area network (WAN), here the Internet 34. The PC 20a is also loaded with software that operates as a browser for the Internet. Exemplary browsers suitable for use here including Microsoft® Internet Explorer® (Microsoft Corporation, Redmond, WA) and Netscape® Navigator® and Netscape® Communicator, the later two from Netscape Communications Corporation, Mountain View, California 94043. On the agent side, is typically at least one web enabled agent 22. While one agent is shown and described, this is exemplary only, for any number of agents (one or greater) is permissible in accordance with the present invention. The agent 22 is typically equipped with a multimedia workstation, such as a multimedia PC 22a with voice and data capabilities, and includes browsers, in accordance with those detailed above. The agent 22 can also use regular (POTS) telephone for audio, typically voice.
The DC Server 26 is typically a server with software and or hardware arranged therein for holding and synchronizing cobrowsing sessions between clients, here for example, the customer 20 and the agent 22, described in detail below. It may also be connected to other servers, such as T-servers and the like, that support voice and data communications. The intermediate or proxy server 30 is connected to the Internet 34 in a way that it accesses Internet and retrieves the requested data object, data stream or the like, that is typically a web page (and will be referred to hereinafter as "web page"), through a single connection (channel or "pipe"). This allows for the same web page, as retrieved through the single channel or "pipe", to subsequently be sent to both customer 20 and agent 22. This Intermediate Server 30 typically includes a processor (P) 39 programmed such that in conjunction with software, hardware or both, accesses the Internet and retrieves any requested web page in communication with a storage unit 40 or other similar data storage device or storage medium with addressable memory units (A1-An). The server 30 also includes hardware, software or combinations thereof, that in conjunction with the processor (P) 39, programmed accordingly, assembles web documents for both the customer 20 and agent 22. These web documents include at least the web page and a footer, typically both in frames. One web document is assembled to appear as a customer workstation on the monitor of the client customer 20 (detailed below). This web document can be formed, for example, as the intermediate server 30 takes the retrieved web page and adds a footer to this page, a cobrowsing functionality, a traffic cop or signaling functionality, and optionally, a form sharing page functionality, for example Surf & Chat™ (VocalTec Communications Ltd., Herzlia 46733, Israel). AH of these functionalities may be stored in the storage unit 40 of the intermediate server 30, or can be retrieved from various servers on the Internet 34. All of these functionalities are of the same domain, that of the intermediate server 30, such that the retrieved web page can be cobrowsed by both customer 20 and agent 22, as detailed below.
The cobrowsing functionality, may for example, be any of the Surf & Call® applications, for example Surf & Call® Center™ from VocalTec Communications Ltd., Herzlia 46332, Israel. This Surf & Call® Center™ includes an embedded plug-in for facilitating an Internet Protocol (IP) call between clients, here customer 20 and agent 22 along with a Cosurfer Data Collaboration (DC) Component, such as the VocalTec® Cosurfer DC Component™ (VocalTec Communications, Ltd., Herzlia 46332, Israel), for facilitating data calls to the DC server 26.
The footer is typically code that dynamically replaces the real target location (the URL) with the location (the URL) of the intermediate or proxy server 30. It also invokes a surf command, typically HTTP language, code, etc., for the recipient client (via their respective workstation) to go to the Intermediate or proxy server 30 and ultimately retrieve the real target web page from the Internet, or alternately, from the intermediate or proxy server 30, if the web page has been retrieved by a cobrowsing client prior to this. Turning also to Figs. 2a and 2b, implementation of an initial cobrowsing processor event, in accordance with the present invention, will now be described in an exemplary e-commerce application. Initially, the server operator, here the server of the agent client 38, has placed a link on its web page, to direct the client browser, to the intermediate or proxy server 30, preferably after the requisite client has reached the web page by regular browsing (surfing). The link typically includes a surf command, such as an HTTP command- for the intermediate or proxy server 30 to retrieve the requested (target) web page from the Internet 34. This command also instructs the retrieval of the real (target) web page by the intermediate or proxy server 30 to have an associated identifier, typically a unique identifier (UID), as detailed below. Upon retrieval of the web page, the web page is placed into the storage unit 40 with this unique identifier. Here for example, this web page originates from the server operator's server, labeled 38. Also, for purposes of this example, it will be noted that this server 38 has a URL of http://www.abc.com, such that its domain is "abc". At block 100, the client customer 20, via his workstation 20a, browses the
Internet 34 to the web site corresponding to abc.com, in accordance with arrow 101, such that the web page of address http:www.abc.com, has been retrieved and now appears before him on his workstation 20a monitor. The web page of address abc.com, will include a link to the intermediate or proxy server. This link can appear on the web page as a hypertext block or the like, activated by clicking (pressing) a mouse or the like. For example, this hypertext block may be a text message such as, "DO YOU WANT HELP IN BROWSING?" The client, here the customer 20, now activates the link on this web page, at block 102, and the client customer's browser is routed to the Intermediate or proxy server 30, at block 104. The Intermediate server 30 then opens a connection (channel or "pipe"), such as an HTTP connection, to the real (target) site and requests this URL (i.e., requests the web page corresponding to the URL) from the Internet 34, at block 106. The web page corresponding to this URL is then retrieved, at block 108. A unique identifier (UID), typically a series of numbers unique to this web page retrieval, that follows requests for this web page, is in place when the intermediate or proxy server retrieves the desired (target) web page from the Internet 34. This unique identifier can be generated in the browser, intermediate or proxy server 30 or in any other server or the like along the Internet 34. For purposes of this example, the specific UID for this first cobrowsing event is 33333. The command to retrieve a web page from the intermediate or proxy server 30 also contains a command to attach the UID to this particular event.
The now-retrieved web page, corresponding to this URL www.abc.com is stored in the storage unit 40, with the unique identifier in an addressable memory unit(s). Within this intermediate server 30, at block 110, the retrieved web page will now become part of a web document, that will appear as a customer work station on the workstation 20a of the customer client 20.
The web document assembly occurs as the source web page address, here abc.com, is parsed to a source web document address, contacting the intermediate or proxy server address, here proxy.com. The web page, here, abc.com, is parsed and converted to a frame. Parsing involves embedding the web page's original URL, here abc.com, within an address containing the URL of the domain of the Intermediate or proxy server, here proxy.com. This ensures that the domain is now that of the intermediate or proxy server. The unique identifier (UID) associated with the web page in the storage device 40 is attached to the page during the parsing process. The parsed address, here proxy.com, is placed into an HTTP command, expressed as, http://vv w.proxy?VESCC_LOCATION=http://wvvw.abc.com&VESCC_UID=33333, for example. This command indicates connecting to the URL, abc.com, through the intermediate or proxy server 30 (the domain of the intermediate or proxy server 30 is "proxy") and a unique identifier, typically digits, here "33333". This unique identifier is specific to the original client cobrowsing request for the web page, here the URL abc.com. The above listed HTTP command is a surf command for a footer. This footer is added as a frame to the web page, as part of the web document being assembled.
Functionalities (also referred to as applications herein) in frames, such as a cobrowsing application, traffic cop and form sharing application frames are added to, or alternately joined with, the web page and footer frames, resulting in the assembled web document. Fig. 3a schematically shows the assembled web document 200, including frames for the web page 201, footer 202, cobrowsing application 203, traffic cop 204, and optionally, a form sharing application 205. This assembled web document 200 is sent to the client, here the customer 20, at block 112. It appears on the monitor of the client workstation, as a customer workstation 200', shown in Fig. 3b.
Continuing with Fig. 3b, the customer workstation 200' includes the web page frame 201', a footer frame (not shown), a cobrowsing application frame 203', for example any of the cobrowsing applications from VocalTec Communications, Herzlia, Israel, for example, the data collaboration (DC) component, that is part of the VocalTec® Surf & Call® Center™, a traffic cop frame (not shown), and optionally, a form sharing page frame (not shown). All of the frames in the assembled web document 200 and resultant customer work station 200', are of the same domain, here "proxy", the domain of the intermediate or proxy server 30. With respect to the cobrowsing application frame, it can for example, work simultaneously with the Surf & Call® embedded plug-in, as represented by the Surf & Call® icon 203", should a Surf & Call™ application be employed. Thus, the user, here the requisite client, invokes the DC component together with the Surf & Call® plug-in by pressing a single button (clicking on the Surf & Call® icon 203").
The customer 20 can now activate the cobrowsing application at block 114, either manually, by clicking on the cobrowsing application frame 203', here, the Surf & Call icon 203", as detailed above, or the cobrowsing application will activate automatically (if the client customer 20 workstation is programmed accordingly, or if the requisite software has been downloaded). The client customer 20 now waits for synchronization of his browser with the browser of the agent, at block 116, to enable the DC server 26 to connect the intended cobrowsing clients. If there is not synchronization between clients (customer and agent), at block 117, the wait continues until there is synchronization. Synchronization may be manual or automatic.
If there is synchronization, at block 118, the URL of the web page to be cobrowsed and information in the footer (in the footer frame) (e.g., the command to go to the requested web page via the intermediate or proxy server 30 and the unique identifier) is sent to the DC server 26, from the client (here, the customer client 20), at block 120. Specifically, since all frames are of the same domain, here, proxy.com, for the intermediate or proxy server 30, the footer catches the event and the traffic cop functionality allows passage of the footer information to be sent to the DC server 26.
The DC server 26 then forwards this footer information to the agent workstation 22a, at block 122. Once this information is received by the agent workstation 22a, at block 124, the agent workstation 22a then sends a request (as per the HTTP command) to the intermediate server 30 for the original web page, http://www.abc.com, at block 126. Once the intermediate server 30 receives this request, the unique identifiers are matched at block 128. Upon matching, the stored web page is retrieved from the requisite memory unit of the storage unit 40. A web document of at least a web page and footer are then sent to the agent workstation at block 130 and received there at block 132. The cobrowsing event is now in progress, at block 134, with the customer 20 and agent 22 in voice and data communication.
Fig. 4 details a diagram of the client 20 and agent 22 in an exemplary subsequent cobrowsing event. This drawing figure is similar to Fig. 1 (detailed above), and will have the same components except where indicated. Here, at the start of this subsequent cobrowsing event, both the client 20 and agent 22 have received the same web page and their browsers are coordinated and synchronized, in accordance with the initial cobrowsing event detailed above. Specifically, both client and agent workstations have received web documents with web pages 290 with footers 291 (in frames) from the intermediate or proxy server 30 from the preceding cobrowsing event. Turning also to Fig. 5, this subsequent cobrowsing event is also shown in a flow diagram. For example, block 300 could be the cobrowsing detailed above (block 134 of Fig. 2b), from where this subsequent cobrowsing session begins. Alternately, this subsequent cobrowsing event can begin from any other cobrowsing event, where clients are cobrowsing. Continuing with the exemplary operation detailed above, to start this subsequent cobrowsing event, a cobrowsing client, customer or agent requests a different web page, than that of the first request, at block 302. Here for, example, the customer (although it could also be the agent), makes a surf command to its browser by requesting a different or new web page, www.xyz.com, such as by clicking (a mouse or the like) on a new link.
As a result of the footer (footer frame) on the web document, the mouse click is caught and this surf command is directed to the Intermediate or proxy server 30, at block 304. This request is assigned its own unique identifier (UID), here, for example 34343 (for this subsequent or new cobrowsing event), different from the unique identifier (33333) for the preceding cobrowsing session detailed above. The command replaces the original link with http://www.xyz.com, and is expressed by: http://vwv.proxy?VESCC_LOCATION=http://w w.xyz.com&VESCC_UID=34343, similar to the command detailed above. Contemporaneous in time with the event of block 302, and typically simultaneous therewith, the surf command is sent to the other client, here the agent workstation 22a, through the DC server 26, with the same unique identifier, here 34343, at block 310. Upon receipt of the command, at block 312, the agent workstation, by virtue of the footer serving as the cobrowsing facilitator (facilitating functionality), sends the URL of the new web page and the unique identifier to the intermediate or proxy server 30, at block 314. The footer of the agent web document has been changed to include the received surf command (this surf command as detailed above).
The intermediate or proxy server 30 takes this first received request, at block 324, from the client, here, customer or agent, to the network, e.g., the Internet, by opening a channel or "pipe" thereto (as detailed above), and retrieving the new web page (as detailed above) at block 326. Once in the intermediate server 30, the new web page is placed into the storage unit 40 with addressing therein in accordance with the new unique identifier at block 328. The web page is sent to the workstation of the client whose request was received first, at block 330. Here, the customer would typically receive the web page first (typically as part of a web document detailed above), as his request typically reaches the intermediate or proxy server 30 first, since he initiated the subsequent cobrowsing to www.xyz.com. (Alternately, should the agent's request be received first at the intermediate or proxy server 30, the step above, as well as the steps below would be reversed for customer and agent).
When the second request, from the other client, arrives at the intermediate or proxy server 30, at block 332, the unique identifier in the request is used to find the stored web page of the same unique identifier, at block 334. Once unique identifiers are matched, the web page is sent from the storage unit 40 to the second requesting client's workstation, at block 336. This second request here, is typically from the agent 22, as the customer 20 request reached the intermediate or proxy server 30 first in this example, as detailed above. Cobrowsing continues with the new web page being cobrowsed by the clients, at block 338, and can continue in this manner for as long as desired. Turning now to Figs. 6 and 7, there is detailed another embodiment of the present invention. This embodiment is directed to web pages, retrieved from various servers into the intermediate or proxy server 30 (detailed above), that are incompatible with the code lines or code portions or segments (collectively referred to herein as "code") for web pages in the intermediate or proxy server 30. For example, the retrieved web page or target data object, may be incompatible with the frame arrangement of the intermediate or proxy server 30, or its embedded links are incompatible with the requirement of catching an event (mouse click or keyboard) by the footer in order to access (surf to) the intermediate or proxy server 30, both occurrences described above. To account for this incompatibility, the intermediate or proxy server 30, as detailed above, has been modified with a rule filter (RF) 400. This modified intermediate or proxy server 30' is similar in all aspects to the intermediate or proxy server 30 detailed above, except with respect to the rule filter 400, and it functions, for example, in conjunction with a system, including components, that has been detailed above and shown in Figs. 1-5.
The rule filter 400 is shown as internal to the intermediate or proxy server 30' of Fig. 6, but could also be an external or peripheral component thereto. This rule filter 400 can be software, hardware or combinations thereof. It is used, for example, to change the code on the retrieved web page so that they function correctly in the environment of the intermediate or proxy server 30', or so that footers perform their intended functions. The rule filter 400 includes a rule-based translator 402 that includes a reader 404, storage media 406 and a rule processor 408. The reader 404 is typically a programmable device, such as a chip or card, programmed for recognizing and reading a rule key from the incoming data stream (indicated as Stream A). This stream typically includes the retrieved web page and the rule key is typically the URL of the web page indicating that a rule is associated with the particular web page.
The storage media 406 is any conventional data storage unit and typically includes files 410, where single or plural rules are stored. These rules are typically related to web pages, for example www.def.com and www.pqr.com, and are stored in files 410 accordingly. These individual rules are for example, instructions to replace incompatible code on the retrieved web page with alternative specified code. This alternate code is created based on the deficiencies of the original web page of the provider (provider web page), this provider utilizing the services and or functions associated with this intermediate or proxy server 30'. (The original or provider web page becomes the retrieved web page or target data object once accessed by the intermediate or proxy server 30', as detailed above). In creating the desired rule, code lines or code portions or segments from the original or provider web page(s) are obtained, and a corresponding rule or rules is created (and provided to the rule filter 400, typically programmed therein) to accommodate the incompatibility caused by a code lines or code portions or segments associated with the retrieved web page. Upon invoking a rule (detailed below), the retrieved web page is modified, for example, by augmenting, adding, changing, removing, deleting or replacing or any combination thereof, one or more code lines, code portions or segments, to compensate for the incompatible code lines code portions or segments, resulting in a compatible web page. This now compatible web page is suitable for web document assembly in the intermediate or proxy server 30' in accordance with the process detailed for the intermediate or proxy server 30, as shown in Figs. 1- 5 and described above. These rules, are typically, for example, from three fields: a) a command, such as, add, replace or remove; b) a source-a regular expression or string on the web page to be, for example, replaced, added or removed; and 3) a destination-typically a code to be added to replace the source.
The rule processor 408 is typically a suitable hardware device, software application or combination thereof, configured and/or programmed to change the retrieved web page in accordance with the rule. Alternatively, for example, the rule modifies and/or changes the retrieved web page so that the required functionality can function in the new environment of the intermediate or proxy server 30', as detailed above (with respect to the intermediate or proxy server 30). In operation, when a web page is retrieved, it enters the rule filter 400 in a data stream (Stream A). The reader 404 attempts to find a rule key, for example, the URL of a web page, from the data stream. If a rule key is not found, the web page is passed to the storage unit 40 of the proxy server 30' (as represented by the broken line arrow of Fig. 7), where it is assembled into a web document as detailed above (for the intermediate or proxy server 30).
If a rule key is found on the retrieved web page (the solid line arrow of Fig. 7 is followed), the corresponding rule or rules file is located in the storage media 406. Once located, the rule processor 408 modifies the retrieved web page in accordance with the requisite rule or rules, so as to be compatible with the pre-configured code (lines, portions and/or segments) of the intermediate or proxy server. The modified web page is then placed into a data stream and sent to the storage unit 40 of the intermediate or proxy server 30', for placement into the web document as configured in the intermediate or proxy server 30', as detailed above (for intermediate or proxy server 30).
For example,, some web pages contain an instruction to place that web page as the top-most frame in a web browser. This would obscure the multiple frames (including the user toolbar/workstation) that the intermediate or proxy server constructs, as described above. Accordingly, when utilizing a rule key, for example, the URL of the web page, a rule is invoked which replaces the command to position the web page topmost (source) with a command that it occupy a regular frame within the user workstation constructed by the intermediate or proxy server functionality. The rule (In HTML) is, for example, as follows:
Command: Replace Source: <BASE href = top> Destination: <BASE href =_self>
Alternatively, for example, if the command is "delete" the destination part of the rule may be left blank.
Another alternate may be, for example, when a functionality in a web page does not require an event (mouse click or keyboard), not affording the footer to catch the event and cause the link or functionality to execute via the intermediate or proxy server 30'. The code responsible for the functionality is then replaced with code containing the functionality together with an added command to access (surf to) the intermediate or proxy server 30' to mimic the functionality which the footer would have added. This is achieved with a suitable rule. For example, a Meta tag (auto redirect) occurs without an event (mouse click or keyboard event), so it must be replaced with an automatic redirect command incorporating the accessing (surfing to) the intermediate or proxy server, for example:
Command: Replace Source: <META HTTP-EQUIV=Refresh CONTENT= "10; URL=http://w w.goto.com/"> Destination: <META HTTP-EQUIV=Refresh CONTENT* "10" URL= http://www.proxy.com/proxy?VESCC_UID=178345021034560&VESCC_LOCATiON= http://www.goto.com>
It should be noted that there are many other instances in which, for example, the code is modified, by utilizing a rule filter, in accordance with that described above.
In a preferred embodiment of the present invention the footer described hereinabove is replaced with a browser plug-in, preferably an active-x™ . This contains code not embedded in a web page but which is compiled. The plug-in performs all the functions of the footer by identifying HTML document events such as mouse and keyboard clicks. The plug-in may additionally identify any browser event including non-mouse/keyboard events. Thus, co-browsing based on the identification of an expanded number of browser events is possible. The plug-in operates at a level lower than javascript and thus can capture a wide range of browser events.
The plug-in is downloaded to the client at an initial stage and is loaded on the client when the customer workstation is downloaded to the customer client 20, as described hereinabove (Figs. 2A,3A,3B ). The plug-in is loaded utilizing an extra frame (plug-in frame) in the workstation (not shown) containing a HTML command to initiate (initialize) the spoofy. The plug-in is downloaded and loaded (initialized) similarly on the agent side, utilizing an extra frame. The plug-in communicates with the Traffic Cop through the plug-in frames in the customer workstation and the plug-in frame at the agent side.
The plug-in registers for browser events through its event manager through which browser events are passed - they may or may not be passed back to the browser later. The event manager registers the event, identifies the event and passes it to an event handler which modifies (or does not modify) each event in accordance with its identification. The event handler then passes these events to the Traffic Cop via the plug-in frame to invoke the co-browsing functionality for each event. When the event is passed to the opposite side via the DC server, as described hereinabove, the plug-in at that side deciphers and executes the browser event in a similar way. Non-limiting examples of the "events" which the plug-in catches are as follows:-
Javascript links, for example, document location=http://www.goto.com/index.html. Meta tag (auto redirect), for example. <META HTTP-EQUIV=Refresh
CONTENT= "10: URL=http://www.goto.com/">.
Sites that cannot live in a frameset (and redirect themselves to the topmost frame)<Base HREF=_top> <BODY onload=
"top.document.location=this.location"> . In this case the plug-in will change the browser event so that the frame does not appear top-most.
Java Applets /ActiveX controls that surf the web i.e a navigation e.g from flash.
In addition, the plug-in catches floating windows (e.g Window.open <http://www.goto.com/index.html>), automatic filling of text fields in HTML forms (IE).
Next, Previous (back.forward) browser navigations are also captured and forwarded to the other side.
It should be noted that the plug-in, by identifying a browser event not previously identifiable by the footer may remove the need, in certain cases, for the use of a rule with the rule filter 400 described hereinabove.
The methods and apparatus disclosed herein have been described with exemplary reference to specific hardware and/or software. The methods have been described as exemplary, whereby specific steps and their order can be omitted and/or changed by persons of ordinary skill in the art to reduce embodiments of the present invention to practice without undue experimentation. The methods and apparatus have been described in a manner sufficient to enable persons of ordinary skill in the art to readily adapt other commercially available hardware and software as may be needed to reduce any of the embodiments of the present invention to practice without undue experimentation and using conventional techniques.
While preferred embodiments of the present invention have been described, so as to enable one of skill in the art to practice the present invention, the preceding description is intended to be exemplary only. It should not be used to limit the scope of the invention, which should be determined by reference to the following claims.

Claims

What is claimed is:
1. A system for facilitating coordinated browsing of data objects from a web application server, between at least two clients, comprising: a first utility for opening a channel to at least one web application server on a network, and retrieving at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; a second utility for providing said at least one target data object retrieved from said at least one application server to a storage medium; a third utility for transferring said at least one data object from said storage medium to said first client; and a fourth utility for transferring said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
2. The system of claim 1 , additionally comprising: a fifth utility for changing the domain of said retrieved at least one target data object to the domain corresponding to said first utility and placing a command onto said retrieved target data object to access said first utility when a second target data object is requested by any of said clients.
3. The system of claim 1 , wherein said second utility includes providing a unique identifier to said at least one target data object retrieved from said at least one application server to a storage medium.
4. The system of claim 3, wherein said fourth utility initially includes matching a unique identifier of said second request with said unique identifier of said at least one target data object retrieved from said at least one application server in said storage medium.
5. The system of claim 1, wherein said first utility is responsive to a link on a web page when said link is activated by at least one of said clients.
6. A method for coordinated browsing of data objects from a web application server, between at least two clients, comprising: opening a channel to at least one web application server on a network, and retrieving at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; providing at least one target data object retrieved from said at least one application server to a storage medium; transferring said at least one data object from said storage medium to said first client; and transferring said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
7. The method of claim 6, additionally comprising: changing the domain of said retrieved at least one target data object data to the domain corresponding to that of a network accessing component, said network accessing component for accessing said at least one web application server; and placing a command onto said retrieved target data object to access said network accessing component, when a second target data object is requested by any of said clients.
8. The method of claim 7, wherein providing said target data object to said storage medium includes providing a unique identifier to said at least one target data object retrieved from said at least one application server.
9. The method of claim 8, wherein said transferring said at least one data object from said storage medium to a second client, includes matching a unique identifier of said second request with said unique identifier of said at least one target data object retrieved from said at least one application server in said storage medium.
10. The method of claim 6, wherein said accessing said at least one application server on a network includes responding to an activated link on a web page, when said link has been activated by at least one of said clients.
11. A programmable storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform method steps for providing coordination of the browsers of at least two clients for a target data object, said method steps selectively executed during the time when said program of instructions is executed on said machine, comprising: opening a channel to a network in response to a first request for a target data object from a first client; accessing at least one target data object through said channel from at least one web application server on said network in accordance with said first request; transferring said requested at least one target data object to said first client; transferring said at least one target data object to said second client in response to a second request for said at least one target data object from a second client, said second request corresponding to said first request as received from said first client.
12. A system for facilitating coordinated browsing of data objects from a web application server, between at least two clients, comprising: a server for positioning intermediate said at least two clients and a network, said server comprising: a storage medium; and a processor, said processor programmed to: open a channel to at least one web application server on a network, and retrieve at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; provide at least one target data object retrieved from said at least one application server to a storage medium; transfer said at least one data object from said storage medium to said first client; and transfer said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
13. The system of claim 12, wherein said processor is additionally programmed to: change the domain of said retrieved at least one target data object to the domain corresponding to that of said server; and place a command onto said retrieved target data object to access said server, when a second target data object is requested by any of said clients.
14. The system of claim 12, wherein processor is additionally programmed to: provide a unique identifier to said at least one target data object retrieved from said at least one application server.
15. The system of claim 14, wherein said processor is additionally programmed to: match a unique identifier of said second request with said unique identifier of said at least one target data object retrieved from said at least one application server in said storage medium, prior to transferring said at least one retrieved target data object to said second client.
16. The system of claim 12, additionally comprising: a web page having a link to said server.
17. The system of claim 12, additionally comprising a data collaboration server configured for holding and synchronizing cobrowsing between said clients.
18. A method for facilitating coordinated browsing of data objects from a web application server on a network, between at least two clients, comprising: positioning a server intermediate said at least two clients and said network; opening a channel to at least one web application server on a network, and retrieve at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; providing at least one target data object retrieved from said at least one application server to a storage medium; transferring said at least one data object from said storage medium to said first client; and transferring said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
19. The method of claim 18, additionally comprising: changing the domain of said retrieved at least one target data object to the domain corresponding to that of said server; and placing a command onto said retrieved target data object to access said server, when a second target data object is requested by any of said clients.
20. The method of claim 18, wherein said providing at least one target data object to said storage medium includes providing a unique identifier to said at least one target data object retrieved from said at least one application server.
21. The method of claim 20, wherein said transferring said at least one data object from said storage medium to a second client includes matching a unique identifier of said second request with said unique identifier of said at least one target data object retrieved from said at least one application server in said storage medium.
22. The method of claim 18, additionally comprising: providing a web page having a link to said server.
23. The method of claim 22, additionally comprising: activating said link.
24. The method of claim 18, additionally comprising: providing a data collaboration server; and holding and synchronizing cobrowsing between said clients.
25. A method for facilitating coordinated browsing of data objects from a web application server on a network, between at least two clients, comprising: transmitting a first request for a target data object, by a first client, to a server intermediate said at least two clients and said network, for said intermediate server to retrieve said at least one target data object from a web application server on said network; transmitting a second request from said first client to said second client to access said intermediate server for retrieving said at least one target data object in accordance with said first request.
26. A method for coordinated browsing of data objects from a web application server, between at least two clients, comprising: opening a channel to at least one web application server on a network, and retrieving at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; analyzing said at least one target data object for at least one rule key; modifying said at least one target data object if said rule key is detected; providing said at least one target data object to a storage medium; transferring said at least one data object from said storage medium to said first client; and transferring said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
27. The method of claim 26, additionally comprising: changing the domain of said retrieved at least one target data object to the domain corresponding to that of a network accessing component, said network accessing component for accessing said at least one web application server; and placing a command onto said retrieved target data object to access said network accessing component, when a second target data object is requested by any of said clients.
28. The method of claim 27, wherein providing said target data object to said storage medium includes providing a unique identifier to said at least one target data object retrieved from said at least one application server.
29. The method of claim 28, wherein said transferring said at least one data object from said storage medium to a second client, includes matching a unique identifier of said second request with said unique identifier of said at least one target data object retrieved from said at least one application server in said storage medium.
30. The method of claim 26, wherein said accessing said at least one application server on a network includes responding to an activated link on a web page, when said link has been activated by at least one of said clients.
31. The method of claim 26, wherein said modifying said at least one target data object if said rule key is detected includes, accessing a predetermined rule corresponding to said rule key.
32. The method of claim 31, wherein said rule includes at least one command for at least one of replacing or removing at least one parameter associated with said target data object retrieved from said at least one application server.
33. The method of claim 31, wherein said rule includes at least one command for adding at least one parameter to said target data object retrieved from said at least one application server.
34. The method of claim 31, wherein said rule includes at providing a source to said target data object retrieved from said at least one application server.
35. The method of claim 34, wherein said providing a source includes providing for at least one of adding, replacing or removing at least one of a regular expression or string with respect to said target data object retrieved from said at least one application server.
36. The method of claim 31, wherein said rule includes at providing a destination to said target data object retrieved from said at least one application server.
37. The method of claim 36, wherein said providing a destination includes providing for at least one of adding, replacing or removing at least one of a regular expression or string with respect to said target data object retrieved from said at least one application server.
38. A programmable storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform method steps for providing coordination of the browsers of at least two clients for a target data object, said method steps selectively executed during the time when said program of instructions is executed on said machine, comprising: opening a channel to a network in response to a first request for a target data object from a first client; accessing at least one target data object through said channel from at least one web application server on said network in accordance with said first request; analyzing said requested at least one target data object for the existence of a rule key; modifying said target data object in accordance with a rule corresponding to said rule key if said rule key exists; transferring said requested at least one target data object to said first client; transferring said at least one target data object to said second client in response to a second request for said at least one target data object from a second client, said second request corresponding to said first request as received from said first client.
39. A system for facilitating coordinated browsing of data objects from a web application server, between at least two clients, comprising: a server for positioning intermediate said at least two clients and a network, said server comprising: a storage medium; and a processor, said processor programmed to: open a channel to at least one web application server on a network, and retrieve at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; provide at least one target data object retrieved from said at least one application server to a storage medium; analyze said at least one retrieved target data object for a rule key; modify said retrieved target data object in accordance with a predetermined rule corresponding to said rule key, if a rule key exists; transfer said at least one data object from said storage medium to said first client; and transfer said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
40. The system of claim 39, wherein said processor is additionally programmed to: change the domain of said retrieved at least one target data object to the domain corresponding to that of said server; and place a command onto said retrieved target data object to access said server, when a second target data object is requested by any of said clients.
41. The system of claim 39, wherein processor is additionally programmed to: provide a unique identifier to said at least one target data object retrieved from said at least one application server.
42. The system of claim 41, wherein said processor is additionally programmed to: match a unique identifier of said second request with said unique identifier of said at least one target data object retrieved from said at least one application server in said storage medium, prior to transferring said at least one retrieved target data object to said second client.
43. The system of claim 39, additionally comprising: a web page having a link to said server.
44. The system of claim 39, additionally comprising a data collaboration server configured for holding and synchronizing cobrowsing between said clients.
45. The system of claim 39, wherein said step of modifying includes, accessing at least one predetermined rule from a storage media.
46. The system of claim 45, wherein said at least one predetermined rule is selected from the group comprising at least one of: a command, a source or a destination.
47. A Method for coordinated browsing of data objects from a web application server, between at least two clients, comprising: registering a browser event from one of said clients;
identifying said browser event; forwarding said browser event to another of said clients.
48. The method of claim 47 additionally comprising:
receiving said browser event at said another of said clients; and
reproducing said browser event at said another of said clients.
49. The method of claim 47 wherein said identifying said browser event includes modifying said browser event according to said identification.
50. The method of claim 47 wherein said browser event is a navigation event.
51. A system for facilitating coordinated browsing of data objects from a web application server, between at least two clients, comprising: a data collaboration server configured for holding and synchronizing cobrowsing between said clients; a signalling medium configured for forwarding browser events between each of said clients and said data collaboration server; a browser plugin in each of said clients configured for registering browser events and sending them to said signalling mechanism for forwarding by said data collaboration server wherein each of said plugins in said at least two clients is configured to reproduce said browser event.
52. A system for facilitating coordinated browsing of data objects from a web application server, between at least two clients, comprising: a server for positioning intermediate said at least two clients and a network, said server comprising: a storage medium; and a processor, said processor programmed to: open a channel to at least one web application server on a network, and retrieve at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; provide at least one target data object retrieved from said at least one application server to a storage medium; transfer said at least one data object from said storage medium to said first client; and transfer said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
53. The system of claim 52, additionally comprising a data collaboration server configured for holding and synchronizing cobrowsing between said clients.
54. The system of claim 53 additionally comprising a browser plugin in each of said clients configured for recognizing browser events and sending them to a signalling mechanism for forwarding by said data collaboration server wherein each of said plugins in said at least two clients is configured to reproduce said browser event.
55. A method for facilitating coordinated browsing of data objects from a web application server on a network, between at least two clients, comprising: positioning a server intermediate said at least two clients and said network; opening a channel to at least one web application server on a network, and retrieving at least one target data object from said at least one web application server through said channel in accordance with a request for said data object from a first client; providing at least one target data object retrieved from said at least one application server to a storage medium; transferring said at least one data object from said storage medium to said first client; and transferring said at least one data object from said storage medium to a second client, in response to a corresponding request for said data object from said second client.
56. The method of claim 55, additionally comprising: providing a data collaboration server; and holding and synchronizing cobrowsing between said clients.
57. The method of claim 56 wherein said holding and synchronizing cobrowsing between clients includes providing a browser plugin at each browser of said at least two clients said plugin registering browser events and sending them to a signalling mechanism for forwarding wherein each of said plugins in said at least two clients is configured to recognize and reproduce said browser event.
PCT/US2001/026968 2000-09-05 2001-08-30 System and method for facilitating coordinated browsing of data objects WO2002021312A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001286912A AU2001286912A1 (en) 2000-09-05 2001-08-30 System and method for facilitating coordinated browsing of data objects

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US65464700A 2000-09-05 2000-09-05
US09/654,647 2000-09-05
US09/797,420 US20020049812A1 (en) 2000-09-05 2001-03-01 System and method for directing shared data
US09/797,420 2001-03-01
US09/885,860 US20020029245A1 (en) 2000-09-05 2001-06-20 System and method for directing shared data
US09/885,860 2001-06-20

Publications (2)

Publication Number Publication Date
WO2002021312A2 true WO2002021312A2 (en) 2002-03-14
WO2002021312A3 WO2002021312A3 (en) 2003-09-25

Family

ID=27417930

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/026968 WO2002021312A2 (en) 2000-09-05 2001-08-30 System and method for facilitating coordinated browsing of data objects

Country Status (2)

Country Link
AU (1) AU2001286912A1 (en)
WO (1) WO2002021312A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004107100A2 (en) 2003-05-22 2004-12-09 Cisco Technology, Inc. Peer-to-peer dynamic web page sharing
SG108895A1 (en) * 2002-04-10 2005-02-28 Nippon Telegraph & Telephone Server-based computing collaboration allowing multiple clients to share application in server and collaborate on the application
CN105991439A (en) * 2015-02-06 2016-10-05 杭州华三通信技术有限公司 Management method and device of data center server (DC server)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870546A (en) * 1996-02-21 1999-02-09 Infoseek Corporation Method and apparatus for redirection of server external hyper-link reference
EP0992922A2 (en) * 1998-10-02 2000-04-12 International Business Machines Corporation Automatic image data quality adjustment to reduce response time of a Web server
EP1018689A2 (en) * 1999-01-08 2000-07-12 Lucent Technologies Inc. Methods and apparatus for enabling shared web-based interaction in stateful servers

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870546A (en) * 1996-02-21 1999-02-09 Infoseek Corporation Method and apparatus for redirection of server external hyper-link reference
EP0992922A2 (en) * 1998-10-02 2000-04-12 International Business Machines Corporation Automatic image data quality adjustment to reduce response time of a Web server
EP1018689A2 (en) * 1999-01-08 2000-07-12 Lucent Technologies Inc. Methods and apparatus for enabling shared web-based interaction in stateful servers

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CABRI G ET AL: "Supporting cooperative WWW browsing: a proxy-based approach" PROCEEDINGS EUROMICRO WORKSHOP ON PARALLEL AND DISTRIBUTED PROCESSING, 3 February 1999 (1999-02-03), pages 138-145, XP002154337 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG108895A1 (en) * 2002-04-10 2005-02-28 Nippon Telegraph & Telephone Server-based computing collaboration allowing multiple clients to share application in server and collaborate on the application
US7191217B2 (en) 2002-04-10 2007-03-13 Nippon Telegraph And Telephone Corporation Distributed server-based collaborative computing
WO2004107100A2 (en) 2003-05-22 2004-12-09 Cisco Technology, Inc. Peer-to-peer dynamic web page sharing
EP1625512A2 (en) * 2003-05-22 2006-02-15 Cisco Technology, Inc. Peer-to-peer dynamic web page sharing
EP1625512A4 (en) * 2003-05-22 2011-10-19 Cisco Tech Inc Peer-to-peer dynamic web page sharing
CN105991439A (en) * 2015-02-06 2016-10-05 杭州华三通信技术有限公司 Management method and device of data center server (DC server)
CN105991439B (en) * 2015-02-06 2019-05-10 新华三技术有限公司 Manage the method and device of data center server

Also Published As

Publication number Publication date
AU2001286912A1 (en) 2002-03-22
WO2002021312A3 (en) 2003-09-25

Similar Documents

Publication Publication Date Title
US20020049812A1 (en) System and method for directing shared data
US6278993B1 (en) Method and apparatus for extending an on-line internet search beyond pre-referenced sources and returning data over a data-packet-network (DPN) using private search engines as proxy-engines
US6718390B1 (en) Selectively forced redirection of network traffic
CN101753606B (en) Method for realizing WEB reverse proxy
US20020029245A1 (en) System and method for directing shared data
US6073241A (en) Apparatus and method for tracking world wide web browser requests across distinct domains using persistent client-side state
US6507867B1 (en) Constructing, downloading, and accessing page bundles on a portable client having intermittent network connectivity
US7596533B2 (en) Personalized multi-service computer environment
US7085997B1 (en) Network-based bookmark management and web-summary system
US6108655A (en) Method and apparatus for transmitting images and other objects over a computer network system
US6907423B2 (en) Search engine interface and method of controlling client searches
US7058698B2 (en) Client aware extensible markup language content retrieval and integration in a wireless portal system
US6199077B1 (en) Server-side web summary generation and presentation
FI105249B (en) Procedure and arrangements for connecting information to network resources
US8250462B2 (en) Method and system of fulfilling requests for information from a network client
CA2548137C (en) Method of redirecting client requests to web services
US20020116494A1 (en) Web page link-tracking system
WO1998049633A1 (en) Server-based host monitor
WO2002019088A1 (en) System and method of sending chunks of data over wireless devices
US6947979B1 (en) Controlling use of a network resource
US20030233400A1 (en) Enhancing of web pages with new functionality for web-based services
US6968356B1 (en) Method and apparatus for transferring data between a client and a host across a firewall
WO2002021312A2 (en) System and method for facilitating coordinated browsing of data objects
US20020156708A1 (en) Personalized internet server
US8806326B1 (en) User preference based content linking

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP