US 8,281,035 B2Grant

Optimized network resource location

Issue Date:2012-10-02

•36 Claims

•7 Drawing Sheets

Abstract

A method for delivering resources in a distributed computing environment, wherein at least a first resource and a second resource are associated with a content provider, and wherein the first resource references the second resource via a first uniform resource locator (URL), the first URL having a first domain name that resolves to a server associated with a domain of the content provider. The second resource is associated with a domain name that resolves to a content delivery network (CDN) formed by a plurality of repeater servers. The domain of the CDN may be distinct from the domain of the content provider. Responsive to a request that causes the first resource to be served to a client from an origin server associated with the content provider's domain, the second domain name in the second URL is resolved to identify a repeater server in the CDN's domain from which to serve the second resource to the client. If a copy of the second resource is already replicated on the identified repeater server, then the copy of the second resource is served to the client from the identified repeater server; otherwise, the second resource is replicated on the identified repeater server and the copy of the second resource is served to the client from the identified repeater server.

Metadata

Assignee

Level 3 Communications, LLC

Inventors

David A. Farber
Richard E. Greer
Andrew D. Swart
James A. Balter

Application Information

Application Number:US 11/441,253

Filing Date:2006-05-26

Priority Date:1998-02-10

Art Unit:2442

Classifications

IPC:

G06F15/16G06F15/173

Patent Drawings (7 sheets)

Description

[0001] This application is a continuation of application Ser. No. 11/065,412 filed Feb. 23, 2005, which is a continuation of application Ser. No. 09/612,598 filed Jul. 7, 2000, now abandoned, which is a divisional of application Ser. No. 09/021,506 filed Feb. 10, 1998, now U.S. Pat. No. 6,185,598.

Field of the Invention

[0002] This invention relates to replication of resources in computer networks.

Background of the Invention

[0003] The advent of global computer networks, such as the Internet, have led to entirely new and different ways to obtain information. A user of the Internet can now access information from anywhere in the world, with no regard for the actual location of either the user or the information. A user can obtain information simply by knowing a network address for the information and providing that address to an appropriate application program such as a network browser.

[0004] The rapid growth in popularity of the Internet has imposed a heavy traffic burden on the entire network. Solutions to problems of demand (e.g., better accessibility and faster communication links) only increase the strain on the supply. Internet Web sites (referred to here as “publishers”) must handle ever-increasing bandwidth needs, accommodate dynamic changes in load, and improve performance for distant browsing clients, especially those overseas. The adoption of content-rich applications, such as live audio and video, has further exacerbated the problem.

[0005] To address basic bandwidth growth needs, a Web publisher typically subscribes to additional bandwidth from an Internet service provider (ISP), whether in the form of larger or additional “pipes” or channels from the ISP to the publisher's premises, or in the form of large bandwidth commitments in an ISP's remote hosting server collection. These increments are not always as fine-grained as the publisher needs, and quite often lead times can cause the publisher's Web site capacity to lag behind demand.

[0006] To address more serious bandwidth growth problems, publishers may develop more complex and costly custom solutions. The solution to the most common need, increasing capacity, is generally based on replication of hardware resources and site content (known as mirroring), and duplication of bandwidth resources. These solutions, however, are difficult and expensive to deploy and operate. As a result, only the largest publishers can afford them, since only those publishers can amortize the costs over many customers (and Web site hits).

[0007] A number of solutions have been developed to advance replication and mirroring. In general, these technologies are designed for use by a single Web site and do not include features that allow their components to be shared by many Web sites simultaneously.

[0008] Some solution mechanisms offer replication software that helps keep mirrored servers up-to-date. These mechanisms generally operate by making a complete copy of a file system. One such system operates by transparently keeping multiple copies of a file system in synch. Another system provides mechanisms for explicitly and regularly copying files that have changed. Database systems are particularly difficult to replicate, as they are continually changing. Several mechanisms allow for replication of databases, although there are no standard approaches for accomplishing it. Several companies offering proxy caches describe them as replication tools. However, proxy caches differ because they are operated on behalf of clients rather than publishers.

[0009] Once a Web site is served by multiple servers, a challenge is to ensure that the load is appropriately distributed or balanced among those servers. Domain name-server-based round-robin address resolution causes different clients to be directed to different mirrors.

[0010] Another solution, load balancing, takes into account the load at each server (measured in a variety of ways) to select which server should handle a particular request.

[0011] Load balancers use a variety of techniques to route the request to the appropriate server. Most of those load-balancing techniques require that each server be an exact replica of the primary Web site. Load balancers do not take into account the “network distance” between the client and candidate mirror servers.

[0012] Assuming that client protocols cannot easily change, there are two major problems in the deployment of replicated resources. The first is how to select which copy of the resource to use. That is, when a request for a resource is made to a single server, how should the choice of a replica of the server (or of that data) be made. We call this problem the “rendezvous problem”. There are a number of ways to get clients to rendezvous at distant mirror servers. These technologies, like load balancers, must route a request to an appropriate server, but unlike load balancers, they take network performance and topology into account in making the determination.

[0013] A number of companies offer products which improve network performance by prioritizing and filtering network traffic.

[0014] Proxy caches provide a way for client aggregators to reduce network resource consumption by storing copies of popular resources close to the end users. A client aggregator is an Internet service provider or other organization that brings a large number of clients operating browsers to the Internet. Client aggregators may use proxy caches to reduce the bandwidth required to serve web content to these browsers. However, traditional proxy caches are operated on behalf of Web clients rather than Web publishers.

[0015] Proxy caches store the most popular resources from all publishers, which means they must be very large to achieve reasonable cache efficiency. (The efficiency of a cache is defined as the number of requests for resources which are already cached divided by the total number of requests.)

[0016] Proxy caches depend on cache control hints delivered with resources to determine when the resources should be replaced. These hints are predictive, and are necessarily often incorrect, so proxy caches frequently serve stale data. In many cases, proxy cache operators instruct their proxy to ignore hints in order to make the cache more efficient, even though this causes it to more frequently serve stale data.

[0017] Proxy caches hide the activity of clients from publishers. Once a resource is cached, the publisher has no way of knowing how often it was accessed from the cache.

Summary of the Invention

[0018] This invention provides a way for servers in a computer network to off-load their processing of requests for selected resources by determining a different server (a “repeater”) to process those requests. The selection of the repeater can be made dynamically, based on information about possible repeaters.

[0019] If a requested resource contains references to other resources, some or all of these references can be replaced by references to repeaters.

[0020] Accordingly, in one aspect, this invention is a method of processing resource requests in a computer network. First a client makes a request for a particular resource from an origin server, the request including a resource identifier for the particular resource, the resource identifier sometimes including an indication of the origin server. Requests arriving at the origin server do not always include an indication of the origin server; since they are sent to the origin server, they do not need to name it. A mechanism referred to as a reflector, co-located with the origin server, intercepts the request from the client to the origin server and decides whether to reflect the request or to handle it locally. If the reflector decides to handle the request locally, it forwards it to the origin server, otherwise it selects a “best” repeater to process the request. If the request is reflected, the client is provided with a modified resource identifier designating the repeater.

[0021] The client gets the modified resource identifier from the reflector and makes a request for the particular resource from the repeater designated in the modified resource identifier.

[0022] When the repeater gets the client's request, it responds by returning the requested resource to the client. If the repeater has a local copy of the resource then it returns that copy, otherwise it forwards the request to the origin server to get the resource, and saves a local copy of the resource in order to serve subsequent requests.

[0023] The selection by the reflector of an appropriate repeater to handle the request can be done in a number of ways. In the preferred embodiment, it is done by first pre-partitioning the network into “cost groups” and then determining which cost group the client is in. Next, from a plurality of repeaters in the network, a set of repeaters is selected, the members of the set having a low cost relative to the cost group which the client is in. In order to determine the lowest cost, a table is maintained and regularly updated to define the cost between each group and each repeater. Then one member of the set is selected, preferably randomly, as the best repeater.

[0024] If the particular requested resource itself can contain identifiers of other resources, then the resource may be rewritten (before being provided to the client). In particular, the resource is rewritten to replace at least some of the resource identifiers contained therein with modified resource identifiers designating a repeater instead of the origin server. As a consequence of this rewriting process, when the client requests other resources based on identifiers in the particular requested resource, the client will make those requests directly to the selected repeater, bypassing the reflector and origin server entirely.

[0025] Resource rewriting must be performed by reflectors. It may also be performed by repeaters, in the situation where repeaters “peer” with one another and make copies of resources which include rewritten resource identifiers that designate a repeater.

[0026] In a preferred embodiment, the network is the Internet and the resource identifier is a uniform resource locator (URL) for designating resources on the Internet, and the modified resource identifier is a URL designating the repeater and indicating the origin server (as described in step B3 below), and the modified resource identifier is provided to the client using a REDIRECT message. Note, only when the reflector is “reflecting” a request is the modified resource identifier provided using a REDIRECT message.

[0027] In another aspect, this invention is a computer network comprising a plurality of origin servers, at least some of the origin servers having reflectors associated therewith, and a plurality of repeaters.

Brief Description of the Drawings

[0028] The above and other objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which the reference characters refer to like parts throughout and in which:

[0029] FIG. 1 depicts a portion of a network environment according to the present invention; and

[0030] FIGS. 2-6 are flow charts of the operation of the present invention.

Detailed Description of the Presently Preferred Exemplary Embodiments

[0031] Overview

[0032] FIG. 1 shows a portion of a network environment 100 according to the present invention, wherein a mechanism (reflector 108, described in detail below) at a server (herein origin server 102) maintains and keeps track of a number of partially replicated servers or repeaters 104a, 104b, and 104c. Each repeater 104a, 104b, and 104c replicates some or all of the information available on the origin server 102 as well as information available on other origin servers in the network 100. Reflector 108 is connected to a particular repeater known as its “contact” repeater (“Repeater B” 104b in the system depicted in FIG. 1). Preferably each reflector maintains a connection with a single repeater known as its contact, and each repeater maintains a connection with a special repeater known as its master repeater (e.g., repeater 104m for repeaters 104a, 104b and 104c in FIG. 1).

[0033] Thus, a repeater can be considered as a dedicated proxy server that maintains a partial or sparse mirror of the origin server 102, by implementing a distributed coherent cache of the origin server. A repeater may maintain a (partial) mirror of more than one origin server. In some embodiments, the network 100 is the Internet and repeaters mirror selected resources provided by origin servers in response to clients' HTTP (hypertext transfer protocol) and FTP (file transfer protocol) requests.

[0034] A client 106 connects, via the network 100, to origin server 102 and possibly to one or more repeaters 104a etc.

[0035] Origin server 102 is a server at which resources originate. More generally, the origin server 102 is any process or collection of processes that provide resources in response to requests from a client 106. Origin server 102 can be any off-the-shelf Web server. In a preferred embodiment, origin server 102 is typically a Web server such as the Apache server or Netscape Communications Corporation's Enterprise™ server.

[0036] Client 106 is a processor requesting resources from origin server 102 on behalf of an end user. The client 106 is typically a user agent (e.g., a Web browser such as Netscape Communications Corporation's Navigator™) or a proxy for a user agent. Components other than the reflector 108 and the repeaters 104a, 104b, etc., may be implemented using commonly available software programs. In particular, this invention works with any HTTP client (e.g., a Web browser), proxy cache, and Web server. In addition, the reflector 108 might be fully integrated into the data server 112 (for instance, in a Web Server). These components might be loosely integrated based on the use of extension mechanisms (such as so-called add-in modules) or tightly integrated by modifying the service component specifically to support the repeaters.

[0037] Resources originating at the origin server 102 may be static or dynamic. That is, the resources may be fixed or they may be created by the origin server 102 specifically in response to a request Note that the terms “static” and “dynamic” are relative, since a static resource may change at some regular, albeit long, interval.

[0038] Resource requests from the client 106 to the origin server 102 are intercepted by reflector 108 which for a given request either forwards the request on to the origin server 102 or conditionally reflects it to some repeater 104a, 104b, etc. in the network 100. That is, depending on the nature of the request by the client 106 to the origin server 102, the reflector 108 either serves the request locally (at the origin server 102), or selects one of the repeaters (preferably the best repeater for the job) and reflects the request to the selected repeater. In other words, the reflector 108 causes requests for resources from origin server 102, made by client 106, to be either served locally by the origin server 102 or transparently reflected to the best repeater 104a, 104b, etc. The notion of a best repeater and the manner in which the best repeater is selected are described in detail below.

[0039] Repeaters 104a, 104b, etc. are intermediate processors used to service client requests thereby improving performance and reducing costs in the manner described herein. Within repeaters 104a, 104b, etc., are any processes or collections of processes that deliver resources to the client 106 on behalf of the origin server 102. A repeater may include a repeater cache 110, used to avoid unnecessary transactions with the origin server 102.

[0040] The reflector 108 is a mechanism, preferably a software program, that intercepts requests that would normally be sent directly to the origin server 102. While shown in the drawings as separate components, the reflector 108 and the origin server 102 are typically co-located, e.g., on a particular system such as data server 112. (As discussed below, the reflector 108 may even be a “plug in” module that becomes part of the origin server 102.

[0041] FIG. 1 shows only a part of a network 100 according to this invention. A complete operating network consists of any number of clients, repeaters, reflectors, and origin servers. Reflectors communicate with the repeater network, and repeaters in the network communicate with one another.

[0042] Uniform Resource Locators

[0043] Each location in a computer network has an address which can generally be specified as a series of names or numbers. In order to access information, an address for that information must be known. For example, on the World Wide Web (“the Web”) which is a subset of the Internet, the manner in which information address locations are provided has been standardized into Uniform Resource Locators (URLs). URLs specify the location of resources (information, data files, etc.) on the network.

[0044] The notion of URLs becomes even more useful when hypertext documents are used. A hypertext document is one which includes, within the document itself, links (pointers or references) to the document itself or to other documents. For example, in an on-line legal research system, each case may be presented as a hypertext document. When other cases are cited, links to those cases can be provided. In this way, when a person is reading a case, they can follow cite links to read the appropriate parts of cited cases.

[0045] In the case of the Internet in general and the World Wide Web specifically, documents can be created using a standardized form known as the Hypertext Markup Language (HTML). In HTML, a document consists of data (text, images, sounds, and the like), including links to other sections of the same document or to other documents. The links are generally provided as URLs, and can be in relative or absolute form. Relative URLs simply omit the parts of the URL which are the same as for the document including the link, such as the address of the document (when linking to the same document), etc. In general, a browser program will fill in missing parts of a URL using the corresponding parts from the current document, thereby forming a fully formed URL including a fully qualified domain name, etc.

[0046] A hypertext document may contain any number of links to other documents, and each of those other documents may be on a different server in a different part of the world. For example, a document may contain links to documents in Russia, Africa, China and Australia. A user viewing that document at a particular client can follow any of the links transparently (i.e., without knowing where the document being linked to actually resides). Accordingly, the cost (in terms of time or money or resource allocation) of following one link versus another may be quite significant.

[0047] URLs generally have the following form (defined in detail in T. Berners-Lee et al, Uniform Resource Locators (URL), Network Working Group, Request for Comments: 1738, Category: Standards Track, December 1994, located at “http://ds.internic.net/rfc/rfc1738.txt”, which is hereby incorporated herein by reference):

[0048] scheme://host[:port]/url-path

[0049] where “scheme” can be a symbol such as “file” (for a file on the local system), “ftp” (for a file on an anonymous FTP file server), “http” (for a file on a file on a Web server), and “telnet” (for a connection to a Telnet-based service). Other schemes, can also be used and new schemes are added every now and then. The port number is optional, the system substituting a default port number (depending on the scheme) if none is provided. The “host” field maps to a particular network address for a particular computer. The “url-path” is relative to the computer specified in the “host” field. A url-path is typically, but not necessarily, the pathname of a file in a web server directory.

[0050] For example, the following is a URL identifying a file “F” in the path “A/B/C” on a computer at “www.uspto.gov”:

[0051] http://www.uspto.gov/A/B/C/F

[0052] In order to access the file “F” (the resource) specified by the above URL, a program (e.g., a browser) running on a user's computer (i.e., a client computer) would have to first locate the computer (i.e., a server computer) specified by the host name. I.e., the program would have to locate the server “www.uspto.gov”. To do this, it would access a Domain Name Server (DNS), providing the DNS with the host name (“www.uspto.gov”). The DNS acts as a kind of centralized directory for resolving addresses from names. If the DNS determines that there is a (remote server) computer corresponding to the name “www.uspto.gov”, it will provide the program with an actual computer network address for that server computer. On the Internet this is called an Internet Protocol (or IP) address and it has the form “123.345.456.678”. The program on the user's (client) computer would then use the actual address to access the remote (server) computer.

[0053] The program opens a connection to the HTTP server (Web server) on the remote computer “www.uspto.gov” and uses the connection to send a request message to the remote computer (using the HTTP scheme). The message is typically an HTTP GET request which includes the url-path of the requested resource, “A/B/C/F”. The HTTP server receives the request and uses it to access the resource specified by the url-path “A/B/C/F”. The server returns the resource over the same connection.

[0054] Thus, conventionally HTTP client requests for Web resources at an origin server 102 are processed as follows (see FIG. 2) This is a description of the process when no reflector 108 is installed.):

- [0055] A1. A browser (e.g., Netscape's Navigator) at the client receives a resource identifier (i.e., a URL) from a user.
- [0056] A2. The browser extracts the host (origin server) name from the resource identifier, and uses a domain name server (DNS) to look up the network (IP) address of the corresponding server. The browser also extracts a port number, if one is present, or uses a default port number (the default port number for http requests is 80).
- [0057] A3. The browser uses the server's network address and port number to establish a connection between the client 106 and the host or origin server 102.
- [0058] A4. The client 106 then sends a (GET) request over the connection identifying the requested resource.
- [0059] A5. The origin server 102 receives the request and
- [0060] A6. locates or composes the corresponding resource.
- [0061] A7. The origin server 102 then sends back to the client 106 a reply containing the requested resource (or some form of error indicator if the resource is unavailable). The reply is sent to the client over the same connection as that on which the request was received from the client
- [0062] A8. The client 106 receives the reply from the origin server 102.

[0063] There are many variations of this basic model. For example, in one variation, instead of providing the client with the resource, the origin server can tell the client to re-request the resource by another name. To do so, in A7 the server 102 sends back to the client 106 a reply called a “REDIRECT” which contains a new URL indicating the other name. The client 106 then repeats the entire sequence, normally without any user intervention, this time requesting the resource identified by the new URL.

[0064] System Operation

[0065] In this invention reflector 108 effectively takes the place of an ordinary Web server or origin server 102. The reflector 108 does this by taking over the origin server's IP address and port number. In this way, when a client tries to connect to the origin server 102, it will actually connect to the reflector 108. The original Web server (or origin server 102) must then accept requests at a different network (IP) address, or at the same IP address but on a different port number. Thus, using this invention, the server referred to in A3-A7 above is actually a reflector 108.

[0066] Note that it is also possible to leave the origin server's network address as it is and to let the reflector run at a different address or on a different port. In this way the reflector does not intercept requests sent to the origin server, but can still be sent requests addressed specifically to the reflector. Thus the system can be tested and configured without interrupting its normal operation.

[0067] The reflector 108 supports the processing as follows (see FIG. 3):

[0068] upon receipt of a request,

- [0069] B1 The reflector 108 analyzes the request to determine whether or not to reflect the request. To do this, first the reflector determines whether the sender (client 106) is a browser or a repeater. Requests issued by repeaters must be served locally by the origin server 102. This determination can be made by looking up the network (IP) address of the sender in a list of known repeater network (IP) addresses. Alternatively, this determination could be made by attaching information to a request to indicate that the request is from a specific repeater, or repeaters can request resources from a special port other than the one used for ordinary clients.
- [0070] B2 If the request is not from a repeater, the reflector looks up the requested resource in a table (called the “rule base”) to determine whether the resource requested is “repeatable”. Based on this determination, the reflector either reflects the request (B3, described below) or serves the request locally (B4, described below).
  - [0071] The rule base is a list of regular expressions and associated attributes. (Regular expressions are well-known in the field of computer science. A small bibliography of their use is found in Aho, et al., “Compilers, Principles, techniques and tools”, Addison-Wesley, 1986, pp. 157-158.) The resource identifier (URL) for a given request is looked up in the rule base by matching it sequentially with each regular expression. The first match identifies the attributes for the resource, namely repeatable or local. If there is no match in the rule base, a default attribute is used. Each reflector has its own rule base, which is manually configured by the reflector operator.
- [0072] B3. To reflect a request, (to serve a request locally go to B4), as shown in FIG. 4, the reflector determines (B3-1) the best repeater to reflect the request to, as described in detail below. The reflector then creates (B3-2) a new resource identifier (URL) (using the requested URL and the best repeater) that identifies the same resource at the selected repeater.
  - [0073] It is necessary that the reflection step create a single URL containing the URL of the original resource, as well as the identity of the selected repeater. A special form of URL is created to provide this information. This is done by creating a new URL as follows:
- [0074] D1. Given a repeater name, scheme, origin server name and path, create a new URL. If the scheme is “http”, the preferred embodiment uses the following format:
  - [0075] http://<repeater>/<server>/<path>
- [0076] If the form used is other than “http”, the preferred embodiment uses the following format:
- [0077] http://<repeater>/<server>@proxy=<scheme>@/<path>
- [0078] The reflector can also attach a MIME type to the request, to cause the repeater to provide that MIME type with the result. This is useful because many protocols (such as FTP) do not provide a way to attach a MIME type to a resource. The format is
- [0079] http://<repeater>/<server>@proxy=<scheme>:<type>@/<path>
- [0080] This URL is interpreted when received by the repeater.
  - [0081] The reflector then sends (B3-3) a REDIRECT reply containing this new URL to the requesting client. The HTTP REDIRECT command allows the reflector to send the browser a single URL to retry the request.
- [0082] B4. To serve a request locally, the request is sent by the reflector to (“forwarded to”) the origin server 102. In this mode, the reflector acts as a reverse proxy server. The origin server 102 processes the request in the normal manner (A5-A7). The reflector then obtains the origin server's reply to the request which it inspects to determine if the requested resource is an HTML document, i.e., whether the requested resource is one which itself contains resource identifiers.
- [0083] B5. If the resource is an HTML document then the reflector rewrites the HTML document by modifying resource identifiers (URLs) within it, as described below. The resource, possibly as modified by rewriting, is then returned in a reply to the requesting client 106.
  - [0084] If the requesting client is a repeater, the reflector may temporarily disable any cache-control modifiers which the origin server attached to the reply. These disabled cache-control modifiers are later re-enabled when the content is served from the repeater. This mechanism makes it possible for the origin server to prevent resources from being cached at normal proxy caches, without affecting the behavior of the cache at the repeater.
- [0085] B6. Whether the request is reflected or handled locally, details about the transaction, such as the current time, the address of the requester, the URL requested, and the type of response generated, are written by the reflector to a local log file.

[0086] By using a rule base (B2), it is possible to selectively reflect resources. There are a number of reasons that certain particular resources cannot be effectively repeated (and therefore should not be reflected), for instance:

- [0087] the resource is composed uniquely for each request;
- [0088] the resource relies on a so-called cookie (browsers will not send cookies to repeaters with different domain names);
- [0089] the resource is actually a program (such as a Java applet) that will run on the client and that wishes to connect to a service Java requires that the service be running on the same machine that provided the applet).

[0090] In addition, the reflector 108 can be configured so that requests from certain network addresses (e.g., requests from clients on the same local area network as the reflector itself) are never reflected. Also, the reflector may choose not to reflect requests because the reflector is exceeding its committed aggregate information rate, as described below.

[0091] A request which is reflected is automatically mirrored at the repeater when the repeater receives and processes the request.

[0092] The combination of the reflection process described here and the caching process described below effectively creates a system in which repeatable resources are migrated to and mirrored at the selected reflector, while non-repeatable resources are not mirrored.

[0093] Alternate Approach

[0094] Placing the origin server name in the reflected URL is generally a good strategy, but it may be considered undesirable for aesthetic or (in the case, e.g., of cookies) certain technical reasons.

[0095] It is possible to avoid the need for placing both the repeater name and the server name in the URL. Instead, a “family” of names may be created for a given origin server, each name identifying one of the repeaters used by that server.

[0096] For instance, if www.example.com is the origin server, names for three repeaters might be created:

[0097] wr1.example.com

[0098] wr2.example.com

[0099] wr3.example.com

[0100] The name “wr1.example.com” would be an alias for repeater 1, which might also be known by other names such as “wr1.anotherExample.com” and “wr1.example.edu”.

[0101] If the repeater can determine by which name it was addressed, it can use this information (along with a table that associates repeater alias names with origin server names) to determine which origin server is being addressed. For instance, if repeater 1 is addressed as wr1.example.com, then the origin server is “www.example.com”; if it is addressed as “wr1.anotherExample.com”, then the origin server is “www.anotherExample.com”.

[0102] The repeater can use two mechanisms to determine by which alias it is addressed:

- [0103] 1. Each alias can be associated with a different IP address. Unfortunately, this solution does not scale well, as IP addresses are currently scarce, and the number of IP addresses required grows as the product of origin servers and repeaters.
- [0104] 2. The repeater can attempt to determine the alias name used by inspecting the “host:” tag in the HTTP header of the request. Unfortunately, some old browsers still in use do not attach the “host:” tag to a request. Reflectors would need to identify such browsers (the browser identity is a part of each request) and avoid this form of reflection.

[0105] How a Repeater Handles a Request

[0106] When a browser receives a REDIRECT response (as produced in B3), it reissues a request for the resource using the new resource identifier (URL) (A1-A5). Because the new identifier refers to a repeater instead of the origin server, the browser now sends a request for the resource to the repeater which processes a request as follows, with reference to FIG. 5:

- [0107] C1. First the repeater analyzes the request to determine the network address of the requesting client and the path of the resource requested. Included in the path is an origin server name (as described above with reference to B3).
- [0108] C2. The repeater uses an internal table to verify that the origin server belongs to a known “subscriber”. A subscriber is an entity (e.g., a company) that publishes resources (e.g., files) via one or more origin servers. When the entity subscribes, it is permitted to utilize the repeater network. The subscriber tables described below include the information that is used to link reflectors to subscribers.
  - [0109] If the request is not for a resource from a known subscriber, the request is rejected. To reject a request, the repeater returns a reply indicating that the requested resource does not exist.
- [0110] C3. The repeater then determines whether the requested resource is cached locally. If the requested resource is in the repeater's cache it is retrieved. On the other hand, if a valid copy of the requested resource is not in the repeater's cache, the repeater modifies the incoming URL, creating a request that it issues directly to the originating reflector which processes it (as in B1-B6). Because this request to the originating reflector is from a repeater, the reflector always returns the requested resource rather than reflecting the request. (Recall that reflectors always handle requests from repeaters locally.) If the repeater obtained the resource from the origin server, the repeater then caches the resource locally.
  - [0111] If a resource is not cached locally, the cache can query its “peer caches” to see if one of them contains the resource, before or at the same time as requesting the resource from the reflector/origin server. If a peer cache responds positively in a limited period of time (preferably a small fraction of a second), the resource will be retrieved from the peer cache.
- [0112] C4. The repeater then constructs a reply including the requested resource (which was retrieved from the cache or from the origin server) and sends that reply to the requesting client.
- [0113] C5. Details about the transaction, such as the associated reflector, the current time, the address of the requester, the URL requested, and the type of response generated, are written to a local log file at the repeater.

[0114] Note that the bottom row of FIG. 2 refers to an origin server, or a reflector, or a repeater, depending on what the URL in step A1 identifies.

[0115] Selecting the Best Repeater

[0116] If the reflector 108 determines that it will reflect the request, it must then select the best repeater to handle that request (as referred to in step B3-1). This selection is performed by the Best Repeater Selector (BRS) mechanism described here.

[0117] The goal of the BRS is to select, quickly and heuristically, an appropriate repeater for a given client given only the network address of the client. An appropriate repeater is one which is not too heavily loaded and which is not too far from the client in terms of some measure of network distance. The mechanism used here relies on specific, compact, pre-computed data to make a fast decision. Other, dynamic solutions can also be used to select an appropriate repeater.

[0118] The BRS relies on three pre-computed tables, namely the Group Reduction Table, the Link Cost Table, and the Load Table. These three tables (described below) are computed off-line and downloaded to each reflector by its contact in the repeater network.

[0119] The Group Reduction Table places every network address into a group, with the goal that addresses in a group share relative costs, so that they would have the same best repeater under varying conditions (i.e., the BRS is invariant over the members of the group).

[0120] The Link Cost Table is a two dimensional matrix which specifies the current cost between each repeater and each group. Initially, the link cost between a repeater and a group is defined as the “normalized link cost” between the repeater and the group, as defined below. Over time, the table will be updated with measurements which more accurately reflect the relative cost of transmitting a file between the repeater and a member of the group. The format of the Link Cost Table is <Group ID><Group ID><link cost>, where the Group ID's are given as AS numbers.

[0121] The Load Table is a one dimensional table which identifies the current load at each repeater. Because repeaters may have different capacities, the load is a value that represents the ability of a given repeater to accept additional work. Each repeater sends its current load to a central master repeater at regular intervals, preferably at least approximately once a minute. The master repeater broadcasts the Load Table to each reflector in the network, via the contact repeater.

[0122] A reflector is provided entries in the Load Table only for repeaters which it is assigned to use. The assignment of repeaters to reflectors is performed centrally by a repeater network operator at the master repeater. This assignment makes it possible to modify the service level of a given reflector. For instance, a very active reflector may use many repeaters, whereas a relatively inactive reflector may use few repeaters.

[0123] Tables may also be configured to provide selective repeater service to subscribers in other ways, e.g., for their clients in specific geographic regions, such as Europe or Asia.

[0124] Measuring Load

[0125] In the presently preferred embodiments, repeater load is measured in two dimensions, namely

[0126] 1. requests received by the repeater per time interval (RRPT), and

[0127] 2. bytes sent by the repeater per time interval (BSPT).

[0128] For each of these dimensions, a maximum capacity setting is set. The maximum capacity indicates the point at which the repeater is considered to be fully loaded. A higher RRPT capacity generally indicates a faster processor, whereas a higher BSPT capacity generally indicates a wider network pipe. This form of load measurement assumes that a given server is dedicated to the task of repeating.

[0129] Each repeater regularly calculates its current RRPT and BSPT, by accumulating the number of requests received and bytes sent over a short time interval. These measurements are used to determine the repeater's load in each of these dimensions. If a repeater's load exceeds its configured capacity, an alarm message is sent to the repeater network administrator.

[0130] The two current load components are combined into a single value indicating overall current load. Similarly, the two maximum capacity components are combined into a single value indicating overall maximum capacity. The components are combined as follows:
current-load=B×current RRPT+(1−B)×current BSPT
max-load=B×max RRPT+(1−B)×max BSPT

[0131] The factor B, a value between 0 and 1, allows the relative weights of RRPT and BSPT to be adjusted, which favors consideration of either processing power or bandwidth.

[0132] The overall current load and overall maximum capacity values are periodically sent from each repeater to the master repeater, where they are aggregated in the Load Table, a table summarizing the overall load for all repeaters. Changes in the Load Table are distributed automatically to each reflector.

[0133] While the preferred embodiment uses a two-dimensional measure of repeater load, any other measure of load can be used.

[0134] Combining Link Costs and Load

[0135] The BRS computes the cost of servicing a given client from each eligible repeater. The cost is computed by combining the available capacity of the candidate repeater with the cost of the link between that repeater and the client. The link cost is computed by simply looking it up in the Link Cost table.

[0136] The cost is determined using the following formula:
threshold=K*max-load
capacity=max(max-load−current-load, e)
capacity=min(capacity, threshold)
cost=link-cost*threshold/capacity

[0137] In this formula, e is a very small number (epsilon) and K is a tuning factor initial set to 0.5. This formula causes the cost to a given repeater to be increased, at a rate defined by K if its capacity falls below a configurable threshold.

[0138] Given the cost of each candidate repeater, the BRS selects all repeaters within a delta factor of the best score. From this set, the result is selected at random.

[0139] The delta factor prevents the BRS from repeatedly selecting a single repeater when scores are similar. It is generally required because available information about load and link costs loses accuracy over time. This factor is tunable.

[0140] Best Repeater Selector (BRS)

[0141] The BRS operates as follows, with reference to FIG. 6:

[0142] Given a client network address and the three tables described above:

- [0143] E1. Determine which group the client is in using the Group Reduction Table.
- [0144] E2. For each repeater in the Link Cost Table and Load Table, determine that repeater's combined cost as follows:
  - [0145] E2a. Determine the maximum and current load on the repeater (using the Load Table).
  - [0146] E2b. Determine the link cost between the repeater and the client's group (using the Link Cost Table).
  - [0147] E2c. Determine the combined cost as described above.
- [0148] E3. Select a small set of repeaters with the lowest cost.
- [0149] E4. Select a random member from the set.

[0150] Preferably the results of the BRS processing are maintained in a local cache at the reflector 108. Thus, if the best repeater has recently been determined for a given client (i.e., for a given network address), that best repeater can be reused quickly without being re-determined. Since the calculation described above is based on statically, pre-computed tables, if the tables have not changed then there is no need to re-determine the best repeater.

[0151] Determining the Group Reduction and Link Cost Tables

[0152] The Group Reduction Table and Link Cost Table used in BRS processing are created and regularly updated by an independent procedure referred to herein as NetMap. The NetMap procedure is run by executing several phases (described below) as needed.

[0153] The term Group is used here to refers to an IP “address group”.

[0154] The term Repeater Group refers to a Group that contains the IP address of a repeater.

[0155] The term link cost refers to a statically determined cost for transmitting data between two Groups. In a presently preferred implementation, this is the minimum of the sums of the costs of the links along each path between them. The link costs of primary concern here are link costs between a Group and a Repeater Group.

[0156] The term relative link cost refers to the link cost relative to other link costs for the same Group which is calculated by subtracting the minimum link cost from a Group to any Repeater Group from each of its link costs to a Repeater Group. The term Cost Set refers to a set of Groups that are equivalent in regard to Best Repeater Selection. That is, given the information available, the same repeater would be selected for any of them.

[0157] The NetMap procedure first processes input files to create an internal database called the Group Registry. These input files describe groups, the IP addresses within groups, and links between groups, and come a variety of sources, including publicly available Internet Routing Registry (IRR) databases, BGP router tables, and probe services that are located at various points around the Internet and use publicly available tools (such as “traceroute”) to sample data paths. Once this processing is complete, the Group Registry contains essential information used for further processing, namely (1) the identity of each group, (2) the set of IP addresses in a given group, (3) the presence of links between groups indicating paths over which information may travel, and (4) the cost of sending data over a given link.

[0158] The following processes are then performed on the Group Registry file.

[0159] Calculate Repeater Group Link Costs

[0160] The NetMap procedure calculates a “link cost” for transmission of data between each Repeater Group and each Group in the Group Registry. This overall link cost is defined as the minimum cost of any path between the two groups, where the cost of a path is equal to the sum of the costs of the individual links in the path. The link cost algorithm presented below is essentially the same as algorithm #562 from ACM journal Transactions on Mathematical Software: “Shortest Path From a Specific Node to All Other Nodes in a Network” by U. Pape, ACM TOMS 6 (1980) pp. 450-455, http://www.netlib.org/toms/562.

[0161] In this processing, the term Repeater Group refers to a Group that contains the IP address of a repeater. A group is a neighbor of another group if the Group Registry indicates that there is a link between the two groups.

For each target Repeater Group T:

- [0162] Initialize the link cost between T and itself to zero.
- [0163] Initialize the link cost between T and every other Group to infinity.
- [0164] Create a list L that will contain Groups that are equidistant from the target Repeater Group T.
- [0165] Initialize the list L to contain just the target Repeater Group T itself.
- [0166] While the list L is not empty:
  - [0167] Create an empty list L′ of neighbors of members of the list L.
  - [0168] For each Group G in the list L:
    - [0169] For each Group N that is a neighbor of G:
      - [0170] Let cost refer to the sum of the link cost between T and G, and the link cost between G and N.
      - [0171] The cost between T and G was determined in the previous pass of the algorithm; the link cost between G and N is from the Group Registry.
      - [0172] If cost is less than the link cost between T and N:
      - [0173] Set the link cost between T and N to cost.
      - [0174] Add N to L′ if it is not already on it.
  - [0175] Set L to L′.

[0176] Calculate Cost Sets

[0177] A Cost Set is a set of Groups that are equivalent with respect to Best Repeater Selection. That is, given the information available, the same repeater would be selected for any of them.

[0178] The “cost profile” of a Group G is defined herein as the set of costs between G and each Repeater. Two cost profiles are said to be equivalent if the values in one profile differ from the corresponding values in the other profile by a constant amount.

[0179] Once a client Group is known, the Best Repeater Selection algorithm relies on the cost profile for information about the Group. If two cost profiles are equivalent, the BRS algorithm would select the same repeater given either profile.

[0180] A Cost Set is then a set of groups that have equivalent cost profiles.

[0181] The effectiveness of this method can be seen, for example, in the case where all paths to a Repeater from some Group A pass through some other Group B. The two Groups have equivalent cost profiles (and are therefore in the same Cost Set) since whatever Repeater is best for Group A is also going to be best for Group B, regardless of what path is taken between the two Groups.

[0182] By normalizing cost profiles, equivalent cost profiles can be made identical. A normalized cost profile is a cost profile in which the minimum cost has the value zero. A normalized cost profile is computed by finding the minimum cost in the profile, and subtracting that value from each cost in the profile.

[0183] Cost Sets are then computed using the following algorithm:

- [0184] For each Group G:
  - [0185] Calculate the normalized cost profile for G
  - [0186] Look for a Cost Set with the same normalized cost profile.
  - [0187] If such as set is found, add G to the existing Cost Set;
  - [0188] otherwise, create a new Cost Set with the calculated normalized cost profile, containing only G.

[0189] The algorithm for finding Cost Sets employs a hash table to reduce the time necessary to determine whether the desired Cost Set already exists. The hash table uses a hash value computed from cost profile of G.

[0190] Each Cost Set is then numbered with a unique Cost Sent Index number. Cost Sets are then used in a straightforward manner to generate the Link Cost Table, which gives the cost from each Cost Set to each Repeater.

[0191] As described below, the Group Reduction Table maps every IP address to one of these Cost Sets.

[0192] Build IP Map

[0193] The IP Map is a sorted list of records which map IP address ranges to Link Cost Table keys. The format of the IP map is:

[0194] <base IP address><max IP address><Link Cost Table key>

[0195] where IP addresses are presently represented by 32-bit integers. The entries are sorted by descending base address, and by ascending maximum address among equal base addresses, and by ascending Link Cost Table key among equal base addresses and maximum addresses. Note that ranges may overlap.

[0196] The NetMap procedure generates an intermediate IP map containing a map between IP address ranges and Cost Set numbers as follows:

- [0197] For each Cost Set S:
  - [0198] For each Group G in S:
    - [0199] For each IP address range in G:
      - [0200] Add a triple (low address, high address, Cost Set number of S) to the IP map.

[0201] The IP map file is then sorted by descending base address, and by ascending maximum address among equal base addresses, and by ascending Cost Set number among equal base addresses and maximum addresses. The sort order for the base address and maximum address minimizes the time to build the Group Reduction Table and produces the proper results for overlapping entries.

[0202] Finally, the NetMap procedure creates the Group Reduction Table by processing the sorted IP map. The Group Reduction Table maps IP addresses (specified by ranges) into Cost Set numbers. Special processing of the IP map file is required in order to detect overlapping address ranges, and to merge adjacent address ranges in order to minimize the size of the Group Reduction Table.

[0203] An ordered list of address range segments is maintained, each segment consisting of a base address B and a Cost Set number N, sorted by base address B. (The maximum address of a segment is the base address of the next segment minus one.)

[0204] The following algorithm is used:

- [0205] Initialize the list with the elements [−infinity, NOGROUP], [+infinity, NOGROUP].
  - [0206] For each entry in the IP map, in sorted order, consisting of (b, m, s),
    - [0207] Insert (b, m, s) in the list (recall that IP map entries are of the form (low address, high address Cost Set number of S))
  - [0208] For each reserved LAN address range (b, m):
    - [0209] Insert (b, m, LOCAL) in the list.
  - [0210] For each Repeater at address a:
    - [0211] Insert (a, a, REPEATER) in the list.
  - [0212] For each segment S in the ordered list:
    - [0213] Merge S with following segments with the same Cost Set
    - [0214] Create a Group Reduction Table entry with base address from the base address of S,
      - [0215] max address=next segment's base−1,
      - [0216] group ID=Cost Set number of S.

[0217] A reserved LAN address range is an address range reserved for use by LANs which should not appear as a global Internet address. LOCAL is a special Cost Set index different from all others, indicating that the range maps to a client which should never be reflected. REPEATER is a special Cost Set index different from all others, indicating that the address range maps to a repeater. NOGROUP is a special Cost Set index different from all others, indicating that this range of addresses has no known mapping.

[0218] Given (B, M, N), insert an entry in the ordered address list as follows:

- [0219] Find the last segment (AB, AN) for which AB is less than or equal to B.
- [0220] If AB is less than B, insert a new segment (B, N) after (AB, AN).
- [0221] Find the last segment (YB, YN) for which YB is less than or equal to M.
- [0222] Replace by (XB, N) any segment (XB, NOGROUP) for which XB is greater than B and less than YB.
- [0223] If YN is not N, and either YN is NOGROUP or YB is less than or equal to B,
  - [0224] Let (ZB, ZN) be the segment following (YB, YN).
  - [0225] If M+1 is less than ZB, insert a new segment (M+1, YN) before (ZB, ZN).
  - [0226] Replace (YB, YN) by (YB, N).

[0227] Rewriting HTML Resources

[0228] As explained above with reference to FIG. 3 (B5), when a reflector or repeater serves a resource which itself includes resource identifiers (e.g., a HTML resource), that resource is modified (rewritten) to pre-reflect resource identifiers (URLs) of repeatable resources that appear in the resource. Rewriting ensures that when a browser requests repeatable resources identified by the requested resource, it gets them from a repeater without going back to the origin server, but when it requests non-repeatable resources identified by the requested resource, it will go directly to the origin server. Without this optimization, the browser would either make all requests at the origin server (increasing traffic at the origin server and necessitating far more redirections from the origin server), or it would make all requests at the repeater (causing the repeater to redundantly request and copy resources which could not be cached, increasing the overhead of serving such resources).

[0229] Rewriting requires that a repeater has been selected (as described above with reference to the Best Repeater Selector). Rewriting uses a so-called BASE directive. The BASE directive lets the HTML identify a different base server. (The base address is normally the address of the HTML resource.)

[0230] Rewriting is performed as follows:

- [0231] F1. A BASE directive is added at the beginning of the HTML resource, or modified where necessary. Normally, a browser interprets relative URLs as being relative to the default base address, namely, the URL of the HTML resource (page) in which they are encountered. The BASE address added specifies the resource at the reflector which originally served the resource. This means that unprocessed relative URLs (such as those generated by Javascript™ programs) will be interpreted as relative to the reflector. Without this BASE address, browsers would combine relative addresses with repeater names to create URLs which were not in the form required by repeaters (as described above in step D1).
- [0232] F2. The rewriter identifies directives, such as embedded images and anchors, containing URLs. If the rewriter is running in a reflector, it must parse the HTML file to identify these directives.
- [0233] If it is running in a repeater, the rewriter may have access to pre-computed information that identifies the location of each URL (placed in the HTML file in step F4).
- [0234] F3. For each URL encountered in the resource to be re-written, the rewriter must determine whether the URL is repeatable (as in steps B1-B2). If the URL is not repeatable, it is not modified. On the other hand, if the URL is repeatable, it is modified to refer to the selected repeater.
- [0235] F4. After all URLs have been identified and modified, if the resource is being served to a repeater, a table is appended at the beginning of the resource that identifies the location and content of each URL encountered in the resource. (This step is an optimization which eliminates the need for parsing HTML resources at the repeater.)
- [0236] F5. Once all changes have been identified, a new length is computed for the resource (page). The length is inserted in the HTTP header prior to serving the resource.

[0237] An extension of HTML, known as XML, is currently being developed. The process of rewriting URLs will be similar for XML, with some differences in the mechanism that parses the resource and identifies embedded URLs.

[0238] Handling Non-HTTP Protocols

[0239] This invention makes it possible to reflect references to resources that are served by protocols other than HTTP, for instance, the File Transfer Protocol (FTP) and audio/video stream protocols. However, many protocols do not provide the ability to redirect requests. It is, however, possible to redirect references before requests are actually made by rewriting URLs embedded in HTML pages. The following modifications to the above algorithms are used to support this capability.

[0240] In F4, the rewriter rewrites URLs for servers if those servers appear in a configurable table of cooperating origin server or so-called co-servers. The reflector operator can define this table to include FTP servers and other servers. A rewritten URL that refers to a non-HTTP resource takes the form:

- [0241] http://<repeater>/origin server>@proxy=<scheme>[:<type>]@/resource
  where <scheme> is a supported protocol name such as “ftp”. This URL format is an alternative to the form shown in B3.

[0242] In C3, the repeater looks for a protocol embedded in the arriving request. If a protocol is present and the requested resource is not already cached, the repeater uses the selected protocol instead of the default HTTP protocol to request the resource when serving it and storing it in the cache.

[0243] System Configuration and Management

[0244] In addition to the processing described above, the repeater network requires various mechanisms for system configuration and network management. Some of these mechanisms are described here.

[0245] Reflectors allow their operators to synchronize repeater caches by performing publishing operations. The process of keeping repeater caches synchronized is described below. Publishing indicates that a resource or collection of resources has changed.

[0246] Repeaters and reflectors participate in various types of log processing. The results of logs collected at repeaters are collected and merged with logs collected at reflectors, as described below.

[0247] Adding Subscribers to the Repeater Network

[0248] When a new subscriber is added to the network, information about the subscriber is entered in a Subscriber Table at the master repeater and propagated to all repeaters in the network. This information includes the Committed Aggregate Information Rate (CAIR) for servers belonging to the subscriber, and a list of the repeaters that may be used by servers belonging to the subscriber.

[0249] Adding Reflectors to the Repeater Network

[0250] When a new reflector is added to the network, it simply connects to and announces itself to a contact repeater, preferably using a securely encrypted certificate including the repeater's subscriber identifier.

[0251] The contact repeater determines whether the reflector network address is permitted for this subscriber. If it is, the contact repeater accepts the connection and updates the reflector with all necessary tables (using version numbers to determine which tables are out of date).

[0252] The reflector processes requests during this time, but is not “enabled” (allowed to reflect requests) until all of its tables are current.

[0253] Keeping Repeater Caches Synchronized

[0254] Repeater caches are coherent, in the sense that when a change to a resource is identified by a reflector, all repeater caches are notified, and accept the change in a single transaction.

[0255] Only the identifier of the changed resource (and not the entire resource) is transmitted to the repeaters; the identifier is used to effectively invalidate the corresponding cached resource at the repeater. This process is far more efficient than broadcasting the content of the changed resource to each repeater.

[0256] A repeater will load the newly modified resource the next time it is requested.

[0257] A resource change is identified at the reflector either manually by the operator, or through a script when files are installed on the server, or automatically through a change detection mechanism (e.g., a separate process that checks regularly for changes).

[0258] A resource change causes the reflector to send an “invalidate” message to its contact repeater, which forwards the message to the master repeater. The invalidate message contains a list of resource identifiers (or regular expressions identifying patterns of resource identifiers) that have changed. (Regular expressions are used to invalidate a directory or an entire server.) The repeater network uses a two-phase commit process to ensure that all repeaters correctly invalidate a given resource.

[0259] The invalidation process operates as follows:

[0260] The master broadcasts a “phase 1” invalidation request to all repeaters indicating the resources and regular expressions describing sets of resources to be invalidated.

[0261] When each repeater receives the phase 1 message, it first places the resource identifiers or regular expressions into a list of resource identifiers pending invalidation.

[0262] Any resource requested (in C3) that is in the pending invalidation list may not be served from the cache. This prevents the cache from requesting the resource from a peer cache which may not have received an invalidation notice. Were it to request a resource in this manner, it might replace the newly invalidated resource by the same, now stale, data.

[0263] The repeater then compares the resource identifier of each resource in its cache against the resource identifiers and regular expressions in the list.

[0264] Each match is invalidated by marking it stale and optionally removing it from the cache. This means that a future request for the resource will cause it to retrieve a new copy of the resource from the reflector.

[0265] When the repeater has completed the invalidation, it returns an acknowledgment to the master. The master waits until all repeaters have acknowledged the invalidation request.

[0266] If a repeater fails to acknowledge within a given period, it is disconnected from the master repeater. When it reconnects, it will be told to flush its entire cache, which will eliminate any consistency problem. (To avoid flushing the entire cache, the master could keep a log of all invalidations performed, sorted by date, and flush only files invalidated since the last time the reconnecting repeater successfully completed an invalidation. In the presently preferred embodiments this is not done since it is believed that repeaters will seldom disconnect.)

[0267] When all repeaters have acknowledged invalidation (or timed out) the repeater broadcasts a “phase 2” invalidation request to all repeaters. This causes the repeaters to remove the corresponding resource identifiers and regular expressions from the list of resource identifiers pending invalidation.

[0268] In another embodiment, the invalidation request will be extended to allow a “server push”. In such requests, after phase 2 of the invalidation process has completed, the repeater receiving the invalidation request will immediately request a new copy of the invalidated resource to place in its cache.

[0269] Logs and Log Processing

[0270] Web server activity logs are fundamental to monitoring the activity in a Web site. This invention creates “merged logs” that combine the activity at reflectors with the activity at repeaters, so that a single activity log appears at the origin server showing all Web resource requests made on behalf of that site at any repeater.

[0271] This merged log can be processed by standard processing tools, as if it had been generated locally.

[0272] On a periodic basis, the master repeater (or its delegate) collects logs from each repeater. The logs collected are merged, sorted by reflector identifier and timestamp, and stored in a dated file on a per-reflector basis. The merged log for a given reflector represents the activity of all repeaters on behalf of that reflector. On a periodic basis, as configured by the reflector operator, a reflector contacts the master repeater to request its merged logs. It downloads these and merges them with its locally maintained logs, sorting by timestamp. The result is a merged log that represents all activity on behalf of repeaters and the given reflector.

[0273] Activity logs are optionally extended with information important to the repeater network, if the reflector is configured to do so by the reflector operator. In particular, an “extended status code” indicates information about each request, such as:

- [0274] 1. request was served by a reflector locally;
- [0275] 2. request was reflected to a repeater;*
- [0276] 3. request was served by a reflector to a repeater;*
- [0277] 4. request for non-repeatable resource was served by repeater;*
- [0278] 5. request was served by a repeater from the cache;
- [0279] 6. request was served by a repeater after filling cache;
- [0280] 7. request pending invalidation was served by a repeater.
  (The activities marked with “*” represent intermediate states of a request and do not normally appear in a final activity log.)

[0281] In addition, activity logs contain a duration, and extended precision timestamps. The duration makes it possible to analyze the time required to serve a resource, the bandwidth used, the number of requests handled in parallel at a given time, and other quite useful information. The extended precision timestamp makes it possible to accurately merge activity logs.

[0282] Repeaters use the Network Time Protocol (NTP) to maintain synchronized clocks. Reflectors may either use NTP or calculate a time bias to provide roughly accurate timestamps relative to their contact repeater.

[0283] Enforcing Committed Aggregate Information Rate

[0284] The repeater network monitors and limits the aggregate rate at which data is served on behalf of a given subscriber by all repeaters. This mechanism provides the following benefits:

- [0285] 1. provides a means of pricing repeater service;
- [0286] 2. provides a means for estimating and reserving capacity at repeaters;
- [0287] 3. provides a means for preventing clients of a busy site from limiting access to other sites.

[0288] For each subscriber, a “threshold aggregate information rate” (TAIR) is configured and maintained at the master repeater. This threshold is not necessarily the committed rate, it may be a multiple of committed rate, based on a pricing policy.

[0289] Each repeater measures the information rate component of each reflector for which it serves resources, periodically (typically about once a minute), by recording the number of bytes transmitted on behalf of that reflector each time a request is delivered. The table thus created is sent to the master repeater once per period. The master repeater combines the tables from each repeater, summing the measured information of each reflector over all repeaters that serve resources for that reflector, to determine the “measured aggregate information rate” (MAIR) for each reflector.

[0290] If the MAIR for a given reflector is greater than the TAIR for that reflector, the MAIR is transmitted by the master to all repeaters and to the respective reflector.

[0291] When a reflector receives a request, it determines whether its most recently calculated MAIR is greater than its TAIR. If this is the case, the reflector probabilistically decides whether to suppress reflection, by serving the request locally (in B2). The probability of suppressing the reflection increases as an exponential function of the difference between the MAIR and the CAIR.

[0292] Serving a request locally during a peak period may strain the local origin server, but it prevents this subscriber from taking more than allocated bandwidth from the shared repeater network.

[0293] When a repeater receives a request for a given subscriber (in C2), it determines whether the subscriber is running near its threshold aggregate information rate. If this is the case, it probabilistically decides whether to reduce its load by redirecting the request back to the reflector. The probability increases exponentially as the reflector's aggregate information rate approaches its limit.

[0294] If a request is reflected back to a reflector, a special character string is attached to the resource identifier so that the receiving reflector will not attempt to reflect it again. In the current system, this string has the form

[0295] “src=overload”.

[0296] The reflector tests for this string in B2.

[0297] The mechanism for limiting Aggregate Information Rate described above is fairly coarse. It limits at the level of sessions with clients (since once a client has been reflected to a given repeater, the rewriting process tends to keep the client coming back to that repeater) and, at best, individual requests for resources. A more fine-grained mechanism for enforcing TAIR limits within repeaters operates by reducing the bandwidth consumption of a busy subscriber when other subscribers are competing for bandwidth.

[0298] The fine-grained mechanism is a form of data “rate shaping”. It extends the mechanism that copies resource data to a connection when a reply is being sent to a client. When an output channel is established at the time a request is received, the repeater identifies which subscriber the channel is operating for, in C2, and records the subscriber in a data field associated with the channel. Each time a “write” operation is about to be made to the channel, the Metered Output Stream first inspects the current values of the MAIR and TAIR, calculated above, for the given subscriber. If the MAIR is larger than the TAIR, then the mechanism pauses briefly before performing the write operation. The length of the pause is proportional to the amount the MAIR exceeds the TAIR The pause ensures that tasks sending other resources to other clients, perhaps on behalf of other subscribers, will have an opportunity to send their data.

[0299] Repeater Network Resilience

[0300] The repeater network is capable of recovering when a repeater or network connection fails.

[0301] A repeater cannot operate unless it is connected to the master repeater. The master repeater exchanges critical information with other repeaters, including information about repeater load, aggregate information rate, subscribers, and link cost.

[0302] If a master fails, a “succession” process ensures that another repeater will take over the role of master, and the network as a whole will remain operational. If a master fails, or a connection to a master fails through a network problem, any repeater attempting to communicate with the master will detect the failure, either through an indication from TCP/IP, or by timing out from a regular “heartbeat” message it sends to the master.

[0303] When any repeater is disconnected from its master, it immediately tries to reconnect to a series of potential masters based on a configurable file called its “succession list”.

[0304] The repeater tries each system on the list in succession until it successfully connects to a master. If in this process, it comes to its own name, it takes on the role of master, and accepts connections from other repeaters. If a repeater which is not at the top of the list becomes the master, it is called the “temporary master”.

[0305] A network partition may cause two groups of repeaters each to elect a master. When the partition is corrected it is necessary that the more senior master take over the network. Therefore, when a repeater is temporary master, it regularly tries to reconnect to any master above it in the succession list. If it succeeds, it immediately disconnects from all of the repeaters connected to it. When they retry their succession lists, they will connect to the more senior master repeater.

[0306] To prevent losses of data, a temporary master does not accept configuration changes and does not process log files. In order to take on these tasks, it must be informed that it is primary master by manual modification of its successor list. Each repeater regularly reloads its successor list to determine whether it should change its idea of who the master is.

[0307] If a repeater is disconnected from the master, it must resynchronize its cache when it reconnects to the master. The master can maintain a list of recent cache invalidations and send to the repeater any invalidations it was not able to process while disconnected. If this list is not available for some reason (for instance, because the reflector has been disconnected too long), the reflector must invalidate its entire cache.

[0308] A reflector is not permitted to reflect requests unless it is connected to a repeater. The reflector relies on its contact repeater for critical information, such as load and Link Cost Tables, and current aggregate information rate. A reflector that is not connected to a repeater can continue to receive requests and handle them locally.

[0309] If a reflector loses its connection with a repeater, due to a repeater failure or network outage, it continues to operate while it tries to connect to a repeater.

[0310] Each time a reflector attempts to connect to a repeater, it uses DNS to identify a set of candidate repeaters given a domain name that represents the repeater network. The reflector tries each repeater in this set until it makes a successful contact. Until a successful contact is made, the reflector serves all requests locally. When a reflector connects to a repeater, the repeater can tell it to attempt to contact a different repeater; this allows the repeater network to ensure that no individual repeater has too many contacts.

[0311] When contact is made, the reflector provides the version number of each of its tables to its contact repeater. The repeater then decides which tables should be updated and sends appropriate updates to the reflector. Once all tables have been updated, the repeater notifies the reflector that it may now start reflecting requests.

[0312] Using a Proxy Cache within a Repeater

[0313] Repeaters are intentionally designed so that any proxy cache can be used as a component within them. This is possible because the repeater receives HTTP requests and converts them to a form recognized by the proxy cache.

[0314] On the other hand, several modifications to a standard proxy cache have been or may be made as optimizations. This includes, in particular, the ability to conveniently invalidate a resource, the ability to support cache quotas, and the ability to avoid making an extra copy of each resource as it passes from the proxy cache through the repeater to the requester.

[0315] In a preferred embodiment, a proxy cache is used to implement C3. The proxy cache is dedicated for use only by one or more repeaters. Each repeater requiring a resource from the proxy cache constructs a proxy request from the inbound resource request. A normal HTTP GET request to a server contains only the pathname part of the URL—the scheme and server name are implicit. (In an HTTP GET request to a repeater, the pathname part of the URL includes the name of the origin server on behalf of which the request is being made, as described above.) However, a proxy agent GET request takes an entire URL. Therefore, the repeater must construct a proxy request containing the entire URL from the path portion of the URL it receives. Specifically, if the incoming request takes the form:

[0316] GET/<origin server>/<path>

then the repeater constructs a proxy request of the form:

[0317] GET http://<origin server>/<path>

and if the incoming request takes the form:

[0318] GET <origin server>@proxy=<scheme>:<type>@/<path>

then the repeater constructs a proxy request of the form:

[0319] GET <scheme>://<origin server>/<path>

[0320] Cache Control

[0321] HTTP replies contain directives called cache control directives, which are used to indicate to a cache whether the attached resource may be cached and if so, when it should expire. A Web site administrator configures the Web site to attach appropriate directives. Often, the administrator will not know how long a page will be fresh, and must define a short expiration time to try to prevent caches from serving stale data. In many cases, a Web site operator will indicate a short expiration time only in order to receive the requests (or hits) that would otherwise be masked by the presence of a cache. This is known in the industry as “cache-busting”. Although some cache operators may consider cache-busting to be impolite, advertisers who rely on this information may consider it imperative.

[0322] When a resource is stored in a repeater, its cache directives can be ignored by the repeater, because the repeater receives explicit invalidation events to determine when a resource is stale. When a proxy cache is used as the cache at the repeater, the associated cache directives may be temporarily disabled. However, they must be re-enabled when the resource is served from the cache to a client, in order to permit the cache-control policy (including any cache-busting) to take effect.

[0323] The present invention contains mechanisms to prevent the proxy cache within a repeater from honoring cache control directives, while permitting the directives to be served from the repeater.

[0324] When a reflector serves a resource to a repeater in B4, it replaces all cache directives by modified directives that are ignored by the repeater proxy cache. It does this by prefixing a distinctive string such as “wr-” to the beginning of the HTTP tag. Thus, “expires” becomes “wr-expires”, and “cache-control” becomes “wr-cache-control”. This prevents the proxy cache itself from honoring the directives. When a repeater serves a resource in C4, and the requesting client is not another repeater, it searches for HTTP tags beginning with “wr-” and removes the “wr-”. This allows the clients retrieving the resource to honor the directives.

[0325] Resource Revalidation

[0326] There are several cases where a resource may be cached so long as the origin server is consulted each time it is served. In one case, the request for the resource is attached to a so-called “cookie”. The origin server must be presented with the cookie to record the request and determine whether the cached resource may be served or not. In another case, the request for the resource is attached to an authentication header (which identifies the requester with a user id and password). Each new request for the resource must be tested at the origin server to assure that the requester is authorized to access the resource.

[0327] The HTTP 1.1 specification defines a reply header titled “Must-Revalidate” which allows an origin server to instruct a proxy cache to “revalidate” a resource each time a request is received. Normally, this mechanism is used to determine whether a resource is still fresh. In the present invention, Must-Revalidate makes it possible to ask an origin server to validate a request that is otherwise served from a repeater.

[0328] The reflector rule base contains information that determines which resources may be repeated but must be revalidated each time they are served. For each such resource, in B4, the reflector attaches a Must-Revalidate header. Each time a request comes to a repeater for a cached resource marked with a Must-Revalidate header, the request is forwarded to the reflector for validation prior to serving the requested resource.

[0329] Cache Quotas

[0330] The cache component of a repeater is shared among those subscribers that reflect clients to that repeater. In order to allow subscribers fair access to storage facilities, the cache may be extended to support quotas.

[0331] Normally, a proxy cache may be configured with a disk space threshold T. Whenever more than T bytes are stored in the cache, the cache attempts to find resources to eliminate.

[0332] Typically a cache uses the least-recently-used (LRU) algorithm to determine which resources to eliminate; more sophisticated caches use other algorithms. A cache may also support several threshold values—for instance, a lower threshold which, when reached, causes a low priority background process to remove items from the cache, and a higher threshold which, when reached, prevents resources from being cached until sufficient free disk space has been reclaimed.

[0333] If two subscribers A and B share a cache, and more resources of subscriber A are accessed during a period of time than resources of subscriber B, then fewer of B's resources will be in the cache when new requests arrive. It is possible that, due to the behavior of A, B's resources will never be cached when they are requested. In the present invention, this behavior is undesirable. To address this issue, the invention extends the cache at a repeater to support cache quotas.

[0334] The cache records the amount of space used by each subscriber in D_S, and supports a configurable threshold T_Sfor each subscriber.

[0335] Whenever a resource is added to the cache (at C3), the value D_Sis updated for the subscriber providing the resource. If D_Sis larger than T_S, the cache attempts to find resources to eliminate, from among those resources associated with subscriber S. The cache is effectively partitioned into separate areas for each subscriber.

[0336] The original threshold T is still supported. If the sum of reserved segments for each subscriber is smaller than the total space reserved in the cache, the remaining area is “common” and subject to competition among subscribers.

[0337] Note, this mechanism might be implemented by modifying the existing proxy cache discussed above, or it might also be implemented without modifying the proxy cache—if the proxy cache at least makes it possible for an external program to obtain a list of resources in the cache, and to remove a given resource from the cache.

[0338] Rewriting from Repeaters

[0339] When a repeater receives a request for a resource, its proxy cache may be configured to determine whether a peer cache contains the requested resource. If so, the proxy cache obtains the resource from the peer cache, which can be faster than obtaining it from the origin server (the reflector). However, a consequence of this is that rewritten HTML resources retrieved from the peer cache would identify the wrong repeater. Thus, to allow for cooperating proxy caches, resources are preferably rewritten at the repeater.

[0340] When a resource is rewritten for a repeater, a special tag is placed at the beginning of the resource. When constructing a reply, the repeater inspects the tag to determine whether the resource indicates that additional rewriting is necessary. If so, the repeater modifies the resource by replacing references to the old repeater with references to the new repeater.

[0341] It is only necessary to perform this rewriting when a resource is served to the proxy cache at another repeater.

[0342] Repeater-Side Include

[0343] Sometimes, an origin server constructs a custom resource for each request (for instance, when inserting an advertisement based on the history of the requesting client). In such a case, that resource must be served locally rather than repeated. Generally, a custom resource contains, along with the custom information, text and references to other, repeatable, resources.

[0344] The process that assembles a “page” from a text resource and possibly one or more image resources is performed by the Web browser, directed by HTML. However, it is not possible using HTML to cause a browser to assemble a page using text or directives from a separate resource. Therefore, custom resources often necessarily contain large amounts of static text that would otherwise be repeatable.

[0345] To resolve this potential inefficiency, repeaters recognize a special directive called a “repeater side include”. This directive makes it possible for the repeater to assemble a custom resource, using a combination of repeatable and local resources. In this way, the static text can be made repeatable, and only the special directive need be served locally by the reflector.

[0346] For example, a resource X might consist of custom directives selecting an advertising banner, followed by a large text article. To make this resource repeatable, the Web site administrator must break out a second resource, Y, to select the banner. Resource X is modified to contain a repeater-side include directive identifying resource Y, along with the article. Resource Y is created and contains only the custom directives selecting an ad banner. Now resource X is repeatable, and only resource Y, which is relatively small, is not repeatable.

[0347] When a repeater constructs a reply, it determines whether the resource being served is an HTML resource, and if so, scans it for repeater-side include directives. Each such directive includes a URL, which the repeater resolves and substitutes in place of the directive. The entire resource must be assembled before it is served, in order to determine its final size, as the size is included in a reply header ahead of the resource.

Claims

What is claimed:

1. A method for delivering resources in a distributed computing environment, wherein at least a first resource and a second resource are associated with a content provider, and wherein the first resource references the second resource via a first uniform resource locator (URL), the first URL identifying a first domain associated with the content provider, the method comprising:

(A) responsive to a request that causes a first resource to be served to a client from an origin server associated with a first domain, modifying the first resource by replacing the first URL with a second URL comprising data prepended to at least a portion of the first URL, wherein at least a portion of the data is resolvable to identify at least one repeater server in a second domain associated with a content delivery network (CDN) formed by a plurality of repeater servers, wherein at least two of said repeater servers in the CDN are at distinct locations from each other, the origin server being distinct from the repeater servers, resolving the at least a portion of the data in the second URL and identifying at least one repeater server in the CDN from which to serve the second resource to the client, wherein the identified repeater server comprises at least one cache storage device distinct from the origin server; and

(B) responsive to the identified repeater server being requested to serve the second resource:

(b1) if a copy of the second resource is already replicated on the at least one cache storage device of the identified repeater server, then serving the copy of the second resource to the client from the at least one cache storage device by the identified repeater server; otherwise,

(b2) if a copy of the second resource is not available on the at least one cache storage device of the identified repeater server, replicating the second resource on the at least one cache storage device of the identified repeater server and then serving the copy of the second resource to the client from the at least one cache storage device by the identified repeater server.

2. A method as recited in claim 1, wherein the replicating step comprises:

at the identified repeater server, obtaining a copy of the second resource from another repeater server in the CDN.

3. A method as recited in claim 1, wherein the replicating step comprises:

at the identified repeater server, obtaining a copy of the second resource from an origin server associated with the content provider.

4. A method as recited in claim 1, wherein the first URL comprises a first domain name identifying the first domain, the second URL being formed, at least in part, by prepending the data to at least a portion of the first domain name to form a second domain name, said second domain name being for the second domain.

5. A method as recited in claim 1, wherein the first resource references the second resource at least by way of a textual reference embedded in the first resource, wherein the first resource was modified by inserting the data into the textual reference.

6. A method as recited in claim 1, wherein the method further comprises:

responsive to the request, transmitting to the client an HTTP REDIRECT command comprising the second URL.

7. A method as recited in claim 1, wherein the first resource is a web page.

8. A method as recited in claim 7, wherein the second resource is an embedded object in the web page.

9. A method as recited in claim 7, wherein the second resource is a resource selected from the group comprising static and dynamic:

video content, audio content, text, image content, web pages, Hypertext Markup Language (HTML) files, XML files, files in a markup language, documents, hypertext documents, data files, and embedded resources.

10. A method as recited in claim 7, wherein the web page is selected from the group comprising: an Hypertext Markup Language (HTML) file, an XML file, a file in a markup language, and a hypertext document.

11. A method as recited in claim 1, wherein the identified repeater server is identified by an Internet Protocol (IP) address.

12. A method as recited in claim 1, wherein the data comprise at least an alphanumeric string of characters.

13. A method as recited in claim 12, wherein the step of resolving comprises:

resolving at least a portion of the alphanumeric string to identify the repeater server in the CDN from which to serve the second resource to the client.

14. A method as recited in claim 12, wherein at least some of the string of characters represent a hostname distinct from the first domain name.

15. A method as recited in claim 12, wherein at least some of the string of characters represent a fully qualified domain name.

16. A method as recited in claim 1 wherein the origin server is at a distinct network location from the repeater servers in the CDN.

17. A method as recited in claim 1, wherein the replicating act (b2) uses at least the portion of the first URL to retrieve the second resource from the origin server associated with said first domain.

18. A method as recited in claim 1, further comprising:

logging, by the identified repeater server, information related to at least some resources served therefrom on behalf of said content provider, wherein said at least some resources includes the second resource.

19. A method as recited in claim 2, further comprising:

logging, by at least some of the other repeater servers in the CDN, information related to at least some resources served therefrom on behalf of said content provider, wherein said at least some resources includes the second resource; and

merging information logged by the identified repeater server with information logged by each of the other repeater servers in the CDN to form merged information.

20. A method as recited in claim 19, further comprising:

providing the merged information to said content provider.

21. An Internet content delivery method for delivering resources on behalf of content providers to clients via a shared content delivery network (CDN) formed by a plurality of repeater servers, wherein at least two of said repeater servers in said CDN are at distinct locations from each other, the resources including web pages and at least some of the web pages including references to other resources, and wherein a first web page located on an origin server associated with a first content provider includes at least a first reference to a first resource, the origin server being a server at which resources originate, the method comprising:

(A) providing the plurality of repeater servers, wherein the shared CDN comprises at least a first domain distinct from a second domain of the origin server, wherein client requests to the first domain resolve to at least one of the plurality of repeater servers;

(B) responsive to a request that causes a first web page to be served to a client from an origin server associated with the first content provider, modifying the first web page by replacing the first reference with a second reference associated with the first domain and resolvable to identify at least one of the plurality of repeater servers as an appropriate repeater server to serve the first resource;

(c1) if a copy of the first resource is not already replicated on at least one cache storage device of the appropriate repeater server, wherein the at least one cache storage device is distinct from the origin server, then (i) retrieving a copy of the first resource from the origin server and storing the retrieved copy on the at least one cache storage device; and (ii) serving the retrieved copy of the first resource to the requesting client from the at least one cache storage device by the appropriate repeater server; otherwise,

(c2) if a copy of the first resource is already replicated on the at least one cache storage device of the appropriate repeater server, then serving the copy of the first resource to the requesting client from the at least one cache storage device by the appropriate repeater server,

wherein the appropriate repeater server is a repeater server from the plurality of repeater servers that was selected based at least in part on some measure of network cost.

22. A method as recited in claim 21, wherein the first web page is served to the client from the origin server.

23. A method as recited in claim 21, wherein the first reference to the first resource comprises a first uniform resource locator (URL) including a first hostname identifying the domain of the origin server, wherein the modifying act further comprises:

modifying the first URL to form the second reference by prepending data to at least a portion of the first URL, the second reference having a second hostname at least partially distinct from the first hostname, wherein the second hostname resolves to at least one of the plurality of repeater servers.

24. A method as recited in claim 21, wherein the web page is selected from the group comprising: an Hypertext Markup Language (HTML) file, an XML file, a file in a markup language, and a hypertext document, and

the first resource is a resource selected from the group comprising static and dynamic: video content, audio content, text, image content, web pages, HTML files, XML files, files in a markup language, documents, hypertext documents, data files, and embedded resources.

25. A method as recited in claim 21, wherein step (B) further comprises:

selecting the appropriate repeater using, at least in part, an analysis of network distance between the client and the plurality of repeater servers.

26. A method as recited in claim 25, wherein the selecting step comprises:

a step for determining and using a Group Reduction Tables and a Link Cost Tables to identify the appropriate repeater.

27. A content delivery system as recited in claim 21 wherein the measure of network cost is determined, at least in part, using a netmap determination means.

28. A method as recited in claim 21 wherein the origin server is at a distinct network location from the repeater servers in the CDN.

29. A method as recited in claim 21, further comprising:

logging, by the appropriate repeater server, information related to at least some resources served therefrom on behalf of said first content provider, wherein said at least some resources includes the first resource.

30. A method as recited in claim 29, further comprising:

logging, by at least some other repeater servers in the CDN, information related to at least some resources served therefrom on behalf of said first content provider, wherein said at least some resources includes the first resource; and

merging information logged by the appropriate repeater server with information logged by at least some of the other repeater servers in the CDN to generate merged information; and

providing the merged information to said content provider.

31. A method for delivering resources in a distributed computing environment on behalf of content providers to clients via a shared content delivery network (CDN) of servers, at least some of said servers in said CDN being at distinct locations from each other, wherein at least a first resource is associated with a first content provider, and wherein the first resource references a second resource via a uniform resource locator (URL) in said first resource, the URL including a first hostname, the method comprising:

(A) responsive to a request that causes the first resource to be served to a client from an origin server in a domain associated with the first content provider, wherein the domain associated with the first content provider is distinct from a domain of the shared CDN, providing at least a second hostname that is at least partially distinct from the first hostname, resolving at least the second hostname, and identifying a server in the domain of the shared CDN, wherein the identified CDN server comprises at least one cache storage device distinct from the origin server; and

(B) responsive to the identified CDN server being requested to serve the second resource:

(b2) if a copy of the second resource is already replicated on the at least one cache storage device of the identified CDN server, then serving the copy of the second resource to the client from the at least one cache storage device by the identified CDN server; otherwise,

(b2) if a copy of the second resource is not available on the at least one cache storage device of the identified CDN server, then (i) replicating the second resource on the at least one cache storage device of the identified CDN server, and (ii) serving the copy of the second resource to the client from the at least one cache storage device by the identified CDN server, wherein the replicating step (i) comprises: obtaining a copy of the second resource from another server in the CDN.

32. A method as recited in claim 31, wherein the method further comprises:

modifying at least a portion of said first hostname to create the second hostname.

33. A method as recited in claim 32, wherein the first resource is a web page in a markup language and wherein the second resource is a resource selected from the group comprising static and dynamic:

video content, audio content, text, image content, web pages, HTML files, XML files, files in a markup language, documents, hypertext documents, data files, and embedded resources.

34. A method as recited in claim 31, wherein the replicating act (b2) comprises:

using at least the first hostname to retrieve the second resource from the origin server in the domain associated with said first content provider.

35. A method as recited in claim 31, further comprising:

logging, by the identified CDN server, information related to at least some resources served therefrom on behalf of said first content provider, wherein said at least some resources includes the second resource.

36. A method as recited in claim 35, further comprising:

merging information logged by the identified CDN server with information logged by the other repeater servers in the CDN to form merged information; and

providing the merged information to said content provider.

Patent Citations (328)

Patent	Date	Inventor	Cited By
US4495570(A)	1985-01-01	Kitajima et al.	Applicant
US4591983(A)	1986-05-01	Bennett et al.	Applicant
US4594704(A)	1986-06-01	Ollivier	Applicant
US4726017(A)	1988-02-01	Krum et al.	Applicant
US4803641(A)	1989-02-01	Hardy et al.	Applicant
US4839798(A)	1989-06-01	Eguchi et al.	Applicant
US4847784(A)	1989-07-01	Clancey	Applicant
US4920432(A)	1990-04-01	Eggers	Applicant
US4922417(A)	1990-05-01	Churm et al.	Applicant
US4943932(A)	1990-07-01	Lark et al.	Applicant
US4949187(A)	1990-08-01	Cohen	Applicant
US4949248(A)	1990-08-01	Caro	Applicant
US5029232(A)	1991-07-01	Nall	Applicant
US5130792(A)	1992-07-01	Tindell et al.	Applicant
US5132992(A)	1992-07-01	Yurt et al.	Applicant
US5136716(A)	1992-08-01	Harvey et al.	Applicant
US5172413(A)	1992-12-01	Bradley	Applicant
US5191573(A)	1993-03-01	Hair	Applicant
US5253275(A)	1993-10-01	Yurt et al.	Applicant
US5253341(A)	1993-10-01	Rozmanith	Applicant
US5287499(A)	1994-02-01	Nemes	Applicant
US5287537(A)	1994-02-01	Newmark et al.	Applicant
US5291554(A)	1994-03-01	Morales	Applicant
US5341477(A)	1994-08-01	Pitkin et al.	Applicant
US5371532(A)	1994-12-01	Gelman	Applicant
US5410343(A)	1995-04-01	Coddington	Applicant
US5414455(A)	1995-05-01	Hooper	Applicant
US5442389(A)	1995-08-01	Blahut	Applicant
US5442390(A)	1995-08-01	Hooper	Applicant
US5442749(A)	1995-08-01	Northcutt	Applicant
US5471622(A)	1995-11-01	Eadline	Applicant
US5475615(A)	1995-12-01	Lin	Applicant
US5508732(A)	1996-04-01	Bottomley	Applicant
US5515511(A)	1996-05-01	Nguyen	Applicant
US5519435(A)	1996-05-01	Anderson	Applicant
US5522070(A)	1996-05-01	Sumimoto	Applicant
US5528281(A)	1996-06-01	Grady	Applicant
US5539621(A)	1996-07-01	Kikinis	Applicant
US5542087(A)	1996-07-01	Neimat et al.	Applicant
US5544313(A)	1996-08-01	Shachnai	Applicant
US5544327(A)	1996-08-01	Dan	Applicant
US5550577(A)	1996-08-01	Verbiest	Applicant
US5550863(A)	1996-08-01	Yurt	Applicant
US5550982(A)	1996-08-01	Long	Applicant
US5557317(A)	1996-09-01	Nishio	Applicant
US5572643(A)	1996-11-01	Judson	Applicant
US5590288(A)	1996-12-01	Castor	Applicant
US5592611(A)	1997-01-01	Midgely	Applicant
US5594910(A)	1997-01-01	Filepp et al.	Applicant
US5603026(A)	1997-02-01	Demers et al.	Applicant
US5619648(A)	1997-04-01	Canale	Applicant
US5623656(A)	1997-04-01	Lyons	Applicant
US5625781(A)	1997-04-01	Cline	Applicant
US5627829(A)	1997-05-01	Gleeson et al.	Applicant
US5630067(A)	1997-05-01	Kindell	Applicant
US5633999(A)	1997-05-01	Clowes	Applicant
US5634006(A)	1997-05-01	Baugher et al.	Applicant
US5638443(A)	1997-06-01	Stefik et al.	Applicant
US5644714(A)	1997-07-01	Kikinis	Applicant
US5646676(A)	1997-07-01	Dewkett et al.	Applicant
US5649186(A)	1997-07-01	Ferguson	Applicant
US5659729(A)	1997-08-01	Nielsen	Applicant
US5666362(A)	1997-09-01	Chen	Applicant
US5671279(A)	1997-09-01	Elgamai	Applicant
US5675734(A)	1997-10-01	Hair	Applicant
US5682512(A)	1997-10-01	Tetrick	Applicant
US5699513(A)	1997-12-01	Feigen et al.	Applicant
US5708780(A)	1998-01-01	Levergood et al.	Applicant
US5712979(A)	1998-01-01	Graber et al.	Applicant
US5715453(A)	1998-02-01	Stewart	Applicant
US5721914(A)	1998-02-01	DeVries	Applicant
US5734831(A)	1998-03-01	Sanders	Applicant
US5740423(A)	1998-04-01	Logan et al.	Applicant
US5742762(A)	1998-04-01	Scholl	Applicant
US5751961(A)	1998-05-01	Smyk	Examiner
US5761507(A)	1998-06-01	Govett	Applicant
US5761663(A)	1998-06-01	Largarde et al.	Applicant
US5764906(A)	1998-06-01	Edelstein et al.	Applicant
US5774660(A)	1998-06-01	Brendel et al.	Applicant
US5774668(A)	1998-06-01	Choquier et al.	Applicant
US5777988(A)	1998-07-01	Cisneros	Applicant
US5777989(A)	1998-07-01	McGarvey	Applicant
US5778187(A)	1998-07-01	Monteiro et al.	Applicant
US5784058(A)	1998-07-01	LaStrange et al.	Applicant
US5794253(A)	1998-08-01	Norin et al.	Examiner
US5796952(A)	1998-08-01	Davis	Applicant
US5799141(A)	1998-08-01	Galipeau et al.	Applicant
US5802106(A)	1998-09-01	Packer	Applicant
US5802291(A)	1998-09-01	Balick et al.	Applicant
US5812769(A)	1998-09-01	Graber et al.	Applicant
US5815664(A)	1998-09-01	Asano	Applicant
US5819092(A)	1998-10-01	Ferguson et al.	Examiner
US5826031(A)	1998-10-01	Nielsen	Applicant
US5828847(A)	1998-10-01	Gehr	Applicant
US5832506(A)	1998-11-01	Kuzma	Applicant
US5832514(A)	1998-11-01	Norin et al.	Applicant
US5835718(A)	1998-11-01	Blewett	Applicant
US5838906(A)	1998-11-01	Doyle et al.	Applicant
US5845303(A)	1998-12-01	Templeman	Applicant
US5856974(A)	1999-01-01	Gervais et al.	Applicant
US5862339(A)	1999-01-01	Bonnaure	Applicant
US5867706(A)	1999-02-01	Martin et al.	Examiner
US5867799(A)	1999-02-01	Lang et al.	Applicant
US5870546(A)	1999-02-01	Kirsch	Applicant
US5870559(A)	1999-02-01	Leshem et al.	Applicant
US5878212(A)	1999-03-01	Civanlar et al.	Applicant
US5884038(A)	1999-03-01	Kapoor	Applicant
US5890171(A)	1999-03-01	Blumer et al.	Applicant
US5893116(A)	1999-04-01	Simmonds et al.	Applicant
US5894554(A)	1999-04-01	Lowery et al.	Applicant
US5896533(A)	1999-04-01	Ramos et al.	Applicant
US5903723(A)	1999-05-01	Beck et al.	Applicant
US5907704(A)	1999-05-01	Gudmundson et al.	Applicant
US5913028(A)	1999-06-01	Wang et al.	Applicant
US5913033(A)	1999-06-01	Grout	Applicant
US5918010(A)	1999-06-01	Appleman et al.	Applicant
US5919247(A)	1999-07-01	Van Hoff et al.	Applicant
US5920701(A)	1999-07-01	Miller et al.	Applicant
US5925106(A)	1999-07-01	Nielsen	Applicant
US5931904(A)	1999-08-01	Banga	Applicant
US5933832(A)	1999-08-01	Suzuoka et al.	Applicant
US5935207(A)	1999-08-01	Logue et al.	Applicant
US5940831(A)	1999-08-01	Takano	Examiner
US5944780(A)	1999-08-01	Chase	Applicant
US5945989(A)	1999-08-01	Freishtat et al.	Applicant
US5956489(A)	1999-09-01	San Andres et al.	Applicant
US5956716(A)	1999-09-01	Kenner	Applicant
US5958008(A)	1999-09-01	Pogrebisky et al.	Applicant
US5961596(A)	1999-10-01	Takubo et al.	Applicant
US5966440(A)	1999-10-01	Hair	Applicant
US5968121(A)	1999-10-01	Logan et al.	Applicant
US5973696(A)	1999-10-01	Agranat et al.	Applicant
US5978791(A)	1999-11-01	Farber et al.	Examiner
US5983005(A)	1999-11-01	Monteiro et al.	Applicant
US5983214(A)	1999-11-01	Lang et al.	Applicant
US5983227(A)	1999-11-01	Nazem et al.	Applicant
US5987606(A)	1999-11-01	Cirasole et al.	Applicant
US5991809(A)	1999-11-01	Kriegsman	Applicant
US5996025(A)	1999-11-01	Day	Applicant
US6002720(A)	1999-12-01	Yurt et al.	Applicant
US6003030(A)	1999-12-01	Kenner et al.	Applicant
US6006264(A)	1999-12-01	Colby et al.	Applicant
US6012090(A)	2000-01-01	Chung et al.	Examiner
US6014686(A)	2000-01-01	Elnozahy et al.	Applicant
US6014698(A)	2000-01-01	Griffiths	Applicant
US6018516(A)	2000-01-01	Packer	Applicant
US6021426(A)	2000-02-01	Douglis	Applicant
US6026440(A)	2000-02-01	Sharder et al.	Applicant
US6029175(A)	2000-02-01	Chow et al.	Applicant
US6029176(A)	2000-02-01	Cannon	Applicant
US6035332(A)	2000-03-01	Ingrassia, Jr. et al.	Applicant
US6038216(A)	2000-03-01	Packer	Applicant
US6038310(A)	2000-03-01	Hollywood et al.	Applicant
US6038610(A)	2000-03-01	Belfiore et al.	Applicant
US6041307(A)	2000-03-01	Ahuja et al.	Applicant
US6041324(A)	2000-03-01	Earl et al.	Applicant
US6044405(A)	2000-03-01	Driscoll, III et al.	Applicant
US6046980(A)	2000-04-01	Packer	Applicant
US6049831(A)	2000-04-01	Gardell et al.	Applicant
US6052718(A)	2000-04-01	Gifford	Examiner
US6052730(A)	2000-04-01	Feliciano et al.	Applicant
US6061738(A)	2000-05-01	Osaku et al.	Applicant
US6065051(A)	2000-05-01	Steele et al.	Applicant
US6065062(A)	2000-05-01	Periasamy et al.	Applicant
US6070191(A)	2000-05-01	Narendran et al.	Applicant
US6078943(A)	2000-06-01	Yu	Examiner
US6081829(A)	2000-06-01	Sidana	Applicant
US6081835(A)	2000-06-01	Antcliff	Applicant
US6085193(A)	2000-07-01	Malkin et al.	Examiner
US6092112(A)	2000-07-01	Fukushige	Applicant
US6092204(A)	2000-07-01	Baker	Applicant
US6094680(A)	2000-07-01	Hokanson	Examiner
US6098078(A)	2000-08-01	Gehani	Applicant
US6105028(A)	2000-08-01	Sullivan et al.	Applicant
US6108673(A)	2000-08-01	Brandt et al.	Applicant
US6108703(A)	2000-08-01	Leighton et al.	Applicant
US6112231(A)	2000-08-01	DeSimone et al.	Applicant
US6112239(A)	2000-08-01	Kenner et al.	Applicant
US6112240(A)	2000-08-01	Pogue et al.	Applicant
US6115357(A)	2000-09-01	Packer et al.	Applicant
US6115752(A)	2000-09-01	Chauhan	Applicant
US6119143(A)	2000-09-01	Dias et al.	Applicant
US6119163(A)	2000-09-01	Monteiro et al.	Applicant
US6125388(A)	2000-09-01	Reisman	Applicant
US6125394(A)	2000-09-01	Rabinovich	Applicant
US6128601(A)	2000-10-01	Van Horne et al.	Applicant
US6128660(A)	2000-10-01	Grimm et al.	Applicant
US6134583(A)	2000-10-01	Herriot	Applicant
US6144375(A)	2000-11-01	Jain et al.	Applicant
US6144702(A)	2000-11-01	Yurt et al.	Applicant
US6144996(A)	2000-11-01	Starnes et al.	Applicant
US6151624(A)	2000-11-01	Teare et al.	Applicant
US6154738(A)	2000-11-01	Call	Applicant
US6154744(A)	2000-11-01	Kenner et al.	Applicant
US6154753(A)	2000-11-01	McFarland	Applicant
US6154777(A)	2000-11-01	Ebrahim	Applicant
US6163779(A)	2000-12-01	Mantha et al.	Applicant
US6167427(A)	2000-12-01	Rabinovich et al.	Applicant
US6173311(B1)	2001-01-01	Hassett et al.	Applicant
US6173322(B1)	2001-01-01	Hu	Applicant
US6178160(B1)	2001-01-01	Bolton et al.	Applicant
US6181690(B1)	2001-01-01	Civanlar	Applicant
US6181867(B1)	2001-01-01	Kenner et al.	Applicant
US6185598(B1)	2001-02-01	Farber et al.	Examiner
US6185619(B1)	2001-02-01	Joffe et al.	Applicant
US6189030(B1)	2001-02-01	Kirsch et al.	Applicant
US6189039(B1)	2001-02-01	Harvey	Applicant
US6195680(B1)	2001-02-01	Goldszmidt	Applicant
US6222856(B1)	2001-04-01	Krishnan et al.	Applicant
US6226618(B1)	2001-05-01	Downs	Applicant
US6226642(B1)	2001-05-01	Beranek et al.	Applicant
US6230196(B1)	2001-05-01	Guenthner et al.	Applicant
US6243760(B1)	2001-06-01	Armbruster et al.	Examiner
US6256675(B1)	2001-07-01	Rabinovich	Applicant
US6263313(B1)	2001-07-01	Milsted	Applicant
US6266699(B1)	2001-07-01	Sevcik	Applicant
US6269394(B1)	2001-07-01	Kenner et al.	Applicant
US6272566(B1)	2001-08-01	Craft	Applicant
US6282569(B1)	2001-08-01	Wallis et al.	Applicant
US6282574(B1)	2001-08-01	Voit	Applicant
US6286045(B1)	2001-09-01	Griffiths et al.	Applicant
US6292905(B1)	2001-09-01	Wallach et al.	Examiner
US6298041(B1)	2001-10-01	Packer	Applicant
US6311214(B1)	2001-10-01	Rhoads	Applicant
US6314565(B1)	2001-11-01	Kenner et al.	Applicant
US6324580(B1)	2001-11-01	Jindal et al.	Examiner
US6327622(B1)	2001-12-01	Jindal et al.	Applicant
US6330602(B1)	2001-12-01	Law et al.	Examiner
US6332195(B1)	2001-12-01	Green et al.	Applicant
US6347085(B2)	2002-02-01	Kelly	Applicant
US6351775(B1)	2002-02-01	Yu	Examiner
US6360256(B1)	2002-03-01	Lim	Applicant
US6360262(B1)	2002-03-01	Guenthner et al.	Examiner
US6370571(B1)	2002-04-01	Medin, Jr.	Applicant
US6370580(B2)	2002-04-01	Kriegsman	Applicant
US6412000(B1)	2002-06-01	Riddle et al.	Applicant
US6415280(B1)	2002-07-01	Farber et al.	Examiner
US6418421(B1)	2002-07-01	Hurtado	Applicant
US6418461(B1)	2002-07-01	Barnhouse et al.	Applicant
US6421726(B1)	2002-07-01	Kenner et al.	Applicant
US6424992(B2)	2002-07-01	Devarakonda et al.	Applicant
US6425005(B1)	2002-07-01	Dugan et al.	Applicant
US6434622(B1)	2002-08-01	Monteiro et al.	Applicant
US6442549(B1)	2002-08-01	Schneider	Applicant
US6452925(B1)	2002-09-01	Sistanizadeh et al.	Applicant
US6456630(B1)	2002-09-01	Packer et al.	Applicant
US6460082(B1)	2002-10-01	Lumelsky	Applicant
US6463454(B1)	2002-10-01	Lumelsky	Applicant
US6463508(B1)	2002-10-01	Wolf	Applicant
US6470389(B1)	2002-10-01	Chung et al.	Examiner
US6480893(B2)	2002-11-01	Kriegsman	Applicant
US6484204(B1)	2002-11-01	Rabinovich	Applicant
US6496856(B1)	2002-12-01	Kenner et al.	Applicant
US6502125(B1)	2002-12-01	Kenner et al.	Applicant
US6502215(B2)	2002-12-01	Raad et al.	Applicant
US6557054(B2)	2003-04-01	Reisman	Applicant
US6581090(B1)	2003-06-01	Lindbo et al.	Applicant
US6587837(B1)	2003-07-01	Spagna	Applicant
US6591299(B2)	2003-07-01	Riddle et al.	Applicant
US6611862(B2)	2003-08-01	Reisman	Applicant
US6654807(B2)	2003-11-01	Farber et al.	Examiner
US6658464(B2)	2003-12-01	Reisman	Applicant
US6665706(B2)	2003-12-01	Kenner et al.	Applicant
US6741563(B2)	2004-05-01	Packer	Applicant
US6763377(B1)	2004-07-01	Belknap et al.	Applicant
US6779031(B1)	2004-08-01	Picher-Dempsey	Applicant
US6785704(B1)	2004-08-01	McCanne	Applicant
US6799221(B1)	2004-09-01	Kenner et al.	Applicant
US6859791(B1)	2005-02-01	Spagna	Applicant
US6915329(B2)	2005-07-01	Kriegsman	Applicant
US6928442(B2)	2005-08-01	Farber et al.	Examiner
US6944676(B1)	2005-09-01	Armbruster et al.	Examiner
US6963910(B1)	2005-11-01	Belknap	Applicant
US6973485(B2)	2005-12-01	Ebata et al.	Applicant
US7047300(B1)	2006-05-01	Oehrke et al.	Applicant
US7054935(B2)	2006-05-01	Farber et al.	Examiner
US7061923(B2)	2006-06-01	Dugan et al.	Applicant
US7080153(B2)	2006-07-01	Monteiro et al.	Applicant
US7103564(B1)	2006-09-01	Ehnebuske	Applicant
US7110984(B1)	2006-09-01	Spagna	Applicant
US7117259(B1)	2006-10-01	Rohwer	Applicant
US7188085(B2)	2007-03-01	Pelletier	Applicant
US7206748(B1)	2007-04-01	Gruse	Applicant
US7254645(B2)	2007-08-01	Nishi	Applicant
US7266686(B1)	2007-09-01	Monteiro et al.	Applicant
US7600120(B2)	2009-10-01	Monteiro et al.	Examiner
US7697415(B2)	2010-04-01	Dugan et al.	Applicant
US7802310(B2)	2010-09-01	Farber et al.	Examiner
US7945539(B2)	2011-05-01	Farber et al.	Examiner
US7945544(B2)	2011-05-01	Farber et al.	Examiner
US7945693(B2)	2011-05-01	Farber et al.	Examiner
US7949662(B2)	2011-05-01	Farber et al.	Examiner
US7949779(B2)	2011-05-01	Farber et al.	Examiner
US8001096(B2)	2011-08-01	Farber et al.	Examiner
US8060613(B2)	2011-11-01	Farber et al.	Examiner
US8082262(B2)	2011-12-01	Farber et al.	Examiner
US8099420(B2)	2012-01-01	Farber et al.	Examiner
US2001/0052024(A1)	2001-12-01	Devarakonda	Applicant
US2002/0078233(A1)	2002-06-01	Biliris	Applicant
US2003/0149581(A1)	2003-08-01	Chaudhri	Applicant
US2004/0139097(A1)	2004-07-01	Farber et al.	Applicant
US2005/0038851(A1)	2005-02-01	Kriegsman	Applicant
US2005/0114296(A1)	2005-05-01	Farber et al.	Applicant
US2005/0198334(A1)	2005-09-01	Farber et al.	Examiner
US2006/0218265(A1)	2006-09-01	Farber et al.	Examiner
US2007/0233705(A1)	2007-10-01	Farber et al.	Examiner
US2007/0233706(A1)	2007-10-01	Farber et al.	Examiner
US2007/0233846(A1)	2007-10-01	Farber et al.	Examiner
US2007/0233884(A1)	2007-10-01	Farber et al.	Examiner
US2008/0140800(A1)	2008-06-01	Farber et al.	Examiner
US2008/0215755(A1)	2008-09-01	Farber et al.	Examiner
US2011/0219120(A1)	2011-09-01	Farber et al.	Examiner
CA2202572	1998-10-01		Applicant
EP801487(A2)	1997-10-01		Applicant
EP817444	1998-01-01		Applicant
EP824236(A2)	1998-02-01		Applicant
EP865180(A2)	1998-09-01		Applicant
GB2281793	1995-03-01		Applicant
JP5162529	1993-06-01		Applicant
JP7066829	1995-03-01		Applicant
JP8-044643	1996-02-01		Applicant
JP8328583	1996-09-01		Applicant
JP10-027148	1998-01-01		Applicant
WO96/42041	1996-12-01		Applicant
WO97/11429	1997-03-01		Applicant
WO97/29423	1997-08-01		Applicant
WO98/04985	1998-02-01		Applicant
WO98/06033	1998-02-01		Applicant

Non-Patent Literature (372)

Complaint for Injunctive and Other Relief, filed Dec. 17, 2007 in Civil Action No. 2:07CV589.Applicant
Report on the Filing or Determination of an Action Regarding a Patent or Trademark, dated Dec. 28, 2007, in connection with Civil Action No. 2:07CV589 filed Dec. 17, 2007.Applicant
Rule 7.1 Financial Interest Disclosure Statement filed Dec. 17, 2007 in Civil Action No. 2:07CV589.Applicant
Awerbuch, B. et al., Distributed Paging for General Networks. In Proc. of the 7th ACM-SIAM Symposium on Discrete Algorithms, pp. 574-583, Jan. 1996.Applicant
Baentsch, M, et al. “Enhancing the Web's Infrastructure: From Caching to Replication.” IEEE Internet Computing, 1(2):18--27, Mar. 1997.Applicant
Gadde, S., et al., “Reduce, reuse, recycle: An approach to building large internet caches,” in Workshop on Hot Topics in Operating Systems (HotOS), Apr. 1997.Applicant
Korkea-aho, M. (1995). Scalability in Distributed Multimedia Systems, Technical report TKO-B128, Helsinki University of Technology.Applicant
Naor, Moni, et al., “The Load, Capacity and Availability of Quorum Systems”, In Proceedings of the 35th IEEE Symposium on Foundations of Computer Science, (Nov. 1994), 214-225.Applicant
Pultar, Giray; “USENIX, Automatically Selecting a Close Mirror Based on Network Topology,” Proceedings of the Twelfth Systems Administration Conference; Boston, Massachusetts, Dec. 1998, p. 159-166.Applicant
Ravi, R., “Rapid Rumor Ramification: Approximating the Minimum Broadcast Time”, In Proceedings of teh 35th IEEE Symposium on Foundation of Computer Science, (Nov. 1994), 202-213.Applicant
Schmidt, J., et al., “Chernoff-Hoeffding Bounds for Applications with Limited Independence”, in Proc. 4th ACM-SIAM Symp. on Discrete Algorithms, (1993), 331-340.Applicant
Wegman, Mark, et al., “New Hash Functions and Their Use in Authentication and Set Equality”, Journal of Computer and System Sciences, vol. 22, (Jun. 1981), 265-279.Applicant
“Cisco Takes Global Route”, PC Week News, (Feb. 17, 1997), p. 23.Applicant
“Exporting Web Server Final Report,” http://www.cs.technion.ac.il/Labs/Lccn/projects/spring97/project4/final—report.html, Spring 1997 (downloaded Jul. 7, 2007).Applicant
“Global IP/PX Service Should Keep Network Delays Down”, Infoworld, (Jan. 20, 1997), 1 page.Applicant
“Local Area Network Server Replacement Procedure”, IBM Technical Disclosure Bulletin, vol. 38, No. 1, (Jan. 1995), 235-236.Applicant
“Patent Abstracts of Japan, Electronic Mail Multiplexing System and Communication Control Method in the System” (Appln. No. JP19930162529), (Jun. 30, 1993) (Pub. No. JP 7066829).Applicant
“Patent Abstracts of Japan, Method and Device for Repeating and Converting Information”, (Appln. No. JP19960328583) (Pub. No. JP10171727), Jun. 26, 1998.Applicant
Adler, R. M., “Distributed Coordination Models for Client/Server Computing,” Computer 28, 4 (Apr. 1995), 14-22.Applicant
Andresen et al., “SWEB: Towards a Scalable World Wide Web Server on Multicomputers”, Proc. IPPS, (Apr. 15, 1996), 850-856.Applicant
Andresen, D., et al., Multiprocessor scheduling with client resources to improve the response time of WWW applications, Proc. 11th Int'l Conf. on Supercomputing (Austria, Jul. 1997). ICS '97. ACM Press, NY, NY, 92-99.Applicant
Basturk, E., et al., “Using network layer anycast for load distribution in the Internet,” Tech. Rep., IBM T.J. Watson Research Center, 1997 (21 pgs.).Applicant
Berners-Lee et al., RFC 1738—Uniform Resource Locators, Dec. 1994.Applicant
Bestavros, A., “Speculative Data Dissermination and Service to Reduce Server Load, Network Traffic and Service Time in Distributed Information Systems”, in Proc. ICDE '96: The 1996 Int'l Conf. on Data Engineering, (Mar. 1996), 4 pages.Applicant
Bestavros, et al., “Server-Initiated Document Dissemination for the WWW,” IEEE Data Engineering Bulletin 19(3):3-11, Sep. 1996.Applicant
Bhattacharjee et al., “Application-layer anycasting,” in Proc. IEEE INFOCOM '97, 1997.Applicant
Braun, H., et al., “Web traffic characterization: an assessment of the impact of caching documents from NCSA's web server,” Comput. Netw. ISDN Syst. 28, 1-2 (Dec. 1995), 37-51.Applicant
Brisco, T. P. RFC 1794: DNS support for load balancing, Apr. 1995.Applicant
Carter et al., “Dynamic server selection using bandwidth probing in wide-area networks,” Tech. Rep. BU-CS-96-007, Comp. Sci. Dept., Boston University, Mar. 1996.Applicant
Carter et al., Server selection using dynamic path characterization in Wide-Area Networks, IEEE INFOCOM '97, 1997 (pp. 1014-1021).Applicant
Carter, J. Lawrence et al., “Universal Classes of Hash Functions”, Journal of Computer and System Sciences, vol. 18, No. 2, (Apr. 1979), 143-154.Applicant
Chankhunthod, A. et al., “A Hierarchical Internet Object Cache”, Proc. of the 1996 USENIX Technical Conf., Jan. 1996, pp. 153-163.Applicant
Cisco Systems Inc., Cisco Distributed Director, pp. 1-15, http://www.cisco.com/warp/public/751/distdir/dd—wp.htm, 1997.Applicant
Cisco Systems, Inc., “Cache Director System”, http://www.cisco.com/warp/public/751/cache/cdsov.htm, (1997), 1-5.Applicant
Cisco Systems, Inc., “Cache Director Systems Technology Overview”, http://www.cisco.com/warp/public/751/cache/cds—ds.htm, (1997), 1-3.Applicant
Cisco Systems, Inc., “Cisco Cache Engine”, http://www.cisco.com/warp/public/751/cache/index.html.Applicant
Cisco Systems, Inc., “Cisco Introduces Web Cache Product For Scaling The Internet”, http://www.cisco.com/warp/public/146/1947.html, (1996), 1-2.Applicant
Cisco Systems, Inc., “Cisco Systems Ships Cisco LocalDirector to Meet Demands of High-Volume Web Traffic,” 1996, pp. 1-2, http://www.cisco.com/warp/public/146/323.html.Applicant
Cisco Systems, Inc., “Excite Chooses Cisco Local Director to Support its Growing Service”, http://www.cisco.com/warp/public/146/1857.html, (1997), 1-2.Applicant
Cisco Systems, Inc., “How to Cost-Effectively Scale Web Servers”, http://www.cisco.com/warp/public/784//5.html, (1996), 1-5.Applicant
Cisco Systems, Inc., “Local Director”, http://www.cisco.com/warp/public/751/lodir/index.html, 2 pages.Applicant
Cisco Systems, Inc., “Local Director”, pp. 1-3.Applicant
Cisco Systems, Inc., “Scaling the Internet News Service”, http://www.cisco.com/warp/public/751/lodir/news wp.htm, (1997), 1-11.Applicant
Cisco Systems, Inc., “Scaling the World Wide Web”, http://www.cisco.com/warp/public/751/lodir/swww wp.html, (1996), 1-7.Applicant
Cisco Systems, Inc., Cisco DistributedDirector 2500 Series Installation and Configuration Guide, pp. xix-xxii; 1-1 to 1-12; 6-1 to 6-18; 7-1 to 7-18; 8-1 to 8-24, pub. date unknown, downloaded Apr. 2007: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/distrdir/dd2501/.Applicant
Cisco Systems, Inc., Cisco DistributedDirector 4700-M Installation and Configuration Guide, pp. xix-xxii; 1-1 to 1-14; 7-1 to 7-18, 8-1 to 8-20; pub. date unknown, [downloaded Apr. 2007 from http://www.cisco.com/univercd/cc/td/doc/product/iaabu/distrdir/dd4700m/].Applicant
Cisco Systems, Inc., http://www.cisco.com/warp/public/751/disttdir/ddwp.htm, (1997), 1-4.Applicant
Cisco Systems, Inc., http://www.cisco.com/warp/public/751/lodir/lodirds.htm, (1997), 1-4.Applicant
Cohen, J., et al., “Cache Array Routing Protocol v1.1”, Sep. 29, 1997; http://tools.ietf.org/id/draft-vinod-carp-v1-01.txt (Last-Modified: Wed, Oct. 1, 1997).Applicant
Colajanni, M. and Yu, P. S. 1997. Adaptive TTL schemes for load balancing of distributed Web servers. SIGMETRICS Perform. Eval. Rev. 25, 2 (Sep. 1997), 36-42.Applicant
Communication (1 page) and European Search Report for Application No. EP 00 12 8346 (3 pages), (Mailed Aug. 24, 2001).Applicant
Cormen, T. H., et al., “Introduction to Algorithms”, The MIT Press, Cambridge, Massachusetts, (1994), 219-243, 991-993.Applicant
Crovella et al., Dynamic server selection in the Internet, 3rd IEEE Workshop on the Arch. and Implementation of High Performance Computer Sys. '95, pp. 158-162, Aug. 1995.Applicant
Danzig, P. B., et al., “An analysis of wide-area name server traffic: a study of the Internet Domain Name System,” Conf. Proc. Communications Architectures & Protocols (Aug. 1992). D. Oran, Ed. SIGCOMM '92. ACM Press, New York, NY, 281-292.Applicant
De Bra, P.M.E., et al., “Information Retrieval in the World Wide Web: Making Client-Based Searching Feasible”, Computer Networks and ISDN Systems, NL, North Holland Publishing, Amsterdam, vol. 27, No. 2, ISSN: 0169-7552, (Nov. 1, 1994), 183-192.Applicant
Deering, S. E., et al, “Multicast routing in datagram internetworks and extended LANs,” ACM Trans. Comput. Syst. 8, 2 (May 1990), 85-110.Applicant
Devine, R., “Design and Implementation of DDH: A Distributed Dynamic Hashing Algorithm”, In Proc. 4th Int'l Conf. on Foundations of Data Organizations and Algorithms, (1993), 101-114.Applicant
Doi, K. “Super Proxy Script—How to make distributed proxy servers by URL hashing,” Sharp Corp., http://naragw.sharp.co.jp/sps/, dates unknown (1996-2000), download Jul. 7, 2007.Applicant
Feeley, M., et al., “Implementing Global Memory Management in a Workstation Cluster”, In Proc. 15th ACM Symp. on Operating Systems Principles, (1995), 201-212.Applicant
Floyd, S., et al., “A Reliable Multicast Framework for Light-Weight Sessions and Application Level Framing”, In Proc. of ACM SIGCOMM '95, 342-356, Aug. 1995.Applicant
Fox, A., “A Framework for Separating Server Scalability and Availability from Internet Application Functionality,” PhD thesis, University of California, Berkeley, 1998.Applicant
Fox, A., et al,, “Cluster-based scalable network services”, Proc. 16th ACM Symp. on Operating Systems Principles (Saint Malo, France, Oct. 5-8, 1997). W. M. Waite, Ed. SOSP '97. ACM Press, New York, NY, 78-91.Applicant
Fredman, M., et al., “Storing a Sparse Table with 0(1) Worst Case Access Time”, J. ACM, vol. 31, No. 3, (Jul. 1984), 538-544.Applicant
Goldszmidt, et al., “Load Distribution for Scalable Web Servers: Summer Olympics 1996—A Case Study,” In Proc. 8th IFIP/IEEE Int'l Workshop on Distributed Systems: Operations and Management, Sydney, Australia, Oct. 1997.Applicant
Grigni, M., et al., “Tight Bounds on Minimum Broadcasts Networks”, SIAM J. Disc. Math. 4 (1991), 207-222.Applicant
Gulbrandsen, A., et al., “A DNS RR for specifying the location of services (DNS SRV)”, Network Working Group, RFC 2052, Oct. 1996.Applicant
Guyton et al., “Locating nearby copies of replicated Internet servers,” Proc. ACM SIGCOMM '95, pp. 288-298, 1995.Applicant
Gwertzman, J., et al., “The Case for Geographical Push-Caching”, Proc. Workshop on Hot OS '95, (May 4, 1995), 51-55.Applicant
Gwertzman, J., et al., “World-Wide Web Cache Consistency”, Proc. 1996 USENIX Tech. Conf., pp. 141-151, San Diego, CA, Jan. 1996.Applicant
International Search Report dated Jun. 8, 1999 for PCT/US99/01477.Applicant
Jeffrey et al., Proxy-Sharing Proxy Servers, IEEE, pp. 116-119, 1996.Applicant
Karger, D., et al., “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”, in Proc. 29th Annual ACM Symp. on Theory of Computing, (May 1997), 654-663.Applicant
Kwan et al., NCSA's World Wide Web Server: Design and Performance, IEEE, pp. 68-74, Nov. 1995.Applicant
Litwin, W., et al., “LH*—A Scalable, Distributed Data Structure”, ACM Trans. on Database Systems, vol. 21, No. 4, pp. 480-525, 1996.Applicant
Luotonen et al., World-Wide Web Proxies, CERN, Apr. 1994 (modified May 24, 1994).Applicant
Malpani, R., et al., “Making World Wide Web Caching Servers Cooperate”, in Proc. 4th Int'l. World Wide Web Conf. (Dec. 1995), 10 pages (downloaded from http://www.w3.org/Conferences/WWW4/Papers/59/ on Jul. 7, 2007).Applicant
Mockapetris et al., “Development of the Domain Name System,” Proc. SIGCOMM '88 Computer Communications Review, vol. 18, No. 4, Aug. 1988.Applicant
Mockapetris, P., RFC 1034: Domain Names—Concepts and Facilities, Nov. 1987.Applicant
Mockapetris, P., RFC 1035: Domain Names—Implementation and Specification, Nov. 1987.Applicant
Mourad et al., “Scalable Web Server Architectures,” iscc, 2nd IEEE Symposium on Computers and Communications (ISCC '97), 1997, pp. 12-16.Applicant
Nisan, N. 1990. Pseudorandom generators for space-bounded computations. In Proc. 22nd Annual ACM Symp. on theory of Computing (Baltimore, MD, U.S., May 13-17, 1990). H. Ortiz, Ed. STOC '90. ACM Press, New York, NY, 204-212.Applicant
Oguchi et al., A Study of Caching Proxy Mechanisms Realized on Wide Area Distributed Networks, High Performance Distributed Computing, 5th Int'l Symposium, pp. 443-449, 1996.Applicant
Palmer, M., et al., “Fido: A Cache that Learns to Fetch”, In Proc. the 17th Int'l Conf. on Very Large Data Bases, (Sep. 1991), 255-264.Applicant
Panigrahy, R., “Relieving Hot Spots on the World Wide Web”, Master's thesis, MIT EECS, Jun. 1997, pp. 1-66.Applicant
Peleg D., et al., “The Availability of Quorum Systems,” Tech. Rep. CS93-17, The Weizmann Institute of Science, Rehovot, Israel, 1993.Applicant
Peleg, D., et al., “The Availability of Quorum Systems”, Information and Computation, 123, (1995), 210-223.Applicant
Petri S., et al., “Load Balancing and Fault Tolerance in Workstation Clusters. Migrating Groups of Communicating Processes.”, Operating Systems Review, vol. 29, No. 4, Oct. 1995, pp. 25-36.Applicant
Plaxton, G. C., et al., “Fast Fault-Tolerant Concurrent Access to Shared Objects”, In Proc. 37th IEEE Symp. of Foundations of Computer Science, (1996), 570-579.Applicant
Postel, RFC 1591—Domain Name System Structure and Delegation, Mar. 1994.Applicant
Rabin, M. O., 1989, “Efficient dispersal of information for security, load balancing, and fault tolerance,” J. ACM 36, 2 (Apr. 1989), 335-348.Applicant
Ross, K.W., “Hash-Routing for Collections of Shared Web Caches”, IEEE Network Magazine, 11, 7:37-44, Nov.-Dec. 1997.Applicant
Schemers, R., “Ibnamed—A load balancing name server written in Perl,” 1995 Lisa IX—Sep. 17-22, 1995—Monterey, CA.Applicant
Schuba, Christoph; “Addressing Weaknesses in the Domain Name System Protocol,” COAST Laboratory, Dept. of Computer Sciences, Purdue University; West Layfayette, IN; Aug. 1993, p. 1-87.Applicant
Smith, “What can Archives offer the World Wide Web?”, Technical Report 11, University of Kent, Computing Laboratory, University of Kent, Canterbury, UK, 1994.Applicant
Tarjan, Robert E., et al., “Storing a Sparse Table”, Commun.ACM, 22, 11, (Nov. 1979), 606-611.Applicant
Thaler, D. G. and Ravishankar, C. V. 1998. Using name-based mappings to increase hit rates. IEEE/ACM Trans. Netw. 6, 1 (Feb. 1998), 1-14.Applicant
Vitter, J. S., et al., “Optimal Prefetching via Data Compression,” Proc. 32nd Annual IEEE Symposium on Foundations of Computer Science (Oct. 1991).Applicant
Vixie, Paul; “Name Server Operations Guide for BIND,” Internet Software Consortium; La Honda, CA; p. SMM:10-2--SMM:10-30 (undated, 1996).Applicant
Wessels, Intelligent Caching for World-Wide Web Objects, Masters Thesis, University of Colorado, 1995.Applicant
Yao, A. C. 1981. Should Tables Be Sorted?. J. ACM 28, 3 (Jul. 1981), 615-628.Applicant
“Cisco DistributedDirector,” Cisco Systems, Inc., White Paper.Applicant
Almeroth, K., et al. “Scalable Delivery of Web Pages Using Cyclic Best-Effort (UDP) Multicast”, IEEE INFOCOM, San Francisco, California, USA, Jun. 1998.Applicant
Almeroth, K., Exhibit A to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008, [31 pages].Applicant
Almeroth, K., Exhibit B to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [131 pages].Applicant
Almeroth, K., Exhibit C to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [157 pages].Applicant
Almeroth, K., Exhibit D to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [128 pages].Applicant
Almeroth, K., Exhibit E Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [286 pages].Applicant
Almeroth, K., Exhibit F to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct, E.D. Va., dated Jul. 25, 2008 [221 pages].Applicant
Almeroth, K., Exhibit G to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [369 pages].Applicant
Almeroth, K., Exhibit H to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [59 pages].Applicant
Almeroth, K., Exhibit I to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [95 pages].Applicant
Almeroth, K., Exhibit J to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008, [105 pages].Applicant
Almeroth, K., Exhibit K-1 to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008, [152 pages].Applicant
Almeroth, K., Exhibit K-2 to Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008 [25 pages].Applicant
Almeroth, K., Expert Report of Dr. Kevin C. Almeroth filed in Civil Action No. 2:07cv589 (RGD-FBS), U.S. Dist. Ct. E.D. Va., dated Jul. 25, 2008. [64 pages and Exhibits A-J, K1, K2].Applicant
Baentsch, M., et al., “Introducing Application-Level Replication and Naming into Today's Web,” Computer Networks and ISDN Systems, vol. 28, No. 7-11, pp. 921-930, May 1996.Applicant
Berners-Lee, T. & Connolly, D., “Hypertext Markup Language-2.0,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1866, Nov. 1995.Applicant
Berners-Lee, T., et al., “Hypertext Transfer Protocol—HTTP/1.0,” Internet Engineering Task Force (IETF) Internet Draft, draft-ietf-http-v10-spec-00.ps, Mar. 1995.Applicant
Berners-Lee, T., et al., “Hypertext Transfer Protocol—HTTP/1.0,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1945, May 1996.Applicant
Berners-Lee, T.. “Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1630, Jun. 1994.Applicant
Bestavros, A. Demand-based document dissemination to reduce traffic and balance load in distributed information systems. In Proc. IEEE Symp. on Parallel and Distributed Processing, San Antonio, TX, Oct. 1995.Applicant
Callon, R., “Use of OSI IS-IS for Routing in TCP/IP and Dual Environments,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1195, Dec. 1990.Applicant
Chandra, R. et al., “BGP Communities Attribute,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1997, Aug. 1996.Applicant
Chen, E., et al., “An Application of the BGP Community Attribute in Multi-home Routing,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1998, Aug. 1996.Applicant
Claims of European Patent No. 1 143 337 B allowed/maintained in oral proceedings, Apr. 24, 2008 [7 pages].Applicant
Colajanni, M., et al., “Scheduling Algorithms for Distributed Web Servers,” International Conf. on Distributed Computing Systems (ICDCS), Baltimore, Maryland, USA, May 1997.Applicant
Communication from European Patent Office dated Feb. 8, 2007 regarding opposition to European Patent No. 1 143 337 B [11 pages].Applicant
Communication from European Patent Office dated May 30, 2008 in patent application EP 99906680 (12 pages).Applicant
Eriksson, H., “MBONE: The Multicast Backbone,” Communications of the ACM, vol. 37, No. 8, p. 54-60, Aug. 1994.Applicant
Fielding, R., et al., “Hypertext Transfer Protocol—HTTP/1.1,” Internet Engineering Task Force (IETF) Internet Draft, draft-ietf-http-v11-spec-00.txt, Nov. 1995.Applicant
Fielding, R., et al., “Hypertext Transfer Protocol—HTTP/1.1,” Internet Engineering Task Force(IETF) Request for Comments (RFC) 2068, Jan. 1997.Applicant
Malkin, G., “RIP Version 2 Carrying Additional Information,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1388, Jan. 1993.Applicant
Moy, J., “OSPF Version 2,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1583, Mar. 1994.Applicant
Notice of Opposition to a European Patent filed against European Patent No. 1 143 337 B, by Akamai Technologies, Inc., Apr. 23, 2004 [5 pages].Applicant
Owner's Response of Apr. 10, 2007 to summons to attend oral proceedings dated Feb. 8, 2007 in Opposition Procedure of European Patent No. 1 143 337 B, including auxiliary requests 1 and 2 and attachment discussing claim features [26 pages].Applicant
Owner's Response of Mar. 20, 2008 to summons to attend oral proceedings dated Jan. 24, 2008 in Opposition Procedure of European Patent No. 1 143 337 B, including auxiliary requests 3 to 7 [21 pages].Applicant
Parris C., et al, “A Dynamic Connection Management Scheme for Guaranteed Performance Services in Packet-Switching Integrated Services Networks,” UC Berkeley Computer Science Division Tech. Report TR-93-005, 1993.Applicant
Parris C., et al, “The Dynamic Management of Guaranteed Performance Connections in Packet Switched Integrated Service Networks,” UC Berkeley Computer Science Division and International Computer Science Institute Tech. Report CSD-94-859, 1994.Applicant
Partridge, C., et al., “Host Anycasting Service,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1546, Nov. 1993.Applicant
Povey, D. et al., “A distributed internet cache,” in Proc. of the 20th Australasian Computer Science Conf., Feb. 1997.Applicant
Rekhter Y., et al., “A Border Gateway Protocol 4 (BGP-4),” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1771, Mar. 1995.Applicant
Rekhter Y., et al., “Application of the Border Gateway Protocol in the Internet,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1772, Mar. 1995.Applicant
Reply of Dec. 21, 2004 of the Patent Proprietor to the Notice of Opposition of European Patent No. 1 143 337 B, Responsive to the Notice of Opposition of Akamai Technologies, Inc. dated Apr. 23, 2004 [11 pages].Applicant
Statement of Opposition to European Patent No. 1 143 337 B, filed by Akamai Technologies, Inc. Apr. 23, 2004 [43 pages].Applicant
Topolcic, C., “Experimental Internet Stream Protocol, Version 2 (ST-II),” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1190, Oct. 1990.Applicant
Touch, J. et al., “The X-Bone,”. Third Global Internet Mini-Conference at Globecom '98. Sydney, Australia, Nov. 1998, pp. 59-68 (pp. 44-52 of the mini-conference).Applicant
Traina, P., “BGP-4 Protocol Analysis,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1774, Mar. 1995.Applicant
Traina, P., “Experience with the BGP-4 protocol,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1773, Mar. 1995.Applicant
Wessels, D. et al., RFC 2187, “Application of Internet Cache Protocol (ICP), Version 2”, Sep. 1997, Memo; Internet RFC/STD/FYI/BCP Archives; Network Working Group.Applicant
Written Submissions in Opposition to European Patent No. 1 143 337 B, by Akamai Technologies, Inc., Apr. 5, 2007 [5 pages].Applicant
Amended Answer of Defendant Limelight Networks, Inc., Exhibit 1 to Defendant Limelight Network Inc.'s Combined Motion for Leave to Amend Its Answer and to Compel Related Interrogatory Responses, in Civil Action No. 2:07cv589, Sep. 9, 2008 [18 pgs].Applicant
Claim construction Opinion and Order in Civil Action No. 2:07:cv589, Dec. 10, 2008 [51 pages].Applicant
Communications from European Patent Office in European Patent Application No. 99 906 680.6: Minutes of Oral Hearing of Nov. 20, 2008, including auxiliary requests; and Invitation under Art. 94(3) and Rule 71(1) EPC (dated Dec. 11, 2008) to amended dependent claims. [32 pgs.].Applicant
Declaration Kevin C. Almeroth in Support of Limelight Networks, Inc.'s Motion for Summary Judgment of Non-Infringement and Invalidity of All Patents-In-Suit, filed Aug. 28, 2008 in Civil Action No. 2:07cv589 (RGD-FBS) [39 pgs.].Applicant
Defendant Limelight Network Inc.'s Combined Motion for Leave to Amend Its Answer and to Compel Related Interrogatory Responses, in Civil Action No. 2:07cv589, Sep. 9, 2008 [4 pgs].Applicant
Defendant Limelight Network Inc.'s Memorandum of Points and Authorities in Support of Its Combined Motion for Leave to Amend Its Answer and to Compel Related Interrogatory Responses (Public Version), in Civil Action No. 2:07cv589, Sep. 9, 2008 [18 pgs.].Applicant
Defendant Limelight Network Inc.'s Memorandum of Points and Authorities in Support of its Combined Motion For Leave To Amend Its Answer And To Compel Related Interrogatory Responses, (Public Version, redacted) filed Sep. 9, 2008, in civil action No. 2:07-cv-00589-RGD-FBS.Applicant
Defendant Limelight Network Inc.'s Rebuttal Brief in Support of Its Combined Motion for Leave to Amend Its Answer and Compel Related Interrogatory Responses (Public version), filed Oct. 7, 2008 in civil action No. 2:07-cv-00589-RGD -FBS.Applicant
Defendant Limelight Network Inc.'s Supplemental Responses to Plaintiff's First Set of Interrogatories (Redacted), Apr. 21, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [46 pgs.].Applicant
Defendant Limelight Networks, Inc.'s Claim Construction Brief for U.S. Patent Nos. 6,654,807; 7,054,935; and 6,473,405, filed in Civil Action No. 2:07CV589 (RGD-FBS), Jun. 27, 2008 [38 pgs.].Applicant
Defendant Limelight Networks, Inc.'s Reply Brief in Support of Its Motion for Summary Judgment of Non-Infringement and Invalidity of All Patents-In-Suit, filed Oct. 1, 2008 in Civil Action No. 2:07cv589 (JBF-FBS) [21 pgs.].Applicant
Defendant Limelight Networks, Inc.'s Memorandum in Support of its Motion for Summary Judgment of Non-Infringement and Invalidity of all Patents-In-Suit, [Redacted] for Civil Action No. 2:07cv589 (RGF-FBS), Aug. 28, 2008.Applicant
Defendant Limelight Networks, Inc.'s Supplemental Responses to Plaintiff's First Set of Interrogatories (No. 2-4, 12-13, and 19) [Redacted], May 16, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [70 pgs.].Applicant
Defendant Limelight Networks, Inc.'s Supplemental Responses to Plaintiff's First Set of Interrogatories (Nos. 1-11, 13-14, 17 and 19-20, [redacted] Feb. 9, 2008, in civil action No. 2:07-cv-00589-RGD-FBS [101 pgs.].Applicant
Exhibit A to Level 3 Communications, LLC's Objections and Responses to Limelight Networks. Inc.'s First Set of Interrogatories, Apr. 21, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [68 pgs.].Applicant
Exhibit B to Level 3 Communications, LLC's Objections and Responses to Limelight Networks. Inc.'s First Set of Interrogatories, Apr. 21, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [20 pgs.].Applicant
Exhibits A-G of Plaintiff Level 3 Communications, LLC's Memorandum of Law in Opposition to Defendant Limelight Networks, Inc.'s Combined Motion for Leave to Amend Its Answer and to Compel Related Interrogatory Responses, Sep. 30, 2008, Civil Action No. 2:07cv589, (Exhibit A [7 pgs.], B [5 pgs.], C [47 pgs.], D [45 pgs.], E [7 pgs.], F [8 pgs.], G [5 pgs.]).Applicant
Exhibits A-V filed in support of Limelight Networks, Inc.'s Motion for Summary Judgment of Non-Infringement and Invalidity of All Patents-In-Suit, Aug. 28, 2008 in Civil Action No. 2:07cv589 (JBF-FBS) [277 pgs.].Applicant
Interlocutory Decision in Opposition proceedings for EPO Appln. No. 00 128 346.4-2211, Patent No. 1143337, Sep. 22, 2008.Applicant
Level 3 Communications Supplemental Exhibit A in Civil Action No. 2:07cv589 (JBF-FBS) [69 pgs.].Applicant
Level 3 Communications, LLC's Confidential Version of Its Opposition Brief to Defendant's Motion for Summary Judgment of Non-Infringement and Invalidity of All Patents-In-Suit, Sep. 17, 2008, filed in Civil Action No. 2:07cv589 (JBF-FBS) [33 pgs.].Applicant
Level 3 Communications, LLC's Non-Confidential Version of its Opposition Brief to Defendant's Motion for Summary Judgment of Non-Infringement and Invalidity of all Patents-In-Suit [Redacted], in Civil Action No. 2:07cv589 (JBF-FBS), Sep. 17, 2008.Applicant
Level 3 Communications, LLC's Objections and Answers to Defendant Limelight Networks, Inc.'s Sixth Set of Interrogatories, Feb. 9, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [9 pgs.].Applicant
Level 3 Communications, LLC's Objections and Answers to Defendant Limelight Networks, Inc.'s Third Set of Interrogatories, [redacted], Aug. 18, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [10 pgs].Applicant
Level 3 Communications, LLC's Objections and Responses to Limelight Networks. Inc.'s First Set of Interrogatories, [redacted] Apr. 21, 2008, in civil action No. 2:07-cv-00589-WDK-FBS [28 pgs].Applicant
Level 3 Communications, LLC's Second Supplemental Response to Limelight Networks, Inc.'s First Set of Interrogatories (No. 15), Nov. 2, 2008 in civil action No. 2:07-cv-00589-RGD-FBS [9 pgs.].Applicant
Level 3 Communications, LLC's Second Supplemental Response to Limelight Networks, Inc.'s First Set of Interrogatories (No. 4) [Redacted], Nov. 3, 2008 in civil action No. 2:07-cv-00589-RGD-FBS [8 pgs.].Applicant
Level 3 Communications, LLC's Supplemental Responses to Limelight Networks, Inc.'s First Set of Interrogatories (No. 10) [Redacted], Jun. 11, 2008 in civil action No. 2:07-cv-00589-RGD-FBS [6 pgs.].Applicant
Level 3 Communications, LLC's Supplemental Responses to Limelight Networks, Inc.'s First Set of Interrogatories (Nos. 14 and 15) [Redacted], May 30, 2008 in civil action No. 2:07-cv-00589-RGD-FBS [10 pgs.].Applicant
Level 3's Memorandum of Law in Reply to Limelight's Claim Construction Brief for U.S. Patent Nos. 6,654,807; 7,054,935; and 6,473,405, in Civil Action No. 2:07CV589, Jul. 3, 2008 [84 pgs.].Applicant
Level 3's Memorandum of Law in Reply to Limelight's Claim Construction Brief, in Civil File No. 2:07CV589, Jul. 3, 2008.Applicant
Memorandum of Law in Support of Level 3's Proposed Claim Constructions, from Case No. 2:07cv589 RDG FBS, Jun. 13, 2008.Applicant
Memorandum on Markman terms to: Judge Robert G. Doumar, Counsel for Level 3 Communications, Counsel for Limelight from: Court appointed technical expert, Professor Ellen W. Zegura Re: Definition of terms, in civil action No. 2:07-cv-00589-MSD-FBS, Level 3 Communications, LLC v. Limelight Networks, Inc. (Aug. 2008).Applicant
Minutes of Oral Proceedings Appin. No. 00 128 346.4-2211, Patent No. 1143337, Sep. 22, 2008.Applicant
Order from Judge Doumar in civil action No. 2:07-cv-00589-MSD-FBS, Level 3 Communications, LLC v. Limelight Networks, Inc. instructing Court-Appointed Expert, Professor Ellen W. Zegura Re: Definition of claim terms, Jul. 25, 2008, [2 pgs.].Applicant
Plaintiff Level 3 Communications, LLC's Memorandum of Law in Opposition to Defendant Limelight Networks, Inc.'s Combined Motion for Leave to Amend Its Answer and to Compel Related Interrogatory Responses, Sep. 30, 2008, Civil Action No. 2:07cv589, [31 pages].Applicant
Response to Summons of May 30, 2008 filed in European Patent Office for European Application No. 99 906 680.6 on Oct. 20, 2008.Applicant
Transcript of 30(b)(6) Deposition of Kevin F. Delgadillo, Tuesday, Sep. 9, 2008 in Civil Action No. 2:07cv589 [39 pages].Applicant
Transcript of Deposition of Maurice Andrew Collins, Sep. 9, 2008 in Civil Action No. 2:07CV589 [136 pgs.].Applicant
Opinion and Order from U.S. District Judge Mark. S. Davis in Civil Action No. 2:07cv589, denying Defendant LimeLight Networks Inc.'s Motion for Summary Judgment, Norfolk, VA, Dec. 29, 2008.Applicant
Answer of Defendant Limelight Networks, Inc. In Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.) Feb. 1, 2008 [14 pgs.].Applicant
Answering Report of Scott Bradner Pursuant to Fed. R. Civ. 26 (a)(2)(B) Concerning the Validity of U.S. Patent Nos. 7,054,935 and 6,654,807, in Civil Action No. 2:07CV589 (RGD-FBS) (E.D. Va.), Aug. 25, 2008 [83 pgs.].Applicant
Defendant Limelight Network Inc.'s Rebuttal Brief in Support of Its Combined Motion for Leave to Amend Its Answer and Compel Related Interrogatory Responses (Public version), filed Oct. 7, 2008 in civil action No. 2:07-cv-00589-MSD-FBS [21 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 205, doc. titled “Leapfrog Project Overview,” Andrew Swart, Aug. 29, 1996 [2 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 206, doc. titled “Leapfrog Management Meeting Agenda,” Oct. 1, 1996 [1 pg.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 207, letter from Andrew D. Swart, Sandpiper Networks to Jean-Claude Asscher, Feb. 25, 1997 [2 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 209, email from David A. Farber sent Apr. 19, 1999 [5 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 210, email from Andrew Swart sent Apr. 24, 1999 [2 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 211, email from Will Crowder sent May 6, 1999 [10 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 212, email from Rick Greer sent Sep. 20, 1999 [11 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 213, email from Mike Warren sent Feb. 25, 2000 [3 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 216, email from “Andrew” sent Nov. 30, 1999 [7 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 219, email from “Andrew” sent Sep. 24, 1996 [3 pgs.].Applicant
Deposition of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 220, document titled “Statement of Opposition, European Patent No. 1 143 337 B”, Apr. 23, 2004 [41 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 154, email [4 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 155, document titled “WebRepeater™ Functional Requirements,” Dave Farber, Sandpiper Software Consulting, LLC, Jun. 18, 1996. [20 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 156 doc. titled “Project Status Meeting Reports,” Aug. 4, 1997 [3 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 157, copy of parts of U.S. Appl. No. 09/021,506 from PTO [68 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 158, documents from PTO file for U.S. Appl. No. 09/612,598 [59 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 159, email from Dave Farber sent Mar. 14, 1997 [12 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 160, email from “Andrew” sent Jan. 15, 1997 [3 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 161, email from “Will”, sent Oct. 17, 1997 [24 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 162, email from Rick Greer sent Jan. 20, 1999 [7 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 163, email from “Andrew” sent Jul. 22, 1996 [2 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 164, copy of European Patent No. 1 143 337 (WO 99/40514) [64 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 165, copy of European Patent Specification No. 1 143 337 [31 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 166, email from Will Crowder sent Aug. 24, 1997 [1 pg.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 167, email from Chris Newton sent Oct. 26, 2000 [7 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 168, document titled “Sandpiper Raises $6.6 Million to Boost Content Distribution for Web Publishers,” May 19, 1998 [2 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 169 document titled “Sandpiper Launches Footprint Distribution Service to Improve Web Site Performance; Cost-Effective Service Manages Content Delivery for Web Publishers,” Sep. 28, 1998 [3 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 170 document titled “Sandpiper Completes New Executive Management Team; Sandpiper Poised for Growth with Strong Executive Team,” Sep. 28, 1998 [2 pgs.].Applicant
Deposition of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Exhibit 171 document titled “Sandpiper Addresses Web Content Management Problems At Herring on Hollywood;—New Technology Company Offers Solutions to Entertainment Industry's Internet Woes,” Sep. 28, 19.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 10, email from David A. Farber, Jan. 11, 1999 [4 pgs.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 11, copy of U.S. Pat. No. 6,185,598 [23 pgs.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 12, email from David A. Farber, Jan. 18, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 13, email from Will Crowder, Feb. 17, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 155 document titled “WebRepeater™ Functional Requirements,” Dave Farber, Sandpiper Software Consulting, LLC, Jun. 18, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 16 email from Will Crowder, May 6, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 166, email from Will Crowder, Aug. 24, 1997.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 19, email from David A. Farber, May 12, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 2, email from Dave Farber dated Oct. 15, 1997 [2 pgs.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 22, document titled “Patent Claim: Resource Request Redirector,” Dave Farber, Sandpiper Software Consulting, LLC, Draft 3, May 24, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 226, email from Peggy Balesteri, Aug. 7, 2008.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 227, email from Dave Farber, May 29, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 228, email from “Dave” dated Jul. 12, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 229, email from “Andrew” dated Jul. 22, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 230, email from “Dave” dated Jul. 10, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 231, document titled “Patent Claim: Network Reflector/Repeater,” Dave Farber, Sandpiper Software Consulting, LLC, Draft 5, Jul. 2, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 232, document titled “WebRepeater Features Comparison”, Sandpiper Software Consulting, Sep. 17, 1996.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 233, email from “Hussain” sent Sep. 19, 1998.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 234, email from “Scott” sent May 30, 1998.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 235, email from “Andrew” sent Feb. 12, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 236, email from David A. Farber sent Apr. 19, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 237, email from David A. Farber sent May 12, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 238, email from David A. Farber sent May 6, 1999 [1 pg.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 239, document titled “Footprint DNS Server Mini-Specification,” Will Crowder, Apr. 23, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 240, email from “David” sent Jun. 4, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 241, email from David A. Farber sent Dec. 6, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 242, email from Chris Newton, sent Oct. 26, 2000.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 243, email from “Andrew” sent Jul. 24, 2000.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 244, email from Andrew Swart sent Nov. 12, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 245, email from Andrew Swart sent Aug. 23, 2002.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 246, email from “Jim” sent Dec. 16, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 247, email from “Jim” sent Nov. 17, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 248, email from “Jim” sent Nov. 17, 1999.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 249, email from Will Crowder sent Dec. 21, 1998.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 250, email from Chris Newton sent Feb. 15, 2000.Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 5, copy of U.S. Pat. No. 6,654,807 [28 pgs.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 6, U.S. Pat. No. 7,054,935 [14 pgs.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 7, email from David A. Farber, Dec. 21, 1998 [2 pgs•].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 8, email from David A. Farber, Jan. 11, 1999 [1 pg.].Applicant
Deposition of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 9, email from Jim Baiter, Apr. 19, 1999 [4 pgs.].Applicant
Deposition of James A. Balter in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Deposition Exhibit 1, Subpoena in Civil Case [10 pgs.].Applicant
Deposition of James A. Balter in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Deposition Exhibit 2, email from Dave Farber dated Oct. 15, 1997 [2 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 10, email from David A. Farber dated Jan. 11, 1999 [4 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 11, copy of U.S. Pat. No. 6,185,598 [23 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 12, email from David A. Farber dated Jan. 18, 1999 [ 4 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 13, email from Will Crowder dated Feb. 17, 1999 [9 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 14, email from Jim Balter dated Sep. 8, 2000 [3 pgs].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 15, email from Will Crowder dated May 12, 1999 [2 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 16, email from Will Crowder dated May 6, 1999 [2 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 17, email from Will Crowder dated Apr. 22, 1999 [9 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 18, email from Jim Baiter dated Apr. 22, 1999 [1 pg.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 19, email from David A. Farber dated May 12, 1999 [1 pg.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 20, email from [email protected] dated Nov. 25, 1997 [3 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 21, document titled “Patent Claim: HTTP Redirector” Draft 2, May 20, 1996, Dave Farber, Sandpiper Software Consulting, LLC [11 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 22, document titled “Patent Claim: Resource Request Redirector,” Dave Farber, Sandpiper Software Consulting, LLC, Draft 3, May 24, 1996 [17 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 23, document titled “Patent Claim: Network Reflector/Repeater,” Dave Farber, Sandpiper Software Consulting, LLC, Draft 5, Jul. 2, 1996 [21 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 24, document titled “Software Design Specification: Advanced Rewrite Tool,” J. Balter, Dec. 3, 1999, Sandpiper Networks, Inc.Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 3, email from Andrew Swart dated Apr. 1, 1998 [1 pg.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 4, email from Rick [Richard] Greer dated Dec. 14, 1998 [6 pgs].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 5, copy of U.S. Patent No. 6,654,807 [28 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 6, copy of U.S. Patent No. 7,054,935 [24 pgs.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 7, email from David A. Farber dated Dec. 21, 1998 [2 pg.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 8, email from David A. Farber dated Jan. 11, 1999 [1 pg.].Applicant
Deposition of James A. Balter, Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Aug. 8, 2008, Depo. Exhibit 9, email from Jim [James] Balter dated Apr. 19, 1999 [4 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 11, copy of U.S. Pat. No. 6,185,598 [23 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 12, email from David A. Farber sent Jan. 18, 1999 [4 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 195, document titled “Web Repeater” (Interactive Systems Corporation), Sandpiper Software, Nov. 23, 1996, [80 pgs].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 196, Subpoena in Civil Case 2:07cv589 RGD/FBS (E.D. Va.), Jun. 19, 2008 [10 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 197, email from Rick Greer sent Feb. 18, 1999 [3 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 198, email from Rick Greer sent Jan. 20, 1999 [7 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 199, email from [email protected] sent Oct. 9, 1998.Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 200 email from [email protected] sent Oct. 2, 1998 [2 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 201, email from Will Crowder sent Dec. 21, 1998 [2 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 202, email from [email protected] sent Nov. 20, 2000 [2 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 203, mail from David A. Farber sent Nov. 3, 1999 [1 pg.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 4, email from Rick Greer sent Dec. 14, 1998 [6 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 5, copy of U.S. Pat. No. 6,654,807 [28 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 6, copy of U.S. Pat. No. 7,054,935 [24 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 7, email from David A. Farber sent Dec. 21, 1998 [2 pgs.].Applicant
Deposition of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.), Depo. Exhibit 8, email from David A. Farber sent Jan. 11, 1999 [4 pgs.].Applicant
Deposition Transcript of Andrew D. Swart, Aug. 21, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.) [redacted, 98 pgs.].Applicant
Deposition Transcript of Andrew D. Swart, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.) [redacted, 78 pgs.].Applicant
Deposition transcript of David A. Farber, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.) [87 pgs.].Applicant
Deposition Transcript of James A. Balter, August 8, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.) [69 pgs.].Applicant
Deposition transcript of Richard E. Greer, Sep. 3, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) (E.D. Va.) [79 pgs.].Applicant
Exhibit A to Reply and Supplemental Report of Dr. Kevin C. Almeroth to the Answering Report of Scott Bradner, in Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.) Sep. 5, 2008 [14 pgs.].Applicant
Exhibit B to Reply and Supplemental Report of Dr. Kevin C. Almeroth to the Answering Report of Scott Bradner, in Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.) Sep. 5, 2008 [12 pgs.].Applicant
Exhibit C to Reply and Supplemental Report of Dr. Kevin C. Almeroth to the Answering Report of Scott Bradner, in Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.) Sep. 5, 2008 [12 pgs.].Applicant
Exhibit D to Reply and Supplemental Report of Dr. Kevin C. Almeroth to the Answering Report of Scott Bradner, in Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.) Sep. 5, 2008 [13 pgs.].Applicant
Joint Statement Regarding Claim Construction with Exhibit “The '807 and '935 Footprint Patents,” in Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.), filed Jul. 9, 2008 [27 pgs.].Applicant
Jury Verdict Form in Civil Action No. 2:07cv589 (MSD-FBS), Jan. 23, 2009 [3 pgs.].Applicant
Level 3 Markman Presentation Powerpoint, in Civil Action No. 2:07cv589, Jul. 9, 2008 [16 pgs.].Applicant
Level 3's Motion for Judgment As a Matter of Law or, in the Alternative, for a New Trial Pursuant to Rules 50(B) and 59(A), in Civil File No. 2:07CV589 (E.D. Va.), Feb. 9, 2009 [3 pgs.].Applicant
Level 3's Reply in Further Support of Its Motion for Judgment As a Matter of Law or, in the Alternative, for a New Trial Pursuant to Rules 50(B) and 59(A), Mar. 12, 2009, in Civil Action No. 2:07cv589 (MSD-FBS) (E.D. Va.) [22 pgs.].Applicant
Limelight Claim Construction Hearing Presentation, in Civil Action No. 2:07cv589, Jul. 14, 2008 [123 pgs.].Applicant
Limelight's Opposition to Level 3's Motion for Judgment As a Matter of Law or, in the Alternative, for a New Trial Pursuant to Rules 50(B) and 59(A), Mar. 2, 2009, in Civil Action No. 2:07cv589 (MSD-FBS) (E.D. Va.) [31 pgs.].Applicant
Reply and Supplemental Report of Dr. Kevin C. Almeroth to the Answering Report of Scott Bradner, in Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.) Sep. 5, 2008 [62 pgs.].Applicant
Second Supplemental Expert Report of Dr. Kevin C. Almeroth Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.) Dec. 24, 2008 [9 pgs.].Applicant
Supplemental Answering Report of Scott Bradner Pursuant to Fed. R. Civ. 26(a)(2)(B) Concerning the Validity of U.S. Patent No. 6,654,807 Civil Action No. 2:07CV589 (RGD-FBS) (E.D. Va.) Dec. 10, 2008 [28 pgs.].Applicant
Transcript of Proceedings for Jury Trial, Norfolk, VA, Jan. 7 to 23, 2009, in Civil Action No. 2:07cv589 (E.D. Va.) [1052 pgs.].Applicant
Transcript of Proceedings for Markman Follow-up Hearing, Norfolk, VA, Oct. 23, 2008, in Civil Action No. 2:07cv589 (E.D. Va.) [58 pgs.].Applicant
Transcript of Proceedings for Markman Hearing, Norfolk, VA, Jul. 14, 2008, in Civil Action No. 2:07cv589 (E.D. Va.) [69 pgs.].Applicant
U.S. P.T.O. Non-Final Office Action in U.S. Appl. No. 11/980,689, May 20, 2009.Applicant
U.S. P.T.O. Office Action in U.S. Appl. No. 11/980,684, May 19, 2009.Applicant
Combined Petition for Panel Rehearing or Rehearing En Banc, U.S. Ct. Appeals for Federal Circuit, Level 3 Communications LLC vs. Limelight Networks, Inc., 2009-1480, Jun. 4, 2010 [22 pgs.].Applicant
Communication dated Apr. 27, 2010 from European Patent Office re Opposition to European Patent application No. (99906680.6-2211) Patent No. 1 053 524 B [1 pg.].Applicant
Exhibit 56 to Deposition of Maurice Andrew Collins in Civil Action No. 2:07cv589 (WDK-FBS), “Defendant Limelight Networks, Inc.'s Notice of Deposition of Andrew Collins,” Aug. 29, 2008 [28 pgs.].Applicant
Exhibit 57 to Deposition of Maurice Andrew Collins in Civil Action No. 2:07cv589 (WDK-FBS), Document titled “Detour: Informed Internet Routing and Transport,” Savage, et al., IEEE Micro, vol. 19, issue 1, p. 50-59, Jan./Feb. 1999 [10 pgs.].Applicant
Exhibit 58 to Deposition of Maurice Andrew Collins in Civil Action No. 2:07cv589 (WDK-FBS), document titled Internet Archive Wayback Machine, sample search Sep. 9, 2008 [1 pg.].Applicant
Exhibit 59 to Deposition of Maurice Andrew Collins in Civil Action No. 2:07cv589 (WDK-FBS), Document titled “Detour,” deponent Collins, Sep. 9, 2008, [1 pg.].Applicant
Exhibit 65 to Deposition of Kevin F. Delgadillo, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS), Document titled Subpoena in a Civil Case [12 pgs.].Applicant
Exhibit 66 to Deposition of Kevin F. Delgadillo, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS), Document titled, “Cisco DistributedDirector,” [9 pgs.].Applicant
Exhibit 67 to Deposition of Kevin F. Delgadillo, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS), Document titled, “Electronic Publishing Form,” dated Nov. 27, 1996 [5 pgs.].Applicant
Exhibit 68 to Deposition of Kevin F. Delgadillo, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS), Email from Kevin Delgadillo, dated Jul. 19, 1996 [1 pg.].Applicant
Exhibit 69 to Deposition of Kevin F. Delgadillo, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS), Document titled, “Cisco Advantage: Leveraging Intranet and Internet Productivity.” [9 pgs.].Applicant
Letter from Chris Hirsz dated Apr. 22, 2010 to European Patent Office forwarding Statement of Opposition to European Patent No. 1 053 524 B In the name of Level 3 CDN International, Inc. filed in European Patent Office by Akamai Technologies, Inc., Apr. 22, 2004 [2 pgs.].Applicant
Limelight Networks Inc.'s Response to the Report of Professor Ellen W. Zegura, Sep. 5, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) [5 pgs.].Applicant
Notice of Abandonment from Canadian Intellectual Property Office for Canadian Patent Application No. 2,320,261 [1 pg.].Applicant
Office Action (Notice of Reasons for Rejection) in Japanese Patent Appln. No. 2007-212908, Mar. 30, 2010, JPO [3 pgs.] with summary English translation [3 pgs.].Applicant
Office Action dated Sep. 24, 2007 from Canadian Intellectual Property Office for Canadian Patent Application No. 2,320,261 [5 pgs.].Applicant
Office Action dated Sep. 28, 2006 from Canadian Intellectual Property Office for Canadian Patent Application No. 2,320,261 [4 pgs.].Applicant
Opening Brief of Appellant Level 3 Communications, LLC, U.S. Ct. Appeals for Federal Circuit, Level 3 Communications LLC vs. Limelight Networks, Inc., 2009-1480, Oct. 5, 2009 [106 pgs.].Applicant
Opinion and Order from U.S. District Judge Mark. S. Davis in Civil Action No. 2:07cv589, ruling on Level 3 Communications, LLC's post-trial motions, Norfolk, VA, Jun. 23, 2009 [26 pgs.].Applicant
Reinstatement and Response, filed Apr. 24, 2009 in Canadian Intellectual Property Office for Canadian Patent Application No. 2,320,261 [18 pgs.].Applicant
Reply Brief of Appellant Level 3 Communications, LLC, U.S. Ct. Appeals for Federal Circuit, Level 3 Communications LLC vs. Limelight Networks, Inc., 2009-1480, Feb. 2, 2010 [41 pgs.].Applicant
Response Brief of Defendant-Appellee Limelight Networks, Inc., U.S. Ct. Appeals for Federal Circuit, Level 3 Communications LLC vs. Limelight Networks, Inc., 2009-1480, Jan. 19, 2010 [72 pgs.].Applicant
Response to Office Action, filed Mar. 28, 2007 in Canadian Intellectual Property Office for Canadian Patent Application No. 2,320,261 [24 pgs.].Applicant
Statement of Opposition to European Patent No. 1 053 524 B in the name of Level 3 CDN International, Inc. filed in European Patent Office by Akamai Technologies, Inc., Apr. 22, 2004 [40 pgs.].Applicant
Transcript of Deposition of Kevin C. Almeroth, Civil Action No. 2:07cv589 (RGD-FBS) (E.D. Va.), Sep. 11, 2008 (redacted) [98 pgs.].Applicant
Transcript of Federal Circuit Oral Argument, Level 3 Communications LLC vs. Limelight, Monday, May 3, 2010 [14 pgs.].Applicant
Transcript of Oral Argument, U.S. Ct. Appeals for Federal Circuit, Level 3 Communications LLC vs. Limelight, Monday, May 3, 2010 [14 pgs.].Applicant
Transcript of Proceedings, Hearing before Hon. Mark S. Davis, U.S. District Judge, in Civil Action No. 2:07cv589 (E.D. Va.), Oct. 23, 2008 [62 pgs.].Applicant
U.S. Ct. Appeals for Fed. Circuit, 2009-1490, Level 3 Communications, LLC v. Limelight Networks, Inc., Judgment Affirmed, Fed. Cir. R. 36, May 5, 2010 [2 pgs.].Applicant
Yokohashi, Takao, System Architectonic Solaris2.x, 26th, UNIX User, Japan, Softbank Corp., Jan. 1, 1998, vol. 7, No. 1, p. 89-96.Applicant
European Patent Office (EPO), European Search Report mailed Aug. 19, 2010 in European Appln. No. 08005349.9 [10 pgs.].Applicant
Akamai Tech., Inc. v. Cable & Wireless Internet Svs., Inc., 344 F.3d 1186, 68 USPQ2d 1186 (Fed. Cir. 2003) [Sep. 15, 2003].Applicant
“Memorandum in Support of Level 3's Motion in Limine to Preclude Limelight Witnesses from Referring to Prosecution History in Rendering Non-Infringement Opinions,” filed in Civil Action No. 2:07cv589 (MSD-FBS), U.S. Dist. Ct. E.D. Va., Jan. 15, 2009 [7 pgs.].Applicant
“Memorandum in Support of Limelight's Motion in Limine No. 7 to Exclude Testimony From Level 3's Experts Not Disclosed in Their Expert Reports Regarding The Disclosures of the Patents-In-Suit,” filed in Civil Action No. 2:07cv589 (MSD-FBS), U.S. Dist. Ct. E.D. Va., Dec. 4, 2008 [6 pgs.].Applicant
Level 3 Communications, LLC's Supplemental Responses to Limelight Networks, Inc.'s First Set of Interrogatories (No. 4), in civil action No. 2:07-cv-00589-RGD-FBS, in U.S. Dist. Ct. E.D. Va., Sep. 3, 2008 [8 pgs.].Applicant
Order denying Appellant's Petition for Panel Rehearing or Rehearing En Banc, U.S. Ct. Appeals for Federal Circuit, Level 3 Communications LLC vs. Limelight Networks, Inc., 2009-1480, Jun. 29, 2010 [2 pgs.].Applicant
Plaintiff Level 3 Communications, LLC'S Response to Defendant Limelight Networks, Inc.'s Response to Report of Professor Ellen Zegura, Sep. 9, 2008, in Civil Action No. 2:07cv589 (WDK-FBS) [5 pgs.].Applicant
Transcript of Proceedings (Motion for Summary Judgment), in Civil Action No. 2:07cv589 in U.S. Dist. Ct. E.D. Va., Norfolk, VA., Dec. 18, 2008, [145 pgs.].Applicant
European Patent Office (EPO) Summons to attend oral proceedings pursuant to Rule 115(1) EPC, dated Aug. 4, 2011, for European Patent No. 99906680.6, including accompanying communication (EPO Form 2906), “Facts & Submissions” [20 pgs.].Applicant
EPO, Annex to Minutes of the Oral Proceedings Before the Opposition Division, Claims of Main Request and new first (noted as IV) and second Auxiliary Request (noted as II), Apr. 24, 2012, European Application No. 99 906 680.6, patent No. EP-B-1053524 [22 pgs.].Applicant
EPO, Interlocutory Decision in Opposition Proceedings, Allowed text for re-granted patent, Apr. 24, 2012, European Application No. 99 906 680.6, patent No. EP-B-1053524, European patent No. EP-B-1 053 524 [29 pgs.].Applicant
EPO, Interlocutory Decision in Opposition Proceedings, Apr. 24, 2012, European Application No. 99 906 680.6, patent No. EP-B-1053524 [2 pgs.] and enclosures.Applicant
EPO, Interlocutory Decision in Opposition Proceedings, Grounds for Decision, Apr. 24, 2012, European Application No. 99 906 680.6, patent No. EP-B-1053524 [8 pgs.].Applicant
EPO, Minutes of the Oral Proceedings Before the Opposition Division, published Apr. 24, 2012, proceedings held Mar. 6, 2012, European Application No. 99 906 680.6, patent No. EP-B-1053524 [12 pgs.].Applicant
European Patent Office (EPO) Communication (examination report) dated Jun. 15, 2012 from EP08005349.9 [6 pgs.].Applicant
European Patent Office (EPO) Communication (search report) dated Jul. 4, 2012 from EP07024629.3 [4 pgs.].Applicant

Abstract

Description

Field of the Invention

[0002] This invention relates to replication of resources in computer networks.

Background of the Invention

[0010] Another solution, load balancing, takes into account the load at each server (measured in a variety of ways) to select which server should handle a particular request.

[0013] A number of companies offer products which improve network performance by prioritizing and filtering network traffic.

[0017] Proxy caches hide the activity of clients from publishers. Once a resource is cached, the publisher has no way of knowing how often it was accessed from the cache.

Summary of the Invention

[0019] If a requested resource contains references to other resources, some or all of these references can be replaced by references to repeaters.

[0021] The client gets the modified resource identifier from the reflector and makes a request for the particular resource from the repeater designated in the modified resource identifier.

Brief Description of the Drawings

[0029] FIG. 1 depicts a portion of a network environment according to the present invention; and

[0030] FIGS. 2-6 are flow charts of the operation of the present invention.

Detailed Description of the Presently Preferred Exemplary Embodiments

[0031] Overview

[0034] A client 106 connects, via the network 100, to origin server 102 and possibly to one or more repeaters 104a etc.

[0042] Uniform Resource Locators

[0048] scheme://host[:port]/url-path

[0050] For example, the following is a URL identifying a file “F” in the path “A/B/C” on a computer at “www.uspto.gov”:

[0051] http://www.uspto.gov/A/B/C/F

- [0055] A1. A browser (e.g., Netscape's Navigator) at the client receives a resource identifier (i.e., a URL) from a user.
- [0056] A2. The browser extracts the host (origin server) name from the resource identifier, and uses a domain name server (DNS) to look up the network (IP) address of the corresponding server. The browser also extracts a port number, if one is present, or uses a default port number (the default port number for http requests is 80).
- [0057] A3. The browser uses the server's network address and port number to establish a connection between the client 106 and the host or origin server 102.
- [0058] A4. The client 106 then sends a (GET) request over the connection identifying the requested resource.
- [0059] A5. The origin server 102 receives the request and
- [0060] A6. locates or composes the corresponding resource.
- [0061] A7. The origin server 102 then sends back to the client 106 a reply containing the requested resource (or some form of error indicator if the resource is unavailable). The reply is sent to the client over the same connection as that on which the request was received from the client
- [0062] A8. The client 106 receives the reply from the origin server 102.

[0064] System Operation

[0067] The reflector 108 supports the processing as follows (see FIG. 3):

[0068] upon receipt of a request,

- [0069] B1 The reflector 108 analyzes the request to determine whether or not to reflect the request. To do this, first the reflector determines whether the sender (client 106) is a browser or a repeater. Requests issued by repeaters must be served locally by the origin server 102. This determination can be made by looking up the network (IP) address of the sender in a list of known repeater network (IP) addresses. Alternatively, this determination could be made by attaching information to a request to indicate that the request is from a specific repeater, or repeaters can request resources from a special port other than the one used for ordinary clients.
- [0070] B2 If the request is not from a repeater, the reflector looks up the requested resource in a table (called the “rule base”) to determine whether the resource requested is “repeatable”. Based on this determination, the reflector either reflects the request (B3, described below) or serves the request locally (B4, described below).
  - [0071] The rule base is a list of regular expressions and associated attributes. (Regular expressions are well-known in the field of computer science. A small bibliography of their use is found in Aho, et al., “Compilers, Principles, techniques and tools”, Addison-Wesley, 1986, pp. 157-158.) The resource identifier (URL) for a given request is looked up in the rule base by matching it sequentially with each regular expression. The first match identifies the attributes for the resource, namely repeatable or local. If there is no match in the rule base, a default attribute is used. Each reflector has its own rule base, which is manually configured by the reflector operator.
- [0072] B3. To reflect a request, (to serve a request locally go to B4), as shown in FIG. 4, the reflector determines (B3-1) the best repeater to reflect the request to, as described in detail below. The reflector then creates (B3-2) a new resource identifier (URL) (using the requested URL and the best repeater) that identifies the same resource at the selected repeater.
  - [0073] It is necessary that the reflection step create a single URL containing the URL of the original resource, as well as the identity of the selected repeater. A special form of URL is created to provide this information. This is done by creating a new URL as follows:
- [0074] D1. Given a repeater name, scheme, origin server name and path, create a new URL. If the scheme is “http”, the preferred embodiment uses the following format:
  - [0075] http://<repeater>/<server>/<path>
- [0076] If the form used is other than “http”, the preferred embodiment uses the following format:
- [0077] http://<repeater>/<server>@proxy=<scheme>@/<path>
- [0078] The reflector can also attach a MIME type to the request, to cause the repeater to provide that MIME type with the result. This is useful because many protocols (such as FTP) do not provide a way to attach a MIME type to a resource. The format is
- [0079] http://<repeater>/<server>@proxy=<scheme>:<type>@/<path>
- [0080] This URL is interpreted when received by the repeater.
  - [0081] The reflector then sends (B3-3) a REDIRECT reply containing this new URL to the requesting client. The HTTP REDIRECT command allows the reflector to send the browser a single URL to retry the request.
- [0082] B4. To serve a request locally, the request is sent by the reflector to (“forwarded to”) the origin server 102. In this mode, the reflector acts as a reverse proxy server. The origin server 102 processes the request in the normal manner (A5-A7). The reflector then obtains the origin server's reply to the request which it inspects to determine if the requested resource is an HTML document, i.e., whether the requested resource is one which itself contains resource identifiers.
- [0083] B5. If the resource is an HTML document then the reflector rewrites the HTML document by modifying resource identifiers (URLs) within it, as described below. The resource, possibly as modified by rewriting, is then returned in a reply to the requesting client 106.
  - [0084] If the requesting client is a repeater, the reflector may temporarily disable any cache-control modifiers which the origin server attached to the reply. These disabled cache-control modifiers are later re-enabled when the content is served from the repeater. This mechanism makes it possible for the origin server to prevent resources from being cached at normal proxy caches, without affecting the behavior of the cache at the repeater.
- [0085] B6. Whether the request is reflected or handled locally, details about the transaction, such as the current time, the address of the requester, the URL requested, and the type of response generated, are written by the reflector to a local log file.

- [0087] the resource is composed uniquely for each request;
- [0088] the resource relies on a so-called cookie (browsers will not send cookies to repeaters with different domain names);
- [0089] the resource is actually a program (such as a Java applet) that will run on the client and that wishes to connect to a service Java requires that the service be running on the same machine that provided the applet).

[0091] A request which is reflected is automatically mirrored at the repeater when the repeater receives and processes the request.

[0093] Alternate Approach

[0096] For instance, if www.example.com is the origin server, names for three repeaters might be created:

[0097] wr1.example.com

[0098] wr2.example.com

[0099] wr3.example.com

[0100] The name “wr1.example.com” would be an alias for repeater 1, which might also be known by other names such as “wr1.anotherExample.com” and “wr1.example.edu”.

[0102] The repeater can use two mechanisms to determine by which alias it is addressed:

- [0103] 1. Each alias can be associated with a different IP address. Unfortunately, this solution does not scale well, as IP addresses are currently scarce, and the number of IP addresses required grows as the product of origin servers and repeaters.
- [0104] 2. The repeater can attempt to determine the alias name used by inspecting the “host:” tag in the HTTP header of the request. Unfortunately, some old browsers still in use do not attach the “host:” tag to a request. Reflectors would need to identify such browsers (the browser identity is a part of each request) and avoid this form of reflection.

[0105] How a Repeater Handles a Request

- [0107] C1. First the repeater analyzes the request to determine the network address of the requesting client and the path of the resource requested. Included in the path is an origin server name (as described above with reference to B3).
- [0108] C2. The repeater uses an internal table to verify that the origin server belongs to a known “subscriber”. A subscriber is an entity (e.g., a company) that publishes resources (e.g., files) via one or more origin servers. When the entity subscribes, it is permitted to utilize the repeater network. The subscriber tables described below include the information that is used to link reflectors to subscribers.
  - [0109] If the request is not for a resource from a known subscriber, the request is rejected. To reject a request, the repeater returns a reply indicating that the requested resource does not exist.
- [0110] C3. The repeater then determines whether the requested resource is cached locally. If the requested resource is in the repeater's cache it is retrieved. On the other hand, if a valid copy of the requested resource is not in the repeater's cache, the repeater modifies the incoming URL, creating a request that it issues directly to the originating reflector which processes it (as in B1-B6). Because this request to the originating reflector is from a repeater, the reflector always returns the requested resource rather than reflecting the request. (Recall that reflectors always handle requests from repeaters locally.) If the repeater obtained the resource from the origin server, the repeater then caches the resource locally.
  - [0111] If a resource is not cached locally, the cache can query its “peer caches” to see if one of them contains the resource, before or at the same time as requesting the resource from the reflector/origin server. If a peer cache responds positively in a limited period of time (preferably a small fraction of a second), the resource will be retrieved from the peer cache.
- [0112] C4. The repeater then constructs a reply including the requested resource (which was retrieved from the cache or from the origin server) and sends that reply to the requesting client.
- [0113] C5. Details about the transaction, such as the associated reflector, the current time, the address of the requester, the URL requested, and the type of response generated, are written to a local log file at the repeater.

[0114] Note that the bottom row of FIG. 2 refers to an origin server, or a reflector, or a repeater, depending on what the URL in step A1 identifies.

[0115] Selecting the Best Repeater

[0123] Tables may also be configured to provide selective repeater service to subscribers in other ways, e.g., for their clients in specific geographic regions, such as Europe or Asia.

[0124] Measuring Load

[0125] In the presently preferred embodiments, repeater load is measured in two dimensions, namely

[0126] 1. requests received by the repeater per time interval (RRPT), and

[0127] 2. bytes sent by the repeater per time interval (BSPT).

[0131] The factor B, a value between 0 and 1, allows the relative weights of RRPT and BSPT to be adjusted, which favors consideration of either processing power or bandwidth.

[0133] While the preferred embodiment uses a two-dimensional measure of repeater load, any other measure of load can be used.

[0134] Combining Link Costs and Load

[0136] The cost is determined using the following formula:
threshold=K*max-load
capacity=max(max-load−current-load, e)
capacity=min(capacity, threshold)
cost=link-cost*threshold/capacity

[0138] Given the cost of each candidate repeater, the BRS selects all repeaters within a delta factor of the best score. From this set, the result is selected at random.

[0140] Best Repeater Selector (BRS)

[0141] The BRS operates as follows, with reference to FIG. 6:

[0142] Given a client network address and the three tables described above:

- [0143] E1. Determine which group the client is in using the Group Reduction Table.
- [0144] E2. For each repeater in the Link Cost Table and Load Table, determine that repeater's combined cost as follows:
  - [0145] E2a. Determine the maximum and current load on the repeater (using the Load Table).
  - [0146] E2b. Determine the link cost between the repeater and the client's group (using the Link Cost Table).
  - [0147] E2c. Determine the combined cost as described above.
- [0148] E3. Select a small set of repeaters with the lowest cost.
- [0149] E4. Select a random member from the set.

[0151] Determining the Group Reduction and Link Cost Tables

[0153] The term Group is used here to refers to an IP “address group”.

[0154] The term Repeater Group refers to a Group that contains the IP address of a repeater.

[0158] The following processes are then performed on the Group Registry file.

[0159] Calculate Repeater Group Link Costs

For each target Repeater Group T:

- [0162] Initialize the link cost between T and itself to zero.
- [0163] Initialize the link cost between T and every other Group to infinity.
- [0164] Create a list L that will contain Groups that are equidistant from the target Repeater Group T.
- [0165] Initialize the list L to contain just the target Repeater Group T itself.
- [0166] While the list L is not empty:
  - [0167] Create an empty list L′ of neighbors of members of the list L.
  - [0168] For each Group G in the list L:
    - [0169] For each Group N that is a neighbor of G:
      - [0170] Let cost refer to the sum of the link cost between T and G, and the link cost between G and N.
      - [0171] The cost between T and G was determined in the previous pass of the algorithm; the link cost between G and N is from the Group Registry.
      - [0172] If cost is less than the link cost between T and N:
      - [0173] Set the link cost between T and N to cost.
      - [0174] Add N to L′ if it is not already on it.
  - [0175] Set L to L′.

[0176] Calculate Cost Sets

[0177] A Cost Set is a set of Groups that are equivalent with respect to Best Repeater Selection. That is, given the information available, the same repeater would be selected for any of them.

[0180] A Cost Set is then a set of groups that have equivalent cost profiles.

[0183] Cost Sets are then computed using the following algorithm:

- [0184] For each Group G:
  - [0185] Calculate the normalized cost profile for G
  - [0186] Look for a Cost Set with the same normalized cost profile.
  - [0187] If such as set is found, add G to the existing Cost Set;
  - [0188] otherwise, create a new Cost Set with the calculated normalized cost profile, containing only G.

[0191] As described below, the Group Reduction Table maps every IP address to one of these Cost Sets.

[0192] Build IP Map

[0193] The IP Map is a sorted list of records which map IP address ranges to Link Cost Table keys. The format of the IP map is:

[0194] <base IP address><max IP address><Link Cost Table key>

[0196] The NetMap procedure generates an intermediate IP map containing a map between IP address ranges and Cost Set numbers as follows:

- [0197] For each Cost Set S:
  - [0198] For each Group G in S:
    - [0199] For each IP address range in G:
      - [0200] Add a triple (low address, high address, Cost Set number of S) to the IP map.

[0204] The following algorithm is used:

- [0205] Initialize the list with the elements [−infinity, NOGROUP], [+infinity, NOGROUP].
  - [0206] For each entry in the IP map, in sorted order, consisting of (b, m, s),
    - [0207] Insert (b, m, s) in the list (recall that IP map entries are of the form (low address, high address Cost Set number of S))
  - [0208] For each reserved LAN address range (b, m):
    - [0209] Insert (b, m, LOCAL) in the list.
  - [0210] For each Repeater at address a:
    - [0211] Insert (a, a, REPEATER) in the list.
  - [0212] For each segment S in the ordered list:
    - [0213] Merge S with following segments with the same Cost Set
    - [0214] Create a Group Reduction Table entry with base address from the base address of S,
      - [0215] max address=next segment's base−1,
      - [0216] group ID=Cost Set number of S.

[0218] Given (B, M, N), insert an entry in the ordered address list as follows:

- [0219] Find the last segment (AB, AN) for which AB is less than or equal to B.
- [0220] If AB is less than B, insert a new segment (B, N) after (AB, AN).
- [0221] Find the last segment (YB, YN) for which YB is less than or equal to M.
- [0222] Replace by (XB, N) any segment (XB, NOGROUP) for which XB is greater than B and less than YB.
- [0223] If YN is not N, and either YN is NOGROUP or YB is less than or equal to B,
  - [0224] Let (ZB, ZN) be the segment following (YB, YN).
  - [0225] If M+1 is less than ZB, insert a new segment (M+1, YN) before (ZB, ZN).
  - [0226] Replace (YB, YN) by (YB, N).

[0227] Rewriting HTML Resources

[0230] Rewriting is performed as follows:

- [0231] F1. A BASE directive is added at the beginning of the HTML resource, or modified where necessary. Normally, a browser interprets relative URLs as being relative to the default base address, namely, the URL of the HTML resource (page) in which they are encountered. The BASE address added specifies the resource at the reflector which originally served the resource. This means that unprocessed relative URLs (such as those generated by Javascript™ programs) will be interpreted as relative to the reflector. Without this BASE address, browsers would combine relative addresses with repeater names to create URLs which were not in the form required by repeaters (as described above in step D1).
- [0232] F2. The rewriter identifies directives, such as embedded images and anchors, containing URLs. If the rewriter is running in a reflector, it must parse the HTML file to identify these directives.
- [0233] If it is running in a repeater, the rewriter may have access to pre-computed information that identifies the location of each URL (placed in the HTML file in step F4).
- [0234] F3. For each URL encountered in the resource to be re-written, the rewriter must determine whether the URL is repeatable (as in steps B1-B2). If the URL is not repeatable, it is not modified. On the other hand, if the URL is repeatable, it is modified to refer to the selected repeater.
- [0235] F4. After all URLs have been identified and modified, if the resource is being served to a repeater, a table is appended at the beginning of the resource that identifies the location and content of each URL encountered in the resource. (This step is an optimization which eliminates the need for parsing HTML resources at the repeater.)
- [0236] F5. Once all changes have been identified, a new length is computed for the resource (page). The length is inserted in the HTTP header prior to serving the resource.

[0238] Handling Non-HTTP Protocols

- [0241] http://<repeater>/origin server>@proxy=<scheme>[:<type>]@/resource
  where <scheme> is a supported protocol name such as “ftp”. This URL format is an alternative to the form shown in B3.

[0243] System Configuration and Management

[0244] In addition to the processing described above, the repeater network requires various mechanisms for system configuration and network management. Some of these mechanisms are described here.

[0247] Adding Subscribers to the Repeater Network

[0249] Adding Reflectors to the Repeater Network

[0252] The reflector processes requests during this time, but is not “enabled” (allowed to reflect requests) until all of its tables are current.

[0253] Keeping Repeater Caches Synchronized

[0254] Repeater caches are coherent, in the sense that when a change to a resource is identified by a reflector, all repeater caches are notified, and accept the change in a single transaction.

[0256] A repeater will load the newly modified resource the next time it is requested.

[0259] The invalidation process operates as follows:

[0260] The master broadcasts a “phase 1” invalidation request to all repeaters indicating the resources and regular expressions describing sets of resources to be invalidated.

[0261] When each repeater receives the phase 1 message, it first places the resource identifiers or regular expressions into a list of resource identifiers pending invalidation.

[0263] The repeater then compares the resource identifier of each resource in its cache against the resource identifiers and regular expressions in the list.

[0265] When the repeater has completed the invalidation, it returns an acknowledgment to the master. The master waits until all repeaters have acknowledged the invalidation request.

[0269] Logs and Log Processing

[0271] This merged log can be processed by standard processing tools, as if it had been generated locally.

- [0274] 1. request was served by a reflector locally;
- [0275] 2. request was reflected to a repeater;*
- [0276] 3. request was served by a reflector to a repeater;*
- [0277] 4. request for non-repeatable resource was served by repeater;*
- [0278] 5. request was served by a repeater from the cache;
- [0279] 6. request was served by a repeater after filling cache;
- [0280] 7. request pending invalidation was served by a repeater.
  (The activities marked with “*” represent intermediate states of a request and do not normally appear in a final activity log.)

[0283] Enforcing Committed Aggregate Information Rate

[0284] The repeater network monitors and limits the aggregate rate at which data is served on behalf of a given subscriber by all repeaters. This mechanism provides the following benefits:

- [0285] 1. provides a means of pricing repeater service;
- [0286] 2. provides a means for estimating and reserving capacity at repeaters;
- [0287] 3. provides a means for preventing clients of a busy site from limiting access to other sites.