Electrical computers and digital processing systems: multicomput – Remote data accessing – Accessing a remote server
Reexamination Certificate
2000-02-04
2003-12-02
Wiley, David (Department: 2143)
Electrical computers and digital processing systems: multicomput
Remote data accessing
Accessing a remote server
C709S217000, C709S203000, C709S228000
Reexamination Certificate
active
06658463
ABSTRACT:
1. BACKGROUND OF THE INVENTION
1.1 Field of the Invention
The present invention relates generally to the distribution of World Wide Web content over a geosynchronous satellite communications network, and in particular, to satellite communications networks having an outbound high-speed, continuous channel carrying packetized data and either a satellite inbound channel or a terrestrial inbound channel, such as a dialup connection to the Internet.
1.2 Description of related Art
1.2.1 Caching HTTP Proxy Servers
The most popular method for distributing multimedia information is the Internet's World Wide Web. The World Wide Web can be considered to be a set of network accessible information resources. In the World Wide Web, many Web Servers and Web Browsers are connected to the Internet via the TCP/IP protocols and the Web Browsers request web pages and graphics and other multimedia content via the Hypertext Transfer Protocol (HTTP).
The World Wide Web is founded on three basic ideas:
1. A global naming scheme for resources—that is, Uniform Resource Locators (URLs).
2. Protocols for accessing named resources—the most common of which is the Hypertext Transfer Protocol (HTTP).
3. Hypertext—the ability to embed links to other resources which is typically done according to the Hypertext Markup Language (HTML).
Web pages are formatted according to the Hypertext Markup Language (HTML) standard which provides for the display of high-quality text (including control over the location, size, color and font for the text), the display of graphics within the page and the “linking” from one page to another, possibly stored on a different web server. Each HTML document, graphic image, video clip or other individual piece of content is identified, that is, addressed, by an Internet address, referred to as a Uniform Resource Locator (URL). In the context of this invention, a “URL” may refer to an address of an individual piece of web content (HTML document, image, sound-clip, video-clip, etc.) or the individual piece of content addressed by the URL. When a distinction is required, the term “URL address” refers to the URL itself while the terms “URL content” or “URL object” refers to the content addressed by the URL.
A web browser may be configured to either access URLs directly from a web server or from an HTTP proxy server. An HTTP proxy server acts as an intermediary between one or more browsers and many web servers. A web browser requests a URL from the proxy server which in turn “gets” the URL from the addressed web server. An HTTP proxy itself may be configured to either access URLs directly from a web server or from another HTTP proxy server. When a proxy server sends a request to another proxy server the proxy server processing the request is referred to as being upstream (that is, closer to the web server). When a proxy server receives a request from another proxy server, the requesting proxy server is referred to as being downstream, that is, farther from the Web Server.
FIG. 1
illustrates a system in which one of a plurality of browsers accesses a web server via upstream and downstream proxy servers with an HTTP GET command. In particular, a plurality of PCs
12
, each including a browser
14
, output a GET command to web server
16
, in order to access the URL “A”. Assuming PC
12
and browser
14
make the first request, the GET command is passed to downstream proxy server
18
. Since this is the first request for URL “A”, the downstream proxy server
18
does not have URL “A” in its cache
20
. As a result, the downstream proxy server
18
also issues a GET URL “A” command to upstream proxy server
22
. Since this is also the first request to upstream proxy server
22
for the URL “A”, the upstream proxy server
22
also does not have URL “A” in its cache
24
. Therefore, the upstream proxy server
22
issues a GET URL “A” command directly the web server
16
. The web server
16
services this request and provides the upstream proxy server
22
with the desired information, which is then stored in the cache
24
. The upstream proxy server
22
passes the desired information to the downstream proxy server
18
, which also stores the desired information in its cache
20
. Finally, the downstream proxy server
18
passes the desired information to the originating requestor's browser
14
at PC
12
, which also stores the desired information in its cache
21
.
Subsequently, PC
12
′, via its browser
14
′, also desires the information at URL “A”. PC
12
′ issues a GET URL “A” command to downstream proxy server
18
. At this time, downstream proxy server
18
has the desired information in its cache
20
and provides the information directly to PC
12
′ without requesting additional information from either the upstream proxy server
22
or the web server
16
. Similarly, if PC
12
″, via its browser
14
″, also desires the information at URL “A”, PC
12
″ issues a GET URL “A” command to downstream proxy server
18
′. However, since downstream proxy server
18
′ does not have the information for URL “A” stored in its cache
20
′, the downstream proxy server
18
′ must access the upstream proxy server
22
and its cache
24
, in order to supply the desired information to PC
12
″. However, the upstream proxy server
22
does not have to access the web server
16
, because the desired information is stored in its cache
24
.
As described above, a caching HTTP proxy server, such as downstream proxy servers
18
,
18
′ and upstream proxy server
22
store (cache) some URLs. Normally, a caching proxy server stores the most frequently accessed URLs. When a web server delivers a URL, it may deliver along with the URL an indication of whether the URL should not be cached and an indication of when the URL was last modified. As described in conjunction with
FIG. 1
, the URLs stored by a caching proxy server are typically URLs obtained on behalf of a browser or downstream proxy server. A caching HTTP proxy server satisfies a request for a URL, when possible, by returning a stored URL. The HTTP protocol also supports a GET IF MODIFIED SINCE request wherein a web server (or a proxy server) either responds with a status code indicating that the URL has not changed or with the URL content if the URL has changed since the requested date and time.
FIG. 2
illustrates a browser executing a GET IF MODIFIED SINCE command from web server
16
. As illustrated in
FIG. 2
, the PC
12
, including browser
14
, has already requested URL “A” once and has URL “A” stored in its cache
21
. PC
12
now wants to know if the information stored at URL “A” has been updated since the time it was last requested. As a result, the browser
14
issues a GET A IF MODIFIED SINCE the last time “A” was obtained. Assuming that URL “A” was obtained at 11:30 a.m. on Jul. 13, 1999, browser
14
issues a GET A IF MODIFIED SINCE Jul. 15, 1999 at 11:30 a.m. request. This request goes to downstream proxy server
18
. If downstream proxy server
18
has received an updated version of URL “A” since Jul. 15, 1999 at 11:30 a.m., downstream proxy server
18
will supply the new URL “A” information to the browser
14
. If not, the downstream proxy server
18
will issues a GET IF MODIFIED SINCE command to upstream proxy server
22
. If upstream proxy server
22
has received an updated URL “A” since Jul. 15, 1999 at 11:30. a.m., upstream proxy server
22
will pass the new URL “A” to the downstream proxy server
18
. If not, the upstream proxy server
22
will issue a GET A IF MODIFIED SINCE command to the web server a. If URL “A” has not changed since Jul. 15, 1999 at 11:30 a.m., web server
16
will issue a NO CHANGE response to the upstream proxy server
22
. In this way, bandwidth and processing time are saved, since if the URL “A” has not been modified since the last request, the entire contents of URL “A” need not be transferred between web browser
14
, downstream proxy server
18
, upstream proxy server
22
, and the web server
16
, only an indicati
Dillon Douglas M.
Gaske T. Paul
Avellino Joseph E.
Hughes Electronics Corporation
Sales Michael
Whelan John T.
Wiley David
LandOfFree
Satellite multicast performance enhancing multicast HTTP... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Satellite multicast performance enhancing multicast HTTP..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Satellite multicast performance enhancing multicast HTTP... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3158526