BACKGROUND OF THE INVENTION Network data transfer rates vary widely from user to user. Therefore, in multiple-user network applications such as co-webbing, joint users are often denied a mutual experience due to these differing data transfer rates. Data transfer rate differences can occur due to a variety of conditions including differing hardware, server connections, or Internet traffic. Differing data transfer rates arnong users of a multiple-user network application can impair the desired co- webbing experience. example, if a first user has a faster data transfer rate than other users of the multiple-user application, the first user may be continually viewing different Web pages than the other users of the network. Specifically, differing data transfer rates cause problems when the first user is viewing a Web page that is a frame page having subframes within the frame page. If the other users do not receive the origin. ll frame page from the server prior to receiving the subframe addresses from the first user, the other users will be incorrectly viewing the subframes as independent Web pages.

In addition, networks that transmit both voice and data information present additional problems for multiple-user network applications. Voice information is extremely degradation- sensitive, and occupies a greater amount of bandwidth than most typical data transfers.

However, when a user requests a data transfer over a network in which the user is also conducting a voice communication, conventional systems do not differentiate between these two types of information transfers. In accordance with co-pending application serial no system and method are disclosed for ensuring that the correct priority is given a data transfer responsive to its type. However, prioritization of data transfers responsive to their type complicates the issue of providing simultaneous display of data over a network because prioritization may cause additional disparity in the data transfer rates of multiple users of the network. Thus, a system is needed for providing simultaneous display of data to multiple users of a network application, and a system is needed to provide simultaneous display of data over a network in an environment where the type of data to be transferred determines the rate at which the data is transferred.

SUMMARY OF INVENTION In accordance with the present invention, a system, method, and apparatus are provided that allow simultaneous display of data retrieved from remote sites to multiple users of a network in an environment where the data transfer rules of users differ due to voice information prioritization, network traffic, hardware differences, or other causes. More specifically, a selection of data for transfer to a first user of a network is received The selection of data preferably specifies a remote address from which to transfer the data. Next, a designation of at least one other user to receive a simultaneous display of the selected data is received. Then, the selection of data is sent to the at least one other user to allow the computer of the at least one other user to initiate the transfer of data from the remote site. Finally, the transfer of data between the first user and the at least one other user is synchronized to provide simultaneous display.

In one embodiment, voice data is given priority in the transfer of information over the network, thus ensuring the highest quality voice signal possible over the user's connection.

However, simultaneous display of data between the user and the at least one other user of the network is still preserved in accordance with the present invention. In a further embodiment, the present invention synchronizes the transfer of data by determining whether the initial selection of data is a request for transfer of a frame. Responsive to the selection being for a frame, the present invention does not send subframe URLs to the at least one other user until receiving a signal from the at least one other user that the initial frame has been received. Thus, by requiring this wait for acknowledgment, the present invention ensures that varying connection speeds will have minimal effect of the simultaneous display of data.

BRIEF DESCRfPTION OF THE DRAWINGS Figure I a is an illustration of a user interface for an on-screen internet telephony device with a data display area in accordance with the present invention.

Figure I b is an illustration of a user interface for co-webbing in accordance with the present invention.

Figure 2 is a block diagram of an integrated voice and data network system and the associated software architecture in accordance with the present invention.

Figure 3 is a flow chart illustrating a preferred method of providing simultaneous display of selected data to multiple users of a network.

Figure 4 is a flowchart illustrating a preferred method of synchronizing the transfer of daa a between users of the network.

DETAILED DESCR1PTION OF PREFERRED EMBODIMENTS Referring to Figure I a, there is shown an illustration of a user interface 100 of an on- screen internet telephony device with a display screen in accordance with the present invention.

The internet telephony device is preferably MediaRing Talk by Mediacom Technologies PTE.

The internet telephony device executes on a client or user computer and is coupled over a network, preferably an integrated voice and data network, to a server or a computer system or a network. The user interface 100 comprises three, simultaneously displayed areas: a first area 102, for displaying information such as the phone number or name of the recipient caller and the duration of the call; a second area 104, for displaying the control buttons for operating the internet telephony device, and a third area 106, here labeled"Advertising Window", for displaying Web pages, advertisements, or messages to the user of the internet telephony device.

A button 110 for initiating a co-webbing session is preferably located in an action toolbar. The organization and placement of the areas in the user interface 100 of Figure 1 is merely illustrative and not limited by the present invention, and variations in the placement, size, and shape of the areas would be readily apparent to those of skill in the art of user interface design. Thus, the internet telephony device uses botti voice data and non-voice data, such as Web pages without decreasing the quality of the voice application.

Referring to Figure. lb, a co-webbing window 116 is shown. The co-webbing window 116 is preferably launched by selection of the co-webbing button 110 in the main user interface 100. In a preferred embodiment, launching the co-webbing window 116 in a first user's computer automatically lunches the co-webbing window 116 on the computers of the users to whom the first user is connected. This ensures that the other users will be able to view the Web page selected by the first user. The co-webbing window 116 displays URLs entered by all of the users of the co-webbing session. The co-webbing window 116 also provides an entry bar 120 within which a user can enter a URL to be displayed. The user initiates the transfer of data from the remote site specified by the URL by selecting the SEND button 124. The user can also select a URL from the list of URLs displayed. Other methods of selecting a URL site known to those of ordinary skill in the art are considered to be within the scope of the prosent invention. The Web page to be displayed is preferably displayed through activation of a default web browser located on the user's computer. Alternatively, the Web page is displayed in the data display window 106.

Referring now to Figure 2, there is shown a block diagram of an integrated voice and data network system 200 and the associated software architecture in accordance with the present invention. In accordance with such system 200, there is provided at least two client computers 202 communicatively coupled by a network 204, such as the internet, to one or more computer servers 206. Although two client computers 202 are shown, there is no physical limit to the number of client computers 202 that may be connected to the network 204 at one time. The client computer 202 may be used for executing non-voice applications 208, such as web pages, advertisements, software programs, and voice applications 210, such as MediaRing's internet telephony device, MediaTalk. The client computer 202 further comprises a WinSock/Winlnet component 212, a TCP/IPsubsystem 214, an intercept layer 218, and a bandwidth management control module 220. The client computer 202 also includes either a network hardware and driver module 224 or a modem and PPP Modem driver 226 or both. The TCP/IP subsystem 214 comprises a receiving buffer 216 which is preferably a first in first out (FIFO) buffer. The receiving buffer 216 buffers incoming and outgoing data and de-couples a voice application 210 from the flow of data received over the internet 204. One embodiment of the operation of receiving buffer 216 is described in co-pending application S/N_/,__. The network hardware and driver module 224 provides an Ethernet connection to server 206. The modem and PPP driver 226 provides a telephone connection to server 206. In a preferred embodiment the client computer 202 may be implemented on an Intel-based computer operating under Microsoft Windows 3.1, Windows95, or WindowsNT operating system, or a SPARC-based computer operating under UNIX, or any other equivalent devices.

In accordance with the present invention, the client computer 202 executes a voice application 210, such as an internet telephony device, in memory. The voice application 210 is comprised of a number of executable code portions and data files. These include code for creating and supporting the user interface. The voice application 210 may be provided to the client computer 202 on a computer readable media, such as a CD-ROM, diskette, 8mm tape, or by electronic communication over the network 204 from one of the servers 206 or other distributors of software, for installation and execution thereon. The internet 204 may be any type of network which delivers data to destinations.

The server 206 comprises a TCP/IP subsystem 230, a server software 232, a server script 234, and a local storage device 236 for storing data files. The TCP/IP subsystem 230 receives and sends data, also called packets, according to the TCP/IP protocol. The server software 232 is an application program which is executed on the server 206. The server software 232 is communicatively coupled to the TCP/IP subsystem 230 to receive requests or data packets over the internet 204 and responds by sending the requested data, such as a web page, to the requesting client 202.

A request for data, such as a web page, starts within client 202 with a voice application 210 or non-voice application 208. The application, whether it is a browser like Netscape's Netscape Navigator or a voice-application 210, like MediaRing's MediaTalk, sends a request to the server uniform resource locator (URL). This request, which comprises a data packet, is sent via the Winsock/Winlnet module 212, and the TCP/IP subsystem 214, where the request is formatted in conventional manner. The request is then sent to the network hardware and driver module 224 if the connection to server 206 is an Ethernet connection, or to the Modem and PPP Driver 226, if the connection to server 206 is a telephone connection.

The data or data packet is then sent to server 206 via the internet 204 in conventional manner. The data packet is received by the server 206 and forwarded to the server software 232.

The server software 232 is an application program which executes on the server computer 206.

Preferably, the server software 232 executes a web-page script 234 which, among other things, directs the server software 232 how to retrieve data from the local storage device 236 and send the data to client 202.

In the illustrated embodiment, the client 202 includes an intercept layer 218 and a bandwidth management control module 220. The intercept layer 218 is coupled to receive data from the server 206 and transmits them to the receiving buffer 216. The intercept layer 218 may be implemented with commercial products such as the VPCOM SHIM by Ashley Laurent, Inc. of Austin, Texas. The bandwidth management control module 220 is coupled to the intercept layer 218 and examines the contents of the data packets being received by and sent by the client 202. The bandwidth management control module 220 may modify the contents and timing of the data being received or sent. The bandwidth management control module 220 can also modify or delete the data packets to change the stream of data being sent to or from the client 202.

Additionally, the bandwidth management control module 220 can control the sending of an acknowledge packet to server 206.

The bandwidth management module 220 is also communicatively coupled to the voice application 210 allowing the voice application 210 to send a signal to the bandwidth management control module 220 indicating the current bandwidth needs of the voice application 210. Voice application 210 can also indicate to bandwidth control module 220 the existence and speed of a voice connection. Accordingly, voice application 210 can send a signal to bandwidth management control module 220 indicating that either more or less bandwidth is needed for voice data for the voice application. The bandwidth management control module 220 responds by decreasing or increasing the window size of the acknowledge packet as needed or by increasing, decreasing, or eliminating the time delay for sending the acknowledge packet to the server 206. Thus, the prioritization of the transfer of voice information can have a differing effect on users'data transfer rates, which could impair a co-webbing experience among multiple users of the voice application module 210 in a network 204.

Figure 3 is a flow chart illustrating a preferred method of providing simultaneous display of selected data to multiple users of a network 204 in an environment in which the data transfer rates of the users differ. The preferred method is performed by a co-webbing data transfer management module 250 which can be combined with the voice application module 210. The co-webbing data transfer management module 250 can be located at each of the clients 202 of the system or may be located in an independent server 206 to which the clients 202 are connected.

First, a first user of the network 204 selects data to be displayed from a remote site, which is then received 300 by the client 202. The user that selects new data for display is arbitrarily designated as a master in the multiple-user connection. The users to whom the selection is transmitted are designated as slaves. The master status is maintained as long the user continues to be the only user requesting for data to be transferred from a remote site. However, if another user requests data to be transferred, that user becomes the master and the original master becomes a slave.

The data to be displayed is typically a Web page. The selection of a Web page to display can be accomplished in several ways, as described above with respect to Figure lb. After receiving the selection of data to be displayed, the selection is transmitted, 302 to the at least one other user. In a preferred embodiment, if the at least one other user does not have a web browser active, the receipt of a URL sent in accordance with the present invention launches the default browser of the at least one other user. Alternatively, if a browser is open, the browser receives the URL address as if the at least one other user had typed in the URL address directly. As discussed above, the co-webbing window 116 of the at least one other user is also activated upon receipt of the URL from the master.

Next, the present invention receives 304 a designation of at least one other user to receive the simultaneous display of data. The present invention provides for co-webbing between as many users as are connected together, providing small or large group webbing experiences.

Designation can be accomplished by typing in a user's telephone number, selecting a user's ID from a directory or pull-down list, or other means as is known to those of ordinar skill in the art.

The designation typically occurs at the beginning of, a communication session, bu) additional users can be designated at any time.

The present invention then sends 308 the selection of the described data to the at least one other user. Then, the present invention synchronizes 312 the transfer of data between the first user and the at least one other user. In accordance with the present invention, the synchronization is preferably performed by a single co-webbing data transfer management module 250; however, the different functions may be executed by separate modules implemented as hardware, software, or firmware, as is known in the art.

Figure 4 illustrates a more detailed embodiment of the present invention in which synchronization is provided. This method applies to systems in which the present invention is located on a server 206 and in systems in which the present invention is located only on clients 202, and the clients 202 are configured in a master-slave configuration as described above. First, the client 202 of the master determines 400 whether the selection of data is a request for transfer of a frame. A Web page may be displayed in a separate scrollable window, and if displayed in this format, the Web page is called a frame. Web pages are typically identified as frames in the code describing the web page. If the request is for a frame, the master sends 404 the URL information to the client (s) 202 of the at least one other user. When a sub frame URL is received 406 by the master, the client 202 of the master does not immediately send the subframe URL in accordance with the present invention. Rather, the client 202 of the master waits 408 for an acknowledgment from the slave (s) before transmitting the subframe URL. More specifically, in one embodiment, the master waits for an acknowledgment from the slave (s) that the slave has completely received the Web frame from the remote site prior to sending the subframe URL to the slave. This ensures that the slave will correctly interpret the subframe URLs when it receives the subframe URLs. The acknowledgment received from the slave is preferably a data packet containing unique identifier that the present invention recognizes as indicating that a slave has received the frame. In an alternate embodiment, the master recognizes the receipt of a frame, and then suppresses further transmission of subframe URLs to the slaves. In this embodiment, when a slave receives the master frame URL, it will be able to correctly interpret the subframe URLs when it receives the subframe URLs from the server 206.

In a system in which there are multiple slaves, the master must wait until all slaves have sent acknowledgments before sending the subframe URLs. This increases the likelihood that the slaves will be displaying the Web page simultaneously. In one embodiment, the master sends subframe URLs to slaves as soon as an individual slave transmits an acknowledgment. In this embodiment, maximization of simultaneous viewing is sacrificed to eliminate potential long wait times created by an outlier slave client 202. For example, if the client 202 of one slave malfunctions, in this embodiment the other slaves will continue to provide the co-webbing experience. In an alternate embodiment, the master waits to receive acknowledgments from all slaves, but if one slave does not send an acknowledgment within a predefined time limit, or if a predetermined percentage of slaves have sent acknowledgments, for example, 75%, then the master sends the URLs to those slaves which have sent the acknowledgments. This embodiment provides a compromise between simultaneous viewing and reducing the effect of outliers.

In an alternate embodiment, the master waits for an acknowledgment from the slave (s) that the slave has initiated the transfer of the frame. The initial transfer of frame data identifies that the Web page is a frame, and thus as soon as the slave receives this information the slave is able to recognize subframe URLs as being sub frames and not separate Web pages.

If the present invention determines the : ; e lection of data is not a request for transfer of a frame, then the master send$.. 412 the URL information immediately upon receiving the URL.

Upon receiving 414 a second URL from the master, the present invention sends 416 the second URL without waiting for acknowledgment. In this circumstance, the master sends the new URL immediately because the new URL is specifying a new Web page to be independently viewed and to ensure synchronicity, the slaves must immediately begin transferring data from this new remote site. Thus, in accordance with the present invention, simultaneous display of data is achieved through synchronizing the transfer of data between a remote site and multiple users of a network. Even if the users have different connection speeds due to differing hardware, server connections, or Internet traffic, simultaneous display of data is achieved in accordance with the present invention. Additionally, the prioritization of the transfer of voice information also may result in different transfer rates for different users. However, as described above, the present invention provides for a simultaneous display even in an environment where the data transfer rates are different to multiple users because of the prioritization of voice information over non- voice data such as Web pages.