US 20030078964 A1
A system and method is provided for reducing the time a user needs to wait for information requested from a remote server on a communications network, for example, a Web server on the Internet. In an exemplary embodiment the system is user centric and the goal is to keep all data the user needs as the close to the user as practical. The user's characteristics and usage patterns are used to determine what to cache and for how long, what to pre-fetch, what to refresh, and what to retrieve. In addition, by segmenting information and utilizing parallel communication channels, data transfer across the last mile can be significantly increased.
1. A method for caching data for use by a browser or application program on a computer, comprising:
storing an item of data in a cache retrieved from a server by said browser or application program;
absent any action by said browser or application program, automatically updating said item in said cache;
displaying said updated item from said cache on said browser or application program.
2. The method of
3. The method of
4. The method of
5. The method of
6. A method for refreshing first data in a cache of a first computer system from second data in a second computer system, said first computer system connected to said second computer system by a communications network, said method comprising:
when said first computer system is not busy, sending a refresh request for said first data to said second computer system;
using said refresh request, locating said second data;
when said second data is a newer version of said first data, sending said second data to said first computer system; and
replacing said first data by said second data in said cache.
7. The method of
8. The method of
9. The method of
10. A system for distributing selected data from a host server across a plurality of caches on a communications network, said communications network, comprising:
a first cache of said plurality of caches connected to said host server and having a first replica of said selected data;
a second cache of said plurality of caches connected to said first cache via a Point of Presence access device and connected to a user PC, wherein said second cache has a second replica of said selected data and wherein said second and first replicas are linked together; and
a browser executing on said user PC for retrieving said selected data by first using said second replica.
11. The method of
12. The method of
13. A method for a first computer system responding to a user request for data from a second computer system having a cache, comprising:
receiving said user's request for data from said second computer system;
retrieving response data corresponding to said user's request;
storing a network address for said second computer system with said response data in said cache; and
sending said response data to said second computer system.
14. The method of
15. The method of
16. A method for pre-fetching data for a user at a first computer system from a second computer system via a communications network, comprising:
determining a frequency in user requests sent by said first computer for selected data from said second computer system; and
requesting said selected data by said first computer at a value higher than said frequency, such that one item of said selected data is available at said first computer system before a corresponding user request is sent.
17. A method for providing a Virtual Private Network (VPN) between a first computer and a second computer via a public communications network, comprising:
establishing a VPN between said first computer and said second computer by using a centralized permission table comprising said first computer's address and said second computer's address; and
when said first computer has a plurality of parallel communication links to said second computer, teaming said plurality of parallel communication links to increase data flow between said first and second computers.
18. A method for adjusting data traffic from a first computer to a second computer, said data traffic needed to support graphics on a computer monitor of said second computer, said method comprising:
sending said computer monitor's display characteristics including a first number of pixels per inch, to said first computer;
evaluating a second number of pixels per inch for a graphic item;
when said second number is greater than said first number, creating a modified graphic item from said graphic item with a reduced number of pixels per inch; and
sending said modified graphic item to said second computer.
19. A method for selecting a proxy server from a plurality of proxy servers in a proxy stack for a computer, comprising:
setting an order for said plurality of proxy servers in said proxy stack by a central proxy stack manager; and
each time a request for a proxy server of said plurality of proxy servers is made by said computer, selecting a proxy server of said plurality next in order in said proxy stack;
20. The method of
21. A system for providing web content, comprising dynamic data and static graphics, to a browser executing on a computer, comprising:
a cache for providing a substantial portion of said static graphics to said browser, wherein said cache is connected to said computer by a Local Area Network; and
a virtual circuit connection to a Web server for providing said browser with a substantial portion of said dynamic data.
22. A method for load balancing data transferred from a first computer to a second computer via a plurality of communication links between said first and second computers, said method comprising:
establishing a TCP/IP connection for each communication link of said plurality of communication links; and
dividing said data between said plurality of communication links based on factors to significantly reduce transfer time of said data.
23. The method of
24. A method for reducing time to transfer a file or data block between a first computer and a second computer via a plurality of communication links, comprising:
sending said file or data block by said first computer using a first link of said plurality of communication links;
sending a portion of said file or data block by said first computer using a second link of said plurality of communication links; and
said second computer, after receiving all of said portion of said file or data block, but not all of said file or data block, reconstructing said file or data block.
 In the following description, numerous specific details are set forth to provide a more thorough description of the specific embodiments of the invention. It is apparent, however, to one skilled in the art, that the invention may be practiced without all the specific details given below. In other instances, well known features have not been described in detail so as not to obscure the invention.
 In order for individuals and businesses to use the Internet as an effective commercial vehicle, the time for a user to request and receive information must be significantly reduced compared to the typical times that occur today. The present invention provides both a “super” system that may be overlaid on parts of the Internet infrastructure and techniques to increase information flow in the network, which, either separately or in combination, significantly reduce the user's wait time for information from, for example, Web sites or other users.
FIG. 2 is a simplified, but expanded, block diagram of FIG. 1 and is used to help explain the present invention. Where applicable the same labels are used in FIG. 2 as in FIG. 1. The modem 210 includes the DSL modem 122, cable modem 124, dial-up modem 126, and wireless transceiver 128 of FIG. 1. Likewise the access device 220 includes the corresponding DSLAM 130, CMTS Headend 132, RAS 134, and wireless transceiver 136 of FIG. 1. The digital connection devices 212 and 222 include the CSU/DSU devices 146 and 150, and in addition include, satellite, ISDN or ATM connection devices. FIG. 2 has an additional connection between LAN server 144 and modem 210, to illustrate another option for a LAN to connect to the PoP 112 besides the digital connection device 212. Most of the computer and network systems shown in FIG. 2, communicate using the standardized Transport Communication Protocol/Internet Protocol (TCP/IP) protocol.
FIG. 3 is a block diagram of the communication path between a browser and a web server of an embodiment of the present invention. The conventional exchange between browser 512 and web server 182, when a user using browser 512 requests a Web page 514 from web server 182, was described above. An embodiment of the present invention creates a plurality of “super” modules, including Super User 540, Super Appliance 532, Super Central Office (CO) server 534, Super CO Concentrator 536, and Super Host 538, that provides an alternative super freeway path to exchange data between browser 512 and web server 182. The user request for Web page 514 is sent by browser 512, executing on PC 140, to Super User software 530 also running on PC 140. Super User 530 then sends the user request to Super Appliance software 532 running on LAN server 144 (or in an alternative embodiment executing on its own server). Super appliance 532 then sends the user request to Super CO Server 534, which sends the request to Super CO Concentrator 536. The Super CO Server 534 and Super CO Concentrator 536 may be standalone servers or may be software that runs on PoP server 152. Super CO concentrator 536 sends the user request via Internet 160 to Super Host 538 which may have its own server (or in an alternative embodiment Super Host 538 is software that runs on web server 182). The user request proceeds from Super Host 548 to web server 182, which retrieves web page 154 from a web site running on web server 182 (the web server 182 may include a Web farm of servers and multiple Web sites). The web page 514 then proceeds back to browser 512 via Super Host 538, Super CO Concentrator 536, Super CO Server 534, Super Appliance 532, and Super User 530.
 In other embodiments, one or more of the Super Modules may be missing, for example, the Super Appliance 532. In the case of a missing Super Appliance 532, Super CO Server 534 exchanges information with Super User 530 through LAN server 144. Another example is if Super Host 548 was not present, then web server 182 exchanges information with Super CO Concentrator 536. Thus if a Super Module is missing, the corresponding normal module, e.g., PC 140, LAN server 144, PoP server 150, PoP router 154, and web server 182, is used instead. All or some of the Super Modules can be used and as long as there is at least one communication link between at least two different Super Modules, the information flow across the link improves significantly.
FIG. 4 is a block diagram of the Super Modules inserted in the conventional system of FIG. 2 of an embodiment of the present invention. The same labels are used in FIG. 4 as in FIG. 2 where the devices are the same or similar. Super User 540 is connected through modem 210 is connected to PoP Server 152 via access device 220. A local area network having Super User 530, Super User 542, and Super Appliance 532 is connected to modem 210 or digital connection device 212, where digital connection device 212 is connected to PoP server 152 by digital connection device 222. Super appliance 532 includes software executing on LAN server 144. Server 152 is connected to router 154 via switch 420, which detours the packet traffic to Super CO Server 534 and Super CO Concentrator 536. Router 154 is connected to the Internet cloud 160. From Internet 160, traffic can go to Super Host 538 connected to web server 182 or to Super Host 550 connected to web server 184.
 Super System Components
 Described below is one embodiment of each of the components of the super system of FIG. 4, including Super User 540, Super Appliance 532, Super CO Server 534, Super CO Concentrator 536, and Super Host 538.
 The Super User 530 includes software which resides on the user's PC, e.g., PC 140. A browser, e.g., Microsoft's Internet Explorer, is set to proxy to the Super User 530, so that all browser requests for data are supplied from the Super User 530. In addition, all user requests via the browser are sent to the Super User 530. Hence the browser is isolated from the rest of the network by the Super User. The Super User caches all the data the user has requested in a local cache on the user's PC, so that when the user requests the data again, it may be retrieved locally, if available, from the local cache. If the data that is cached exceeds a predetermined file size, then the Super User analyzes all the data in the local cache and deletes the data that is least likely to be used. For example, a conventional least recently used algorithm may be used to discard old data. Some of the software function of Super User 540 are:
 1. Caching: If the browser requests data that exists in the local cache and the data meets the cache life requirements, then the data is supplied from the local cache. Otherwise the data is retrieved from the nearest Super Module cache, e.g., the Super Appliance 532 or Super CO Server 534, Super CO Concentrator 536, or Super Host 538, where the updated data is available or if not available from any Super Cache then from the Web server. Each data element has a cache life, that is how long it can be used from a cache before it needs to be refreshed.
 2. Refreshing the Cache: When the Super User PC is idle (not actively retrieving data from the Internet), the Super User checks the local cache and automatically refreshes data that is reaching its cache life. The Super User, using Artificial Intelligence (AI) or other techniques, prioritizes the refreshing based on what it determines the user is most likely to request. For example, the Super User can keep a count on how often a user accesses a web page. A higher count would indicate that the user is more likely to request that web page in the future, and the Super User would automatically refresh that page.
 3. Pre-fetching: Using AI or other techniques the Super User, during idle times, pre-fetches web pages (i.e., retrieves web pages that the user has not yet asked for) that have a high probability of being needed by the user. For example, if a user is viewing some pages on a catalog site, then there is a high probability that the user will view other pages on the site in the same category. The Super User would pre-fetch these pages. The pre-fetching increases the probability that the user will get the data from the local cache.
 4. Courier packets (described later) are packaged and the packaged data compressed by the Super User before being sent to the Super Appliance or Super CO Server. Courier packets are un-packaged and the un-packaged data uncompressed by the Super User before being sent to the browser.
 The Super Appliance 532 includes software executing on LAN server 144. Some of the functions performed by the Super Appliance 532 includes, firewall security, global caching, teaming, smart hosting, and email management. Further function performed by the Super Appliance software include:
 1. If the Super Appliance is attached to a Super CO Server, then all the data transmitted between them is compressed and packaged into courier packets, otherwise standard Internet requests are used and the responses are packaged into courier packets before the responses are sent to the Super User.
 2. The Super Appliance also automatically copies and maintains web sites that are used frequently by its users.
 3. If the Super Appliance is attached to a Super CO Server, then it updates its copy of the web sites only when notified of changes from the Super CO Server. If the Super Appliance is not attached to a Super CO Server then it checks for updates of the web sites during idle times and/or during periodically predetermined intervals.
 4. If Super Users are attached to the Super Appliance then all data responses are transmitted in compressed format to the Super Users. If regular users are attached to the Super Appliance, then the data responses are decompressed in the Super Appliance and sent to the users. If the Super User is maintaining web sites, then anytime a web page is updated on the Super Appliance a notification is sent to the Super User so that the Super User may request the change.
 5. The Super User will also notify the Super Appliance of information about the user's available resources such as memory, CPU and PC monitor density. The Super Appliance uses the available resource information of each Super User to determine the most efficient method to forward information. For example, in the case of PC monitor density, adjustments can be made to the graphics transmitted over the local area network. Sending high density graphics to a monitor that can not display the graphics is a waste of network resources. The software in the Super Appliance adjusts the graphics density before transmitting the data.
 6. If more than one Super User requests the same data, then the Super Appliance implodes the request and sends only one request to the next Super Module, e.g., the Super CO Server. If there is not another Super Module between the Super Appliance and the Web site, then the request is still imploded and a standard TCP/IP request is made. When the response to the imploded request is received then the data is exploded by the Super Appliance and the data is sent to the appropriate Super Users.
 The more web sites that are maintained at the Super Appliance the more the access speed for web pages approaches the local area network speed. The more web pages maintained at the Super User the more the web access speed approaches hard disk access speed. The more web pages that can be copied and maintained on the Super Appliance and the Super User, the less the last mile becomes a bottleneck for response time.
 The Super CO Server 534 is the bridge between the Internet backbone 114 and the user 110. One objective of the Super CO Server 534 is to minimize the traffic between the user and the Internet. The Super CO Server accomplishes this by copying the web sites accessed by the Super Users or normal users. The more web sites that are hosted on the Super CO Server, the more the network is optimized by reducing the movement of data across the network. If the web sites that are hosted at Super CO Server come from web sites stored on a Super CO Concentrator 536, the Super CO Server 534 requests updated web pages whenever notified by the Super CO Concentrator 536 that the web pages have changed. Web pages from the Super CO Concentrator 536 are stored in compressed and repackaged format. If the web sites that are hosted on the Super CO Server are not stored in the Super CO Concentrator, then the Super CO Server checks at predetermined intervals for changes in the web site at the hosting web server. The Super CO Server keeps a log of the web sites that are hosted on every Super Appliance 532 cache. As changes occur to web sites that exist on a Super Appliance cache, a notification is sent to that Super Appliance that changes have occurred and that the Super Appliance should request updated copies of the changed web pages. As data is received from a non Super CO Concentrator site it is compressed, packaged and stored on the Super CO Server. The Super CO Server determines from its request logs the web sites that are being accessed by its users and determines which web sites to copy and maintain at the Super CO Server 534 cache. The Super CO Server will also delete sites that are not being used. If a web site is not being stored and maintained, the web page is maintained in a separate global cache so that if it is requested again it can be supplied from the global cache. A correct balance needs to be maintained between the global cache and the web hosting. If a web page is requested from a Super Appliance then the web page is sent in super compressed and repackaged format, otherwise the web page is decompressed and sent to the requesting user. The optimizations used are related to the amount of compression applied to the variable data (usually text) and the amount of variable data on the web page. The more Rich Data formats are used on the Internet the more optimization is achieved. Flash software, files, java programs, java scripts, music and motion video, etc. are all stored at the Super CO Server.
 The data requests from the Super Appliances that are not satisfied by the Super CO Server cache are sent to the Super CO Concentrator 536 that is responsible for servicing the URL (web site) requested. The requests are packaged, compressed and imploded according to the optimization schemes. In one embodiment, the first level of data implosion occurs at the Super CO Server. In an alternative embodiment implosion is done by the Super Appliance or by the Super Host. The Super CO Server is organized by ISP geography so that duplicate usage characteristics that are regionally oriented can be imploded on request and exploded on response. All requests and imploded requests that cannot be responded to by data in the Super CO Server's cache are passed to the Super CO Concentrator.
 The Super CO Concentrator 536 is organized by Web sites (URL's). This increases the probability that Web site data that users need will be in the CO concentrator's cache. It also increase the probability that requests can be imploded and network traffic can be reduced. Each Super CO Concentrator is responsible for caching and interfacing with the Super Hosts, e.g. 538, and other non Super Host web sites. For non Super Host web sites, Super CO Concentrator 536 is the first Super Module encountered and the initial repackaging, first compression, final implosion, first explosion, the conversion of all graphics to an optimized compression format such as PNG or proprietary compression algorithms, and the first level of super caching occurs. This is also where all the checking and refreshing occurs for the other Super Modules. As data from the Web sites is refreshed and updated the Super CO Servers are notified so that all caches can be updated and refreshed.
 The Web server hosts one or more web sites that are attached to the Internet. The Super Host, i.e., Super Host 538, replies to requests made from the Super CO Concentrators, e.g., 536. Each time a request is made for a down load of any web site hosted on the Web server, the Super Host 538 retrieves the web pages from the Web server and compresses and packages the contents before sending it to the requesting Super CO Concentrator. This improves the efficiency of the web transport by the effective compression rate and by sending a single data block for all the requested web page data. Alternatively, rather than sending all of the data of the requested web page as one single data block, the Super Host may forward information to the Super CO Concentrator as more than one data block to maximize overall transmission performance. In one embodiment, the Super Host may forward the initial HTML document while simultaneously retrieving, packaging and compressing the remaining data. The remaining data can in turn, be forwarded as a single data block or as multiple blocks. The decision to forward as a single block or multiple blocks is based on a number of factors used to minimize the overall transmission time by balancing the data delivery rate to the Super User with the data retrieval rate by the Super Host. Each piece of information is analyzed and compressed using techniques that best perform for the specific type of data. As each Super CO Concentrator request is received, the Super Host records the IP address of the Super CO Concentrator. The Super Host checks the web sites contained on the Web server and sends notifications of any changed web pages to any Super CO Concentrator that has requested data from the web sites historically. This allows the Super CO Concentrator to know when it needs to refresh its version of the Web site and minimizes Web traffic by allowing the Super CO Concentrator to service user requests for web pages directly from its version of the web page in the Super CO Concentrator's cache. The only time the Super CO Concentrator version of the web page needs to be refreshed is when it has changed. This allows for minimized traffic from the web hosting sites to the ISP sites. There are many ISP sites accessing data at each web site. This is a step in moving web sites to the outer fringe of the Internet and bringing compression and packaging to the inner workings of the Internet. The challenge of moving web sites to the outer fringes of the Internet is to make sure data is current, the interlocking of the Super Module caches insures this.
 Due to the content and graphics-rich nature of today's web sites, the delivery of information from a Web server to a user's web browser can take considerable time. The result is a frustrated user who will, in many instances, abandon the web site rather than continuing to wait. This results in a dilemma for the e-commerce web site operator, who may be forced to use simple text with low-resolution images (if any) or run the risk of losing the user.
 Attempts have been made to solve the problem by introducing cache servers at the ISP. Caching servers have proven successful in providing some reduction in user wait time, because they keep copies of web pages that have been recently retrieved by the user and other users. However, caching servers provide no benefit for requests of new web pages, i.e., web pages that have not been previously requested, nor do they update the web pages maintained locally with any changes made at the Web server, i.e., the web pages become stale. Additionally, caching servers have limited storage sizes, and therefore must throw away older content in favor of retaining newer content. Because of this “First-In, First-Out” (FIFO) based methodology, content that may have been cached could be discarded by the time it is need again.
 A solution to the above problems includes an embodiment of the present invention that has the objective of maintaining the data a user needs as close as possible to the user for as long as the user may need it. By trying to maximize the storing of needed data at the Super User or Super Appliance via Super Caches, the amount of data transferred over the last mile and hence, the user's wait time, is significantly reduced. To achieve this, the Super modules with their Super Caches keep essentially a self-maintaining linked mirror of selected web sites or parts thereof. The content of the mirror information is based on the users needs and is keep current by automatic updates during idle times or during scheduled time periods. Hence, if changes or modifications occur to the main web site, the changes or modifications are propagated through the Super Caches. In addition, unlike a caching server that only holds the pieces of a web site that have previously been requested, a smart cache includes one or more link levels of a web site, even the seldom used links. The use of link levels is chosen, because it is probable that a user will use another link on the same level. For example, link level 0 is the home page along with its links to its embedded objects, e.g., graphics and files. Link level 1 would include web pages that are linked from the home page and links to the embedded objects on these web pages. Hence the link levels form a triangle of links with link level 0 as the top. As the number of link levels are further increased, the amount of linked pages and their associated linked objects continue to multiply until eventually the entire web site has been retrieved. Thus all or parts of the web site are replicated. In an alternative embodiment a depth first algorithm could be used rather than a breath first algorithm on the choice of probable links. Further, the only parts of a Super Cache that are deleted are the parts that are determined by artificial intelligence or other means to be no longer needed by the user. For example, a least recently used algorithm weighted by the number of visits by the user could be used to determine when a web page should be discarded.
 Finally, a Super Cache and a caching server are not mutually exclusive; they will work in harmony providing the user with the best of all worlds. If a requested web page does not happen to be in one of the Super Caches, e.g., Super Cache 644 (FIG. 5), the request is the forwarded to the caching server, e.g., ISP Server 152 having ISP cache 630 (FIG. 5). If the requested web page is not in either a Super Cache or in the caching server, the request is then forwarded onto the web site.
 The Super Caches reside at all points in the network. A Super Cache can be located at the LAN server and therefore shareable by all networked users on the LAN. A Super Cache can also be located on a single user's PC. The closer a smart cache is to the user, the faster the contents of the cache can be delivered to the user. The Super Cache through its Super User or Super Appliance Super Module can operate through any type of connection that the user may have to the Internet including dial-up, cable modem, DSL, and any other network access (see FIG. 1).
FIG. 5 shows an example of a Super Cache structure of an embodiment of the present invention. In FIG. 5 there are two user requesters groups 610 and 612 that are connected to point of presence (PoP) 614. PoP 614 is connected through the Internet (not shown) to a data provider group 616. Data requester group 610 includes a browser 620 connected to Super User 540 having Super cache 622. Data requester group 612 has browser 512 connected to Super User 530 having optional Super Cache 632. Super User 530 is also connected to Super Appliance 532 having Super Cache 642. PoP 614 includes ISP server 152 having ISP cache 630, where ISP server 152 is connected to Super Central Office (CO) server 534 having Super Cache 644. Super CO server 534 is connected to Super CO Concentrator 536 having Super Cache 646. Data provider group 616 includes Super Host 538 having Super Cache 648, where Super Host 538 is connected to Web server 182.
 Super caches 642,644, 646, and 648 are inter-linked together (virtual links 650, 654 and 656 respectively) such that they maintain a common set of current data, e.g., some or all of a web site at Web server 182. Optionally Super Cache 622 for Super User 540 is inter-linked with Super Cache 644 (virtual link 652). Also when Super Cache 632 of Super User 530 exists, Super Cache 632 may optionally be linked to Super Cache 642 (virtual link 634).
 The Super User 530 or 540 determines by Artificial Intelligence or other means which web sites the user needs, and loads these web sites into the user's Super Cache 632 or 622 (or the Super Appliance 642). For example, the web sites a user needs may be determined from current and historical user usage. Most people use 20% of the web sites 80% of the time, which means that the Super User (or Super Appliance) cache should have a reasonable finite size that can be maintained on the user's PC. As the Super User loads and maintains the Super Cache on the user's PC, the same web pages are stored in the other Super Caches, e.g. 642, 641, 646, and 648.
 Once the initial web pages are loaded in the inter-linked Super Caches, they must be kept current, i.e., refreshed or updated. FIG. 6 is a simplified example showing the refreshing process for a Super Cache system of one embodiment of the present invention. The user group 612, PoP 614 (except for the ISP Server 152 and ISP cache 630), and data provider 616 are the same as illustrated in FIG. 5. Refresh request flow 660, including individual refresh requests 662, 664, 666, 668, and 669, begins at Super User 530 and proceeds to Web server 182. The data response flow 670, including individual data responses 672, 674, 676, 687, and 679, starts at Web server 182 and proceeds to Super User 530. To aid in explanation, each Super Cache is given a level number, i.e., Super Cache 632 is at level 1 (L1), Super Cache 642 is at level two (L2), Super Cache 644 is at level three (L3), Super Cache 646 is at level four (L4) and Super Cache 648 is at level five (L5). The higher the level the closer the Super Cache is to the Web server 182, conversely the lower the level the closer the Super Cache is to the browser 512.
 Refreshing occurs during the time the processor is not performing higher priority tasks, for example, a user requesting data or receiving data responses or executing application instructions or any other user request. If the Super User is a stand alone (no other Super Modules) then the Super User software retrieves the data from the Internet using any conventional procedure well known to one of ordinary skill in the art, and refreshes the user's Super Cache 632. When the Super User 530, is attached to a Super Appliance 532, then the refresh request goes to the Super Appliance Super Cache 624 (If the Super User, e.g., 540 is attached to the Super Co server 534 as in FIG. 5, then the refresh request is sent to the Super Cache 644). Each Super Module receives refresh requests from its lower level Super Modules. If the data requested is current in its cache, the responding Super Module uses its cache to fulfill the request. If the cache of the responding Super User is not current, the refresh request is forwarded to the next higher level Super Module. This process is repeated until there is no higher level Super Module. Then this level reverts back to standard Internet protocol to send the refresh request to the Web server to satisfy the refresh request. This process keeps the Super Caches current throughout the Super Cache levels.
FIG. 7 is a flowchart of an automatic refreshing process of a Super Cache of an embodiment of the present invention. Super cache at level N 680 (where “N” is an integer) requests a refresh from Super Cache at level N+1 682. At step 684 the first Super Module with cache at level N 680 request a refresh of data, based on for example, a predetermined scheduled time, expired cache life, or receipt of an update notification from the second Super Module with Super Cache at level N+1. At decision node 686, if the first Super Module is busy than a wait loop occurs by going to node 685. When the first Super Module is idle then at step 688 the refresh request is sent to Super Cache at level N+1 682. At step 690 the refresh request is received by the second Super Module, and at step 692 the second Super Module checks its cache to see if the requested data is present and current in the level N+1 Super Cache. If the requested data is not present nor current in the Super Cache, then a second refresh request is sent to a third Super Module with a Super Cache at level N+2 (step 696), when the second Super Module is idle. When the second Super Module is the Super Host 538, then the refresh request is sent to the Web server 192. If the requested data is current in the cache, then at step 698, the first Super Modules IP address is stored along with the requested data in the N+1 level Super Cache. At step 700 the requested data is retrieved from the N+1 level cache, and at step 702 the data is sent to the first Super Module. The first Super Module receives the data response (step 704) and updates the data in its Super Cache (step 706). Optionally, if necessary, an update notification is sent to the previous Super Module with cache at level N−1 (optional step 708).
 The Super Host 538 in FIG. 6 (or in the case it is absent, the Super CO Concentrator 536 or Super CO server 534) actively stores and monitors the web site on the Web server 182. When there is a change on the web site, the Super Host 538 updates its level 5 Super Cache 648. Super Host 538 then sends an update notification 652 (FIG. 6) to Super CO Concentrator 536. When idle, Super CO Concentrator 536 sends a refresh request 668 to Super Host 538. Super Host 538 gets the web site change stored in its Super Cache 648 and returns a data response 674 to Super CO Concentrator 536. Super CO Concentrator 536 updates its Super Cache 646 and then sends an update notification 676 to Super CO server 534. The process repeats with update notifications 650 going to lower levels, refresh requests 666 going to higher levels, and responding data requests going to lower levels until the Super User's level 1 Super Cache 632 is updated with the change. Since there are many users for one web site, the one to many multicasting of a change is an efficient way of updating user caches.
 In an embodiment of the present invention the IP source address of the sender in the user request IP packet is stored with the data in response to the user request in the receiving Super Module's Super Cache. As data requests move up the Super Cache levels, i.e., the level number increases, the requesting Super Module, e.g., level N, identifying addresses are stored along with the response data in the receiving Super Module Super Cache, e.g., level N+1. Any event that causes an update to the data, for example, a user request or the Super Host checking the Web server, and the update is promulgated to all lower level caches. Since this a one to many activity the efficiencies of keeping the caches fresh is very good.
FIG. 8 is an example of the storing data from multiple users requests and the requesters IP addresses in the cache of receiving Super Module. FIG. 8 shows four Super Modules, Super Module1 710 having Super Cache 712, Super Module2 714 having Super Cache 716, Super Module3 715 having Super Cache 717, and Super Module4 718 having Super Cache 720. Super modules 710, 714, and 715 are connected to Super Module4 718. Super module1 710 sends user1 request 730 via communications link 732 to Super Module4 718. Super module4 718 executes user1 request 730 and retrieves response datal 762. Super module4 718 associates response datal 762 with the IP source user1 address 766 of user1 request 730, e.g., IP address of Super Module1 710 in, for example, row 742 of a data structure 740. Super module4 718 returns response datal 750 to Super Module1 710, which stores the data in its Super Cache 712. Similarly, Super Module2 714 sends user2 request 734 to Super Module4 718 via link 736 and Super Module3 715 sends user3 request 735 to Super Module4 718 via link 737. Super module4 718 similarly processes the user requests, and creates in data structure 720 row 744 having response data2 764-1 with user2 IP address 768, and row 746 having response data2 764-2 (i.e., a duplicate of response data2 764-1), with user3 IP address 769. Similarly, Super Module4 718 sends the same response data2 in 754-1 and 754-2, to Super Modules 714 and 715, respectively. Note that when response data2 (764-1 and 764-2) is changed, then data structure 720 indicates that User2 IP Address 768 and User3 IP Address 769 need to be sent an update notification. Thus an update can be multicast down through the cache levels.
 For systems that employ dynamic IP addresses, the data structure of the 740 includes an additional entry for User ID to maximize the performance of the Super Cache, e.g., Userl ID 770, User2 ID 772, and User3 ID 774. Each time a Super Cache level N, with a dynamically assigned IP address, connects to Super Cache level N+1, the Super Cache N+1 checks its data table 740 to match the unique User ID to the new dynamically assigned IP address to ensure the IP address field is always current, e.g., User2 ID 772 with User2 IP Address 768. This method allows the Super Cache N+1 to take maximize the user of information previously cached for each user with dynamically assigned IP addresses, even though the user IP address may have changed. One embodiment is to include the User ID field in the data structure 740, e.g., user IDs 770, 772, and 774, or to create a separate data structure.
 In another embodiment the Super User (or Super Appliance) determines by artificial intelligence or other means the probability of the user going to web pages that have not been requested. For example, there may be a good probability that the user will go to links to the web pages already stored in the Super Users Super Cache or a good probability that a user will use some links on a page of a web site never before visited by the user. Then during idle time, the Super User can pre-fetch web pages to try to increase the probability that the user can satisfy future requests from its Super User cache (or Super Appliance cache). Pre-fetch requests are treated like refresh requests except that they have the lowest priority, i.e., below user requests, updates, and refresh requests. Pre-fetched web pages are also not refreshed unless there is no other activity on the network.
 In examining the web pages users retrieve, the web pages include textual data and graphics. While there are efficient and simple algorithms for text compression, compression of graphics data is much more difficult. Fortunately, many web page graphics do not change much. In another aspect of the present invention, the graphics are stored close to the user in either the Super User Super Cache or Super Appliance Super Cache or both.
FIG. 9 shows an example of data flows for graphics and text or dynamic data between a user and a web server over the Internet of an aspect of the present invention. FIG. 8 shows a browser 532 connected to Web server 814 via a Super User 530, Super Appliance 532 having Super Cache 642, PoP 810, and Internet 812. Super cache 642 stores the graphics on a web page that typically does not change and has a low compression ratio. These Web graphics are supplied by Super Cache 642 via path 820 to browser 512. The text and the dynamic requests which typically change, are easy to compress and have a high compression ratio, are requested by the browser over path 822 to Web server 814.
 The above approach works in conjunction with online purchasing at a web site supporting e-commerce. The user interacts with the Super Cache 642 to receive high-resolution, animated and 3D graphics depicting the web site's products. Because this content needs only to be delivered from the Super Cache 642 to the user's browser, and not transmitted across the Internet, the interaction is crisp, and fast. When the user makes a request that requires a secure purchase or a database lookup provided in an Active Server Page, the Super Cache 642 does not handle that request, instead, it is passed directly on to the web server 814 via path 822. As most requests are small, they travel rapidly back to the web server 814, which performs its standard processing. The results are delivered back to the user through the Super User 530.
 As FIG. 9 indicates, dynamic data and data that is tagged as non-cacheable is usually not saved in cache for it needs to be refreshed on every web page request. For a Super Appliance where there are multiple users with frequent, but expected, requests for dynamic data, requesting the data at a frequency higher than the expected or average frequency, pre-fetches the data before needed and reduces the users wait time. A dynamic pre-fetching list is created using Artificial intelligence or other means when data is requested by more than one person on a frequent basis. The parameters can be inputted to define frequency and timing.
 Another aspect of the present invention the smart module caches streaming files the same way it does normal web page data. Unless the streaming data is real time the streaming data is cached in the Super Caches as close to the user as possible. The next time a non-real time streaming file is requested it exists close to the user, hence significantly reducing network resources required for delivery.
 In one embodiment of the present invention multiple connections of any type can be “teamed” together to provide higher bandwidth. This higher bandwidth provides faster retrievals of web pages, graphics and file downloads than with a single connection of the same type. Teaming requires a Super Module having two or more communication links going to one or more destinations. Since the Super Module software is on top of the conventional communications software, e.g., standard modem software, the Super Module can exchange application data with each of the two or more communication links, even if each communication link has a different communications protocol.
 The teaming typically occurs between two Super Modules having two or more communication links. A load balancing algorithm dynamically adjusts the TCP/IP packet traffic to try to minimize the transfer time of data. Factors used in the load balancing algorithm include, but are not limited to, the speed of the connections, the current load on the connections, quality of service of the connections, and the last connection used. For example, if there is a fast DSL connection and a slow dial-up modem connection to a Super Module, and both are not being used, it is likely that the fast DSL connection is used first.
 Connection teaming is different from the standard multi-link point-to-point protocol (MLPPP) which also combines multiple connections. MLPPP treats the multiple connections as a single pipe. MLPPP at the sending side receives network protocol data units (PDUs) from higher-layer protocols or applications and fragments these PDUs into smaller packets, adds an MLPPP header to each fragment and sends them over all the available links. On the receiving end, the MLPPP software takes the fragmented packets from the different links, puts them in their correct order based on their MLPPP headers and reconverts them to their original network-layer PDUs. The MLPPP standard does not dictate how traffic is balanced over these member PPP links. On the other hand connection teaming does not need another special communication protocol, i.e., Point-to-Point Protocol (PPP), besides the standard TCP/IP protocol, and teaming intelligently uses the available links (and may not use some).
FIG. 10 shows an example of connection teaming of an embodiment of the present invention. Super User 910 with Browser 908 is connected to PoP 935 via two dial-up connection lines 912 and 914. Browser 920 is connected to Super User 922 and both the browser software and Super User software execute on the user's PC. Super User 922 is connected to Super Appliance 924 having Super cache 926. Super Appliance 924 has a high-speed link 928 and two low speed modem links 930 and 932 to PoP 935. Pop 935 is connected to the Internet 940 by a high speed data link 937. Web server 942 is also connected to the Internet 940.
 For example, look at the teaming connections 912 and 914 between Super User 910 and PoP 935 having Super CO server 534 (not shown). Both connections 912 and 914 need to be online at the same time. This means that if analog modems are used, there needs to be two modems, two phone lines, and usually two ISP accounts (or a single ISP account that supports simultaneous logins). In other embodiments more than two connections of different types may be used.
 To explain how teaming works, the sample path to and from Browser 920 to Web server 942 via Super User 922, Super Appliance 924, PoP 935, and Internet 940 will be used. A user types a single request into his browser 920, such as http://www.gm.com. The request is sent over the sample path to the Web server 942. The web server 942 responds by sending a single HTML file back to the browser 920. That HTML file contains many additional links, typically for the embedded graphic images that comprise the web page. The web browser 920 automatically generates requests for those links, sometimes numbering in the dozens. The connection teaming software in, for example, the Super Appliance 924 senses the fact that many related requests are being generated by the web browser 920. The Super Appliance 924 using load balancing may spread these requests across some or all of the available connections 928, 930, and 932 or may send most of the requests over the high speed connection 928 and split the remainder between low speed connections 930 and 932.
 Using the example of the General Motors (GM) home page, over 36 embedded graphic requests may be automatically generated. Without Connection Teaming, one connection would have to process all 36 requests by itself. Using Connection Teaming with two connections, each connection only has to handle 18 requests. If four connections were available to Connection Teaming, the load would be further reduced to only 9 requests per connection. Hence using connections in parallel has significantly reduced data transfer time.
 File Transfer Multiplier
 The Super Appliance contains the intelligence to make decisions based upon HTTP, HTTP-FTP or FTP requests that it receives from an end-user's application such as a web browser. These decisions can dramatically improve Internet access performance for transferring files and web page graphics, especially over the last mile. In addition to HTTP, HTTP-FTP and FTP, the Super Modules employ File Transfer Multiplier to reduce the time for any application to transfer significant amounts of data.
 An end-user application, such as a web browser, is configured to forward its HTTP and HTTP-FTP requests to the Super Appliance. When the end-user types an address or clicks on a link in his web browser 920, a request to receive information from a specific HTTP or HTTP-FTP server is generated by the browser 920 and forwarded to the Super Appliance (either via a normal PC or a Super User). Upon receipt of this request, the Super Appliance contacts the Web server 942 and gets certain initial data on the file, i.e., file information, including: 1. an acknowledgement that the requested file is available from the destination server; 2. the “timestamp” (i.e. date and time) of the requested file; 3. the size in bytes of the requested file; 4. the protocol supported by the destination server (specifically, to check if it is running the HTTP 1.1 protocol supporting the “partial receive” function or the FTP protocol supporting the “transfer restart” feature); and 5. if there are alternate servers that can transmit the file or portions of the file.
 When the Super Appliance receives this file information, it makes several decisions on retrieving the actual file:
 1. If the requested file exists in Super Appliance's Super Cache 926 and has the same timestamp as the file information sent from the Web server 942, then the Super Appliance 924 delivers a copy of the file directly from the Super Cache 926 to the end user's browser 920. This saves on the need to retrieve the same file across the Internet providing significant performance improvements to the end user.
 2. If the file information from the Web server 942 has a timestamp more recent than the one in Super Appliance's cache 926, or the file does not yet exist in the Super Appliance's cache 926, then the Super Appliance 924 retrieves the file across the last mile from the other Super Caches (see FIG. 6) or from the Web server 942. In this case the file transfer multiplier technique, which is a part of one embodiment of this invention and described below, is needed to improve the efficiency of transferring the file over the last mile.
 The file transfer multiplier technique takes advantage of a feature found in HTTP 1.1 compliant web servers and a feature found in FTP servers called “transfer restart”. Each of these features provide the same basic capability, they allow a Super Module to specify what part of a file to download. The file transfer multiplier technique works regardless of whether the request is for a large graphic image to be displayed on a web page, or file transfer using the HTTP-FTP protocol (the form of FTP generated by web browsers). From the user's perspective, they simply make a request from their browser 920 that is forwarded to the Super Appliance 924. The Super Appliance 924 then determines if the next level Super Module cache, or web or FTP server processing the request supports HTTP 1.1 or the FTP transfer restart feature. If so, the Super Appliance 924 requests the different parts of the file over one or more connections. If the web or FTP server does not support the required features that allow the file to be split, then the Super Appliance 924 receives the file over one connection as it would normally have been done.
 More specifically, the Super Appliance 924 generates multiple requests for the file. The first request asks that the Web/FTP server (or another Super Module) send the entire file. The other requests ask that the Web/FTP server, e.g., Web server 942, (or another Super Module) send the other segments of the file. The Super Appliance 924 receives both the first segment and the other segments of the file in parallel. As the first segment of the file is being received by the Super Appliance, it is immediately forwarded onto the browser 920 via Super User 922, just as the browser would expect. The other segments of the file are stored on the Super Appliance PC as they are being received and may be forwarded immediately or after a delay to the browser. Since typically the LAN network speed is greater than the last mile link, the user receives the whole file in a smaller amount of time. If for any reason the request for the other segments of the file fails or is being received at a slower pace than the first request, the Super Appliance cancels the other requests and allows the first request to receive the entire file. If there are multiple servers that can send the file, the Super Appliance can request different portions of the file from different servers therefore load balancing the traffic and achieving faster delivery.
 File transfer multiplying gains its performance boost due to sending in parallel multiple segments of a file. When using file transfer multiplying in an environment with a single connection to the Internet, a performance gain is received through the better utilization of that single connection. It is not uncommon for the throughput of a single request to be “throttled down” by an ISP, so that the ISP's bandwidth can be spread across many requests for its many users. For example, there may be a 416 Kbps DSL connection between the end-user's PC and the ISP. The ISP may impose a limitation that any one request should not receive more than 200 Kbps worth of bandwidth. Without file transfer multiplying, a single request for a file could therefore go no faster than the 200 Kbps would allow, leaving 216 Kbps of bandwidth unused. With file transfer multiplying, multiple requests are made for the file (one request for the first segment of the file and the other for the second segment of the file). In the environment with the same limitation of 200 Kbps per request, each request of the file gets 200 Kbps worth of bandwidth, which when combined provides 400 Kbps to bring down the first half and the second half of the file. This significantly increases the bandwidth that is being unused.
 When using file transfer multiplying in an environment with Super Appliance's Connection Teaming feature managing multiple connections, the performance gain is enhanced by sending one or more requests through one connection and the other requests through the other connections. In a situation where there is no “throttling down” by the ISP, all requests would get the full bandwidth of each connection in order to bring down the segments of the file. In a case where the throttling down does occur, the remaining bandwidth will be used by Super Appliance for processing other requests for other users or by requesting portions from other servers.
FIG. 11 gives examples of the time savings due to file transfer multiplying of an aspect of the present invention. Horizontal axis 1010 has the time indications of “0” start time 1012, time “T” 1014, and time “2T” 1016, i.e., (2×T). Assuming that a file propagating over a communications link 930 (FIG. 10) takes a time period of 2T 1016. By splitting the file 1020 in half and sending the first segment 1044 of the file 1020 over link 930 (FIG. 10) and simultaneously sending the second segment 1032 of the file 1020 over a second link 932 (FIG. 10) the time to take transfer the whole file 1020 is T or the time is halved. Also the whole file 1020 could be sent over link 930, while concurrently the second segment 1032 is sent over line 932. If the second segment 1032 arrives successfully, then the second portion of the transmission on link 930 is not needed. If one link is a high-speed DSL link 928 (FIG. 10) and the second link 930 (FIG. 10) a dial up modem link, then the file 1020 can be divided disproportionately. The first big segment 1040 is sent over the DSL link 928 and the remainder small portion 1042 of file 1020 is over the slow link 930.
 The above outlines the process of an “External File Transfer Multiplier” between the application server and the Super Module furthest from the user. External File Transfer Multipliers require that the application server support a file splitting standard such as HTTP 1.1 partial receive or FTP transfer restart. The Super Modules also use “Internal File Transfer Multiplier” to reduce delivery time between Super Modules independent of whether the application server supports a file splitting feature. To achieve this, each Super Module supports a data splitting function allowing information sent between Super Modules to be divided into several blocks that are forwarded to the next Super Module in parallel rather than in series. In addition to being application independent, the Internal File Transfer Multiplier can accelerate delivery of data from multiple sources. Internal File Transfer Multiplier improves transmission times for data transferred over a single high speed line or in situations where Teaming is used to deliver information over multiple lines to the next Super Module. Internal File Transfer Multiplier is bi-directional and improves data uploading, such as sending email with large attachments as well as data downloads, such as file transfer from a remote server.
 As shown by FIG. 11 above, when splitting Courier packets or files between different speed access connections the data is typically not divided into equal size files, instead the data is split into files that match the speed of the access so that all transmissions complete at the same time. As another example, assume a Super Module needs to transfer “n” bytes of data across two lines where one line is 4 times faster than the other, then the fast line would have a file four fifths the size of the data to transfer and the slower line would have a file of one fifth the size of the data to be transferred. This allows the transfers to complete at approximately the same time. If the file had been split evenly, the fast line would complete and the slow line would delay the effective response time.
 The segmenting of a file and parallel transmission of the file segments, can be done with any number of access lines. Since the requesting Super Module does not know the size of the data it is requesting from the sending Super Module, this information must be deduced by the requesting module using the speed of the access lines. When the sending Super Module receives a request for a file that needs to be split, it will split the file into segments whose sizes are based on the speed of the access line that the segment will be sent on. The segments are sent on their corresponding access lines, so that the requesting Super Module can coordinate the segment transfers by the speed of the access lines. This technique eliminates the waiting for completion of transfer because of slow lines. This is especially valuable when the data is repackaged into large courier packages.
 Monitor Resolution
 In an embodiment of the present invention the Super User 540 or Super Appliance 532 informs the Super CO Server 534 of characteristics of the PC monitors, for example, pixels per inch, maximum resolution, and maximum number of colors, that are supported. For example if the monitor pixels per inch is less than the graphics pixels per inch, then the graphics pixels per inch of the images is reduced before being sent from the Super CO Server 534 to the Super User 540 or Super Appliance 532. A company can also choose the monitor characteristics it wishes to support and the Super CO Server 534 adjusts all the graphics elements of a web page to meet these parameter.
 Proxy Stacks
 A proxy server is an intermediary computer that is located between an application on a user's PC, e.g., a browser and the a server on the Internet. The proxy server intercepts all request to the server and tries to fulfill the request itself. If it cannot the request is forwarded to the server. For example, when a user visits a web site on his browser, the browser sends a request to an assigned proxy server. If the proxy server recently visited that site (because another user already went there), the proxy server will have stored, hopefully the same web pages, on its hard drive. So instead of needing to download these pages from the web server, the user's PC downloads these pages from the Proxy Server, thus speeding up access times. Some of the major online services, such as Compuserve and America Online, for example, employ an array of proxy servers.
 In a further embodiment of the present invention proxy stacks having two or more proxy servers are used. Each Super User has two or more primary proxy servers, e.g., Super Appliances, which can be used in a priority order or switched with each user request. And each Super Appliance has two or more as proxy servers, e.g., Super CO servers. A user goes through at least two proxy servers, i.e., a Super Appliance proxy server connected to a Super CO proxy server before reaching the Internet.
FIG. 12 is an example of using Proxy Stacks of an embodiment of the present invention. Three Super Users 1110, 1112, and 1114 are connected by switch 1116 to proxy servers at Super Appliance 1120 and 1122. Super appliance 1120 is further connected to two other proxy servers on Super CO servers 1130 and 1133 via switch 1124. And Super Appliance 1122 is connected to proxy servers on Super CO server 1130 and 1132 via switch 1126. Super User 1110 has a first proxy stack with Super Appliance 1120 proxy followed in the stack by the Super Appliance 1122 proxy. Super User 1112 has a second proxy stack with Super Appliance 1120 proxy followed in the stack by the Super Appliance 1122 proxy. Super User 1110 has a third proxy stack with Super Appliance 1120 proxy followed in the stack by the Super Appliance 1122 proxy. Super appliance 1120 has a fourth proxy stack with Super CO server 1130 proxy followed in the stack by Super CO server 1132 proxy. Super appliance 1120 has a fifth proxy stack with Super CO server 1130 proxy followed in the stack by Super CO server 1132 proxy.
 Because a cache server is typically a proxy server, each Super Module with a Super Cache can serve as a proxy server. Hence the examples of proxy servers are not limited to Super Appliances or Super CO Servers, but include Super CO Concentrators and Super Hosts.
 In one embodiment there is a central proxy stack manager called the Proxy Resolver which manages the proxy stacks in each of the Super Modules in network. By modifying proxy stack lists at the centralized Proxy Resolver location, the proxy stacks for each of the Super Modules in the network can be modified. A preferred method of implementation is for the Artera system to connect to the Proxy Resolver upon startup, or at specific intervals, to retrieve the proxy stacks that the Super Module should be using. This allows proxy definitions for the Super Modules to be updated from a central control.
 In the example of FIG. 12 above, each Super User has two or more primary proxy servers, e.g., Super Appliances, which can be used in a priority order or switched with each user request. If a proxy server times out the next proxy server in the stack is used, this creates a system that is fault tolerant (non-stop). If each time a request is made the next proxy server on the stack is used load balancing can be accomplished. The Super Appliances also can have a proxy stack of two or more Super CO servers for which to use. This Appliance stack can be set up to be used in priority order or switched for each request. If used in priority order the next Proxy is used as a backup, if the priority Proxy should time out. If used alternately it load balances the network between the Proxies. At any time the Proxy Resolver can load a new Proxy list onto the Artera Appliance thereby changing the processing nature of the network.
 A Virtual Private Network (VPN) is private network, such as a corporate intranet, that uses the resources of a public network, such as the Internet. Two typical types of VPNs are site-to-site and remote access. Each type makes use of a VPN gateway, which is a gatekeeper, typically specialized hardware, between a trusted private network and the untrusted public network. The gatekeeper has a “guest” list of who has access to the trusted private network. If a packet is not on the list then there is no access.
FIG. 13 shows examples of a conventional site-to-site VPN 1440 and a conventional remote VPN 1446. For a site-to-site VPN 1440, a first intranet, having PC 1412, PC 1414, and LAN server 1416, is connected by VPN gateway 1420 to the Internet 1530 by digital connection device 1526 and PoP 1514. From internet 1530 the VPN 1440 is connected to a second intranet , having PC 1434, PC 1436, and LAN server 1432, via PoP 1540, modem 1542, and VPN gateway 1430. Hence the first intranet and the second intranet are connected together via the Internet to form a combined intranet. For a remote VPN 1446, a user at a remote PC dials in via modem 1534 to PoP 1532 to access LAN server 1432 via Internet 1530, PoP 1540, modem 1542, and VPN Gateway 1430. The PC will have VPN client software and may have a fixed IP address or a dynamic IP address supplied by a dynamic DNS/URL service, which supplies a URL (uniform resource locator) to be used by the PC. The dynamic DNS/URL service informs the VPN gateway 1430 of the PC's IP address, so that PC has access to LAN server 1432.
 The conventional VPNs as illustrated in FIG. 13 have several limitations. First, special gateway hardware is typically required. And second, a user cannot have access to multiple VPNs. An embodiment of present invention overcomes these problems. Any grouping of Super Module sites can form one or more VPNs. There is a Central Site 1538 (FIG. 16) which has a permission table of which Super Module has access to which other Super Module, i.e., who can access whom.
FIG. 14 shows examples of two virtual private networks (VPNs) of an embodiment of the present invention. Super User 1510 belongs to VPN 1552 and to VPN 1550. Super User 1510 is remotely connected to Super Appliance 1524 via remote VPN 1550, where Super Appliance 1524 is a software gateway executing on LAN serverl4l6. When Super Appliance 1524 and Super Appliance 1544 start up, they send their IP addresses to the permission table at the Central Site 1538. The Super User 1510 dials into PoP 1514 via modem 1512 and the PoP assigns an IP address to the Super User. Next, the Central Site is logged into by Super User 1510 and the Super User 1510 reports its IP address to the Central Site. When Super User 1510 wants to access PC 1412 via Super Appliance 1524, the permission table is checked. Since Super User 1510 has access rights, a tunnel, i.e.,VPN 1550, between the Super User 1510 IP address and the Super Appliance 1524 IP address is established. Super User 1510 also has access to Super User 1536 and Super Appliance 1544 as indicated by the permissions table at the Central Site 1538, hence VPN 1552 is established. Thus a Super User has access to multiple VPNs and to other Super Users.
 In alternative embodiment, Super User 1536 may also be a remote user and may not be logged on, when VPN 1552 is created. When Super User 1536 logs in, it is assigned an IP address and according to the permission table, a three way VPN including, Super User 1536, Super User 1510 and Super Appliance 1544, is established.
 The optimizations described above for the super transport system can be applied across any VPN of embodiments of the present invention, as long as an Super Appliance module is installed on both sides of the VPN. As an example, two Super Modules can be connected using a VPN and all data transfers, whether they are files, email or web pages, use, file transfer multipier and teaming as described above. Specifically, if, for example, there were two modem lines from Super User 1510 to PoP 1514 rather than one, the data transfer from Super User 1510 to Super Appliance 1524 via VPN 1550 would be significantly increased, since from the PoP 1514 to the Super Appliance 1524 there is a fast digital connection.
 Although specific embodiments of the invention have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. The described invention is not restricted to operation within certain specific data processing environments, but is free to operate within a plurality of data processing environments. Additionally, although the invention has been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the invention is not limited to the described series of transactions and steps.
 Further, while the invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the invention. The invention may be implemented only in hardware or only in software or using combinations thereof.
 The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.
FIG. 1 is a block diagram showing a user connection to the Internet of the prior art.
FIG. 2 is a simplified, but expanded, block diagram of FIG. 1.
FIG. 3 is a block diagram of the communication path between a browser and a web server of an embodiment of the present invention.
FIG. 4 is a block diagram of the Super Modules inserted in the conventional system of FIG. 2 of an embodiment of the present invention.
FIG. 5 shows an example of a Super Cache structure of an embodiment of the present invention.
FIG. 6 is a simplified example showing the refreshing process for a Super Cache system of one embodiment of the present invention.
FIG. 7 is a flowchart of an automatic refreshing process of a Super Cache of an embodiment of the present invention.
FIG. 8 is an example of the storing data from multiple users requests and the requesters IP addresses in the cache of receiving Super Module.
FIG. 9 shows an example of data flows for graphics and text or dynamic data between a user and a web server over the Internet of an aspect of the present invention.
FIG. 10 shows an example of connection teaming of an embodiment of the present invention.
FIG. 11 gives examples of the time savings due to file transfer multiplying of an aspect of the present invention.
FIG. 12 is an example of using Proxy Stacks of an embodiment of the present invention.
FIG. 13 shows examples of a conventional site-to-site VPN and a conventional remote VPN.
FIG. 14 shows examples of two virtual private networks (VPNs) of an embodiment of the present invention.
 The following copending, commonly assigned applications are incorporated herein by reference in their entirety: U.S. Utility Application entitled, “System And Method For Increasing the Effective Bandwidth of a Communications Network”, by Michael J. Parrella, Sr., et al., filed Jun. 4, 2002, Attorney Docket No. 20275-0003; and U.S. Utility Application entitled, “System and Method For Modifying a Data Stream Using Element Parsing”, by Michael J. Parrella, Sr., et al., filed Jun. 4, 2002, Attorney Docket No. 20275-0005.
 The invention relates generally to the field of communications, and in particular to the efficient transfer of information over a computer network.
 The Internet has grown considerably in its scope of use over the past decades from a research network between governments and universities to a means of conducting both personal and commercial transactions by both businesses and individuals. The Internet was originally designed to be unstructured so that in the event of a breakdown the probability of completing a communication was high. The method of transferring information is based on a concept similar to sending letters through the mail. A message may be broken up into multiple TCP/IP packets (i.e., letters) and sent to an addressee. Like letters, each packet may take a different path to get to the addressee. While the many small packets over many paths approach provides relatively inexpensive access by a user to, for example, many Web sites, it is considerably slower than a point-to-point connection between a user and a Web site.
FIG. 1 is a block diagram showing a user connection to the Internet of the prior art. In general a user 110 connects to the Internet via a point-of-presence (PoP) 112 traditionally operated by an Internet Service Provider (ISP). The PoP is connected to the ISP's backbone network 114, e.g., ISP1. Multiple ISP backbone networks, e.g., ISP1 and ISP2, are connected together by Network Access Points, e.g., NAP 170, to form the Internet “cloud” 160.
 More specifically, a single user at a personal computer (PC) 120 has several choices to connect to the PoP 112 such as a direct subscriber line (DSL) modem 122, a TV cable modem 124, a standard dial-up modem 126, or a wireless transceiver 128 on, for example, a fixed wireless PC or mobile telephone. The term personal computer or PC is used herein to describe any device with a processor and a memory and is not limited to a traditional desktop PC. At the PoP 112 there will be a corresponding access device for each type of modem (or transceiver) to receive/send the data from/to the user 110. For the DSL modem 122, the PoP 112 has a digital subscriber line access multiplexer (DSLAM) as its access device. For the cable modem 124, the PoP 112 has a cable modem termination system (CTMS) headend as its access device. DSL and cable modem connections allow hundreds of kilo bits per second (Kbps) and are considerably faster than the standard dial up modem 126 whose data is received at the PoP 112 by a dial-up remote access server (RAS) 134. The wireless transceiver 128 could be part of a personal digital assistant (PDA) or mobile telephone and is connected to a wireless transceiver 136, e.g., a base station, at the PoP 112.
 A business user (or a person with a home office) may have a local area network (LAN), e.g., PCs' 140 and 142 connected to LAN server 144 by Ethernet links. The business user may have a T1 (1.544 Mbps) or fractional T1 connection to the PoP 112. The data from the LAN server 144 is sent via a router (not shown) to a digital connection device, e.g., a channel service unit/data service unit (CSU/DSU) 146, which in turn sends the digital data via a T1 (or fractional T1) line 148 to a CSU/DSU at the PoP 112.
 The PoP 112 may include an ISP server 152 to which the DSLAM 130, CTMS Headend 132, RAS 134, wireless transceiver 136, or CSU/DSU 150, is connected. The ISP server 152 may provide user services such as E-mail, Usenet, or Domain Name Service (DNS). Alternatively, the DSLAM 130, CTMS Headend 132, RAS 134, wireless transceiver 136, or CSU/DSU 150 may bypass the ISP server 152 and are connected directly to the router 154 (dashed lines). The server 152 is connected to a router 154 which connects the PoP 112 to ISP1's backbone having, e.g., routers 162, 164, 166, and 168. ISP1's backbone is connected to another ISP's backbone (ISP 2) having, e.g., routers 172, 174, and 176, via NAP 170. ISP2 has an ISP2 server 180 which offers competing user services, such as E-mail and user Web hosting. Connected to the Internet “cloud” 160 are Web servers 182 and 184, which provide on-line content to user 110.
 While the Internet provides the basically functionality to perform commercial transactions for both businesses and individuals, the significant time delay in the transfer of information between, for example, a Web server and a business or individual user is a substantial problem. For example a user at PC 120 wants information from a Web site at Web server 182. There are many “hops” for the data to travel back from Web server 182 to user PC 120. Also because information is being “mailed” back in packets, the packets travel back typically through different paths. These different paths are shared with other users packets and some paths may be slow. Hence there is a significant time delay even if there were sufficient capacity in all the links between Web server 182 and user 120. However, because there are also choke points, i.e., where the traffic exceeds the capacity, there is even further delay.
 Two major choke points are the last and second to last mile. The last mile is from the PoP 112 to the user 110. Local Area Networks having, e.g., LAN Server 144, PC 140 and PC 142 and the core ISP backbone 114 run very fast. Local area networks typically run at 10/100 mega bits per second (Mbps). The core ISP backbones operate at, for example, Optical Carrier (OC) 48, i.e., 2.5 gigabits per second (Gbps) or OC-192, i.e., 10 Gbps. The majority of last mile access is dial up which typically runs at 56 Kbps. Even with a DSL modem of about 512 Kbps downloading graphics may be unpleasantly slow. Thus the last mile between PoP 112 and user 110 is a bottleneck between two large communications pipes.
 The second to last mile is between the ISPs. An ISP with PoP 112 may connect via its backbone 114 to a higher level ISP (not shown) to get regional/national/global coverage. As an increase in bandwidth to the higher level ISP increases the local ISP's costs, the local ISP with, for example PoP 112, may instead reduce the amount of bandwidth available to user 110. The effect is that there is more traffic than link capacity between Web server 182 and PC 120 and hence a significant delay problem. In today's fast pace world this problem is greatly hindering the use of the Internet as a commercial vehicle.
 Therefore there is a need for reducing the user's wait time for information from a communications network such as the Internet.
 The present invention provides a system and method for reducing the time a user needs to wait for information requested from a remote server on a communications network, for example, a Web server on the Internet. In an exemplary embodiment the system is user centric and the goal is to keep all data the user needs as the close to the user as practical. The user's characteristics and usage patterns are used to determine what to cache and for how long, what to pre-fetch, what to refresh, and what to retrieve. In addition, by segmenting information and utilizing parallel communication channels, data transfer across the last mile can be significantly increased.
 An embodiment of the present invention includes a method for caching data for use by a browser on a computer. The method includes storing an item of data in a cache retrieved from a server by the browser; absent any action by the browser, automatically updating the item in the cache; displaying the updated item from the cache on the browser.
 Another embodiment of the present invention includes a method for refreshing first data in a cache of a first computer system from second data in a second computer system, where the first computer system is connected to the second computer system by a communications network. The method includes: when the first computer system is not busy, sending a refresh request for the first data to the second computer system; using the refresh request, locating the second data; when the second data is a newer version of the first data, sending the second data to the first computer system; and replacing the first data by the second data in the cache.
 Yet another embodiment of the present invention includes a system for distributing selected data from a host server across a plurality of caches on a communications network, the communications network. The system includes: a first cache of the plurality of caches connected to the host server and having a first replica of the selected data; a second cache of the plurality of caches connected to the first cache via a Point of Presence access device and connected to a user PC, wherein the second cache has a second replica of the selected data and wherein the second and first replicas are linked together; and a browser executing on the user PC for retrieving the selected data by first using the second replica.
 A further embodiment of the present invention includes a method for a first computer system responding to a user request for data from a second computer system having a cache. The method includes: receiving the user's request for data from the second computer system; retrieving response data corresponding to the user's request; storing a network address for the second computer system with the response data in the cache; and sending the response data to the second computer system.
 Another embodiment of the present invention includes a method for a first computer system responding to a user request for data from a second computer system having a cache. The method includes: receiving the user's request for data from the second computer system; retrieving response data corresponding to the user's request; storing a network address for the second computer system with the response data in the cache; and sending the response data to the second computer system.
 An embodiment of the present invention includes a method for pre-fetching data for a user at a first computer system from a second computer system via a communications network,. The method includes: determining a frequency in user requests sent by the first computer for selected data from the second computer system; and requesting the selected data by the first computer at a value higher than the frequency, such that one item of the selected data is available at the first computer system before a corresponding user request is sent.
 Another embodiment of the present invention includes a method for providing a Virtual Private Network (VPN) between a first computer and a second computer via a public communications network. The method includes: establishing a VPN between the first computer and the second computer by using a centralized permission table comprising the first computer's address and the second computer's address; and when the first computer has a plurality of parallel communication links to the second computer, teaming the plurality of parallel communication links to increase data flow between the first and second computers.
 A further embodiment of the present invention includes a method for adjusting data traffic from a first computer to a second computer, the data traffic needed to support graphics on a computer monitor of the second computer. The method includes: sending the computer monitor's display characteristics including a first number of pixels per inch, to the first computer; evaluating a second number of pixels per inch for a graphic item; when the second number is greater than the first number, creating a modified graphic item from the graphic item with a reduced number of pixels per inch; and sending the modified graphic item to the second computer.
 Another embodiment of the present invention includes a method for selecting a proxy server from a plurality of proxy servers in a proxy stack for a computer. The method includes: setting an order for the plurality of proxy servers in the proxy stack by a central proxy stack manager; and each time a request for a proxy server of the plurality of proxy servers is made by the computer, selecting a proxy server of the plurality next in order in the proxy stack.
 An embodiment of the present invention includes a system for providing web content, comprising dynamic data and static graphics, to a browser executing on a computer. The system includes: a cache for providing a substantial portion of the static graphics to the browser, wherein the cache is connected to the computer by a Local Area Network; and a virtual circuit connection to a Web server for providing the browser with a substantial portion of the dynamic data.
 Another embodiment of the present invention includes a method for load balancing data transferred from a first computer to a second computer via a plurality of communication links between the first and second computers. The method includes: establishing a TCP/IP connection for each communication link of the plurality of communication links; and dividing the data between the plurality of communication links based on factors to significantly reduce transfer time of the data.
 Yet another embodiment of the present invention includes a method for reducing time to transfer a file between a first computer and a second computer via a plurality of communication links. The method includes: sending the file by the first computer using a first link of the plurality of communication links; sending a portion of the file by the first computer using a second link of the plurality of communication links; and the second computer, after receiving all of the portion of the file, but not all of the file, reconstructing the file.
 These and other embodiments, features, aspects and advantages of the invention will become better understood with regard to the following description, appended claims and accompanying drawings.
 This application claims priority from and incorporates by reference in its entirety U.S. Provisional Application Serial No. 60/295,721, titled “System and Method for Improving the Effective Bandwidth of a Communication Device”, by Michael J. Parrella et. al., filed Jun. 4, 2001, U.S. Provisional Application Serial No. 60/295,672, titled “Method and System Providing Compression/Decompression of Communication Data”, by Michael J. Parrella et al., filed Jun. 4, 2001, U.S. Provisional Application Serial No. 60,295,676, titled “System and Method Providing Packaging of Parseable Data Elements in a Network Communication”, by Michael J. Parrella et al., filed Jun. 4, 2001, U.S. Provisional Application Serial No. 60/295,720, titled “Bi-Directional File Transfer Multiplier”, by Michael J. Parrella et al., filed Jun. 4, 2001, U.S. Provisional Application Serial No. 60/295,671, titled “Modification of a Data Stream Using Element Parsing”, by Michael J. Parrella et al., filed Jun. 4, 2001.