|Publication number||USRE39017 E1|
|Application number||US 09/927,778|
|Publication date||Mar 14, 2006|
|Filing date||Aug 15, 2001|
|Priority date||Feb 14, 1997|
|Also published as||CA2278300A1, EP1015991A1, US5938737, WO1998036362A1|
|Publication number||09927778, 927778, US RE39017 E1, US RE39017E1, US-E1-RE39017, USRE39017 E1, USRE39017E1|
|Inventors||Joseph Smallcomb, Ray Allen Daniel|
|Original Assignee||Itt Manufacturing Enterprises, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (15), Referenced by (1), Classifications (13), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention relates to interactive information requests over the internet.
To gain access to the internet, a client (user) will typically login into an Internet Service Provider (ISP) via a telephone or ISDN modem. This connection is typically a medium data rate (i.e., 9.6 to 28.8 kbps), symmetrical connection. However, the client is typically searching for information, which leads to asymmetric communications. For example, a client (user) requesting a file download will send a small upstream request (e.g., 200 bytes) but receive a large file (e.g. 200 kbytes) in return from the server. In these types of connection the downstream channel (i.e., return link) is the bottleneck.
The typical volume of downstream data to upstream data ratio is from 10:1 to 20:1. Currently, asymmetrical channel services are being deployed (e.g., satellite broadcast, cable modems, ADSL, etc.) to take advantage of this ratio and reduce this downstream bottleneck. These services typically increase the downstream channel capacity by using a media with wider bandwidth (e.g., co-axial cable), and maintain or allocate a smaller bandwidth connection for the upstream user request channel. In some cases (such as satellite broadcast), an upstream channel path, independent of the downstream channel path, is utilized.
The Internet is a packet switch network, where the defacto protocol standard is TCP/IP. The Internet Protocol (IP) provides the basic addressing scheme for internet routing (where the information goes). Transmission Control Protocol (TCP) is very robust protocol designed for error-free bulk data transfer and error detection and correction. On top of TCP/IP, an additional serial interface, protocol (e.g., PPP or SLIP) is used for connection with an ISP. From the standpoint of upstream channel efficiency, a typical internet request has a high degree of packet overhead to accommodate the layers of protocol, the error correction, and the data coding scheme.
Browsing on the World Wide Web (WWW) (one of the most popular activities on the internet) also leads to inefficient use of the upstream channel. This browsing is based on the HyperText Transfer Protocol (HTTP). Typically, a user sends an HTTP request for a Web Page to a particular server on the internet and the server responds with requested information. This transaction takes several phases (i.e., Connect, Request, Response, Close) to complete. In addition, the requested information from the server is most commonly an HTTP file which references graphical images, audio files, and/or additional text. The browser will then automatically request the additional information (unless the user has manually selected to filter out certain high bandwidth file requests from being made). It is not uncommon for an initial request of a web page to trigger 20 more requests which are required to complete the transaction and build the image seen through the browser.
Although the implementation of asymmetrical internet connections has made internet interaction more efficient, there is yet more compression that can occur to make the upstream channel even more compact.
In this invention, the upstream traffic between the Client and the Upstream Gateway is compressed and reduced with the bulk of the internet communication performed at the Upstream and (in some cases) Downstream Gateway. This allows more users to be placed on multiple access upstream channels and/or reduce the user cost on a charge-by-the-byte upstream channel. This invention exploits the architecture of the Indirect Network Connection that is utilized in an asymmetrical internet connection as well as the characteristic that the upstream channel from the Client to the Upstream Gateway is a point-to-point connection.
This invention utilizes four types of compression to reduce upstream channel traffic so that the ratio of downstream to upstream channel traffic is increased significantly beyond the 20:1 ratio that is now experienced:
(1) Format compression of request packets.
The typical browser request contains ASCII symbols with characters and patterns that are commonly repeated. For example, in the request:
“/” and “.” are the most common characters. Patterns like “http://”, “www”, “.com”, and “.html” are also common. A simple statistical compression or linear predication scheme could reduce the number of bytes required for a request and would be appropriate for this real-time compression application.
Software running at the Client site could operate beneath the browser to compress the ASCII text requests prior to their TCP/IP formatting and the full, uncompressed, request would be regenerated at the Upstream Gateway.
(2) Perform TCP and IP packetizinq at the Upstream Gateway rather than at the Client:
Since the upstream channel between the Client and the Upstream Gateway is a point-to-point link, the packet overhead of TCP and IP are not necessarily required. Software running at the Client site would operate beneath the browser to bypass the TCP/IP packet formation after the initial connection is established. The Upstream Gateway would then take the requests and add the TCP/IP overhead prior to transmission to the Internet.
(3) Keep a User Profile at the Upstream Gateway:
A large database could be implemented at the Upstream Gateway which stores a Client's previous data requests. Software running at the Client site would operate beneath the browser to send a short address reference message to the Upstream Gateway to indicate a previously requested site instead of sending an entire request sequence. The Upstream Gateway, in turn, would look up the short address reference in the database for that Client in order to send out the complete data request to the Internet. This could be implemented with a “Go back “N” requests” scheme or a Bookmark scheme similar to those on a typical browser.
(4) Automatically generate additional HTTP requests:
The fact that a single web page likely requires multiple data requests from the Client is the largest contributor to upstream data traffic. Instead of the Client system sending the automatic subsequent requests for additional data (referenced by the initial HTTP file delivered from the Server), the gateways could be programmed to receive the first request response from a server and automatically make all of the subsequent file requests for the Client. Each of the requested files would then be downloaded to the Client on the downstream channel as they are received. This makes it possible to have only one data request to be sent by the Client on the upstream channel (instead of a multitude) to assemble a web page.
In addition to the higher HTTP level compression, the gateways could also handle the lower HTTP level of connection, request, response, and close messages with the Internet so that the Client would not be required to send all of these separate messages on the upstream channel.
The Upstream and Downstream Gateways could operate in concert for this service, or they could operate independently with one gateway or the other managing the proxy requests.
Software running at the Client site would operate beneath the browser to manage these compression functions. In addition, should the Client wish to filter out the request of certain files (e.g. to speed up their internet session or to reduce downstream bandwidth), the compression management software could send a message to the gateways to indicate this and only the desired files would be automatically requested by the gateways.
The above and other objects, advantages and features of the invention will become more clear when considered with the following description and accompanying drawings, wherein:
The upstream channel traffic from a Client can be significantly reduced, increasing the number of users on a multiple access upstream channel or reducing the required bandwidth for a single user. This is accomplished by:
One or more of these techniques may be used to “compress” data traffic on the upstream request channel.
While the invention has been described in relation to preferred embodiments of the invention, it will be appreciated that other embodiments, adaptations and modifications of the invention will be apparent to those skilled in the art.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5136291 *||Nov 30, 1990||Aug 4, 1992||Unisys Corporation||Transmitting binary data files using electronic mail|
|US5307413 *||Jul 19, 1991||Apr 26, 1994||Process Software Corporation||Method and apparatus for adding data compression and other services in a computer network|
|US5534913 *||Mar 31, 1994||Jul 9, 1996||At&T Corp.||Apparatus and method for integrating downstream data transfer over a cable television channel with upstream data carrier by other media|
|US5535199 *||Sep 6, 1994||Jul 9, 1996||Sun Microsystems, Inc.||TCP/IP header compression X.25 networks|
|US5555377 *||Dec 20, 1993||Sep 10, 1996||International Business Machines Corporation||System for selectively compressing data transferred in network in response to produced first output when network utilization exceeds first threshold and data length over limit|
|US5557749 *||Oct 15, 1992||Sep 17, 1996||Intel Corporation||System for automatically compressing and decompressing data for sender and receiver processes upon determination of a common compression/decompression method understood by both sender and receiver processes|
|US5627829 *||Jun 6, 1995||May 6, 1997||Gleeson; Bryan J.||Method for reducing unnecessary traffic over a computer network|
|US5668737 *||Mar 22, 1995||Sep 16, 1997||Pixel Magic, Inc.||High-speed data processor and coding method|
|US5673322 *||Mar 22, 1996||Sep 30, 1997||Bell Communications Research, Inc.||System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks|
|US5673392 *||Apr 26, 1995||Sep 30, 1997||Murata Mfg. Co., Ltd.||Method of executing communication program in modem apparatus|
|US5732216 *||Oct 2, 1996||Mar 24, 1998||Internet Angles, Inc.||Audio message exchange system|
|US5732219 *||Mar 17, 1995||Mar 24, 1998||Vermeer Technologies, Inc.||Computer system and computer-implemented process for remote editing of computer files|
|US5742773 *||Apr 18, 1996||Apr 21, 1998||Microsoft Corporation||Method and system for audio compression negotiation for multiple channels|
|US5867112 *||May 14, 1997||Feb 2, 1999||Kost; James F.||Software method of compressing text and graphic images for storage on computer memory|
|US6115384 *||Jun 20, 1996||Sep 5, 2000||Fourelle Systems, Inc||Gateway architecture for data communication bandwidth-constrained and charge-by-use networks|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US20090231998 *||Mar 17, 2008||Sep 17, 2009||Microsoft Corporation||Selective filtering of network traffic requests|
|U.S. Classification||709/247, 370/352, 709/217|
|International Classification||G06F15/16, H04L29/06, H03M7/30, G06F13/00|
|Cooperative Classification||H04L69/04, H03M7/30, H04L29/06|
|European Classification||H04L29/06C5, H04L29/06, H03M7/30|
|Feb 20, 2007||FPAY||Fee payment|
Year of fee payment: 8
|Feb 17, 2011||FPAY||Fee payment|
Year of fee payment: 12
|Apr 3, 2013||AS||Assignment|
Owner name: RPX CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EXELIS INC.;REEL/FRAME:030146/0905
Effective date: 20130322