Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20080071859 A1
Publication typeApplication
Application numberUS 11/980,672
Publication dateMar 20, 2008
Filing dateOct 31, 2007
Priority dateFeb 14, 2002
Also published asCN1777880A, CN100498756C, EP1474751A2, EP1474751A4, EP1474751B1, US8924466, US9167036, US20060015574, US20070174463, US20080065724, US20160044105, WO2003069437A2, WO2003069437A3
Publication number11980672, 980672, US 2008/0071859 A1, US 2008/071859 A1, US 20080071859 A1, US 20080071859A1, US 2008071859 A1, US 2008071859A1, US-A1-20080071859, US-A1-2008071859, US2008/0071859A1, US2008/071859A1, US20080071859 A1, US20080071859A1, US2008071859 A1, US2008071859A1
InventorsSteven Seed, Kevin Hobbs, Shane Glynn, Isaac Foraker, Peter Jones, Homer Chen
Original AssigneeLevel 3 Communications, Llc
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Popularity-based selective replication in content delivery network
US 20080071859 A1
Abstract
A client requests an object at a first server in a content delivery network (CDN), the request having been directed to said first server regardless of whether the first server has the requested object; When the first server does not have a copy of the requested object, it selectively replicating the requested object on the first server. The replicating is based at least in part on a measure of popularity of the requested object, wherein the requested object is not replicated to the first server when the measure of popularity of the requested object does not exceed a popularity threshold.
Images(10)
Previous page
Next page
Claims(25)
1. A method in a distributed computing environment having a plurality of edge servers and at least one parent server, wherein the edge servers are arranged in hierarchical fashion relative to the at least one parent server, the plurality of edge content servers and the at least one parent server forming a content delivery network (CDN), the method comprising:
directing a request by a client for an object to a first edge server in the CDN; and
if a copy of the requested object is stored on the first edge server, serving the requested object to the client from the first edge server; and,
if a copy of the requested object is not stored on the first edge server, directing the client to a parent server in the CDN associated with the first edge server for delivery of the requested object therefrom and determining whether to replicate the requested object on the first edge server for use in serving future client requests based on a measure of popularity of the requested object.
2. A method as recited in claim 1, further comprising:
replicating the requested object on the first edge server when the measure of popularity of the requested object exceeds a popularity threshold.
3. A method as recited in claim 2, wherein the measure of popularity is defined based on a total number of client requests for the object received at the first edge server.
4. A method as recited in claim 1, wherein if the parent server associated with the first edge server does not have a copy of the requested object, directing the client to another server in the CDN.
5. A method as recited in claim 4, wherein the step of directing is repeated for a plurality of other servers in the CDN.
6. A method as recited in claim 4, wherein the other server to which the client is directed if the parent server associated with the first edge server does not have a copy of the requested object is another parent server in the CDN.
7. A method as recited in claim 1, wherein the distributed computing environment further comprises at least one origin server, the method further comprising:
if a copy of the requested object is not stored on the parent server associated with the first edge server, directing the client to at least one origin server for delivery of the requested object therefrom and determining whether to replicate the requested object on the parent server associated with the first edge server for use in serving future client requests based on a measure of popularity of the requested object.
8. A method as recited in claim 1, wherein the measure of popularity of the requested object is a dynamic measure of popularity.
9. A method as recited in claim 1, wherein the requested object is a streaming media object.
10. A method, in a framework in which multiple resources of multiple content providers are delivered to multiple end user clients via a shared content delivery network (CDN) formed of a plurality of CDN server sites, each server site comprising one or more servers, the method comprising:
causing a client request for a resource to be directed to a first server site in said CDN;
if the first server site has a copy of the requested resource, then serving the requested resource to the client from the first server site; otherwise,
if the first server site does not have a copy of the requested resource, determining a measure of popularity of the requested resource relative to the first server site and replicating the requested resource to the first server site if the determined measure of popularity meets or exceeds a popularity threshold associated with the requested resource.
11. A method as recited in claim 10, further comprising:
if the first server site does not have a copy of the requested resource, causing the client to be directed to a second server site in the CDN.
12. A method as recited in claim 11, further comprising:
attempting to serve the requested resource to the client from the second server site in the CDN.
13. A method as recited in claim 10, wherein the measure of popularity of the requested resource is a dynamic measure of popularity.
14. A method, in a framework in which multiple resources of a content provider are delivered to multiple end user clients via a content delivery network (CDN) formed of a plurality of CDN server sites, each server site comprising one or more servers, wherein at least some of the CDN server sites are edge server sites each comprising one or more edge servers, and wherein at least some others of the CDN sites are parent server sites each comprising one or more parent servers, the method comprising:
(A) responsive to a client request for a resource at an edge server site in said CDN; and
(B) if the edge server site has a copy of the requested resource, then serving the requested resource to the client from the edge server site; otherwise,
(C) replicating a copy of the requested resource on the edge server site if a measure of popularity of the requested resource exceeds a popularity threshold associated with the requested object, otherwise not replicating the requested resource on the edge server site.
15. A method as recited in claim 13, further comprising:
(D) if the edge server site does not have a copy of the requested resource, then attempting to serve the requested object to the client from a second server site in the CDN.
16. A method as recited in claim 15, wherein the second server site in the CDN has a copy of the requested resource.
17. A method as recited in claim 13, wherein the measure of popularity of the requested resource is a dynamic measure of popularity.
18. A method, in a framework in which multiple resources of a content provider are delivered to multiple end user clients via a content delivery network (CDN), the CDN being formed of a plurality of edge servers and at least one parent server, wherein the edge servers are arranged in hierarchical fashion relative to the at least one parent server, the method comprising:
responsive to a client request for a resource at a first edge server in said CDN, determining if a copy of the requested resource is stored on the first edge server and, if not, then replicating a copy of the requested resource on the first edge server if a measure of popularity of the requested resource exceeds a popularity threshold associated with the requested object.
19. A method as recited in claim 18, wherein if the first edge server does not have a copy of the requested resource, the method comprises:
attempting to serve the requested resource to the client from another server in the CDN, distinct from the first edge server.
20. A method as recited in claim 18, further comprising:
directing the client to the other server in the CDN for delivery of the requested resource therefrom.
21. A method as recited in claim 20, wherein the other server in the CDN is a parent server to which the first edge server is associated.
22. A method as recited in claim 21, wherein the framework further comprises at least one origin server associated with the content provider, the method further comprising:
if a copy of the requested object is not stored on the parent server associated with the first edge server, directing the client to at least one origin server for delivery of the requested object therefrom and determining whether to replicate the requested object on the parent server associated with the first edge server for use in serving future client requests based on a measure of popularity of the requested object.
23. A content delivery method comprising:
in response to a client request at a first server in a content delivery network (CDN), said request being for an object, said client request having been directed to said first server regardless of whether the first server has the requested object, when the first server does not have a copy of the requested object, determining whether to replicate the requested object on the first server based at least in part on comparing a measure of popularity of the requested object against a popularity threshold associated with the requested object.
24. A method as recited in claim 23, further comprising:
replicating the requested object on the first server when the measure of popularity of the requested object exceeds the popularity threshold.
25. A method as recited in claim 24, wherein the measure of popularity is defined based on a total number of client requests for the object received at the first server.
Description
    CROSS-REFERENCE TO RELATED APPLICATION
  • [0001]
    This application is a continuation of co-pending U.S. patent application Ser. No. 11/715,316, titled “Managed Object Replication And Delivery” filed Mar. 8, 2007, which is a continuation of co-pending U.S. patent application Ser. No. 10/073,938 titled “Managed Object Replication And Delivery” filed Feb. 14, 2002, the disclosures of each of which are incorporated herein by reference in their entirety. This application is also related to U.S. patent application Ser. No. ______, (attorney docket no. 2711-0101), titled “Peer Server Handoff in Content Delivery Network,” and filed on even date herewith, the entire disclosure of which is incorporated herein by reference.
  • BACKGROUND
  • [0002]
    This invention relates in general to the field of computer networks. Particularly, aspects of this invention pertain to managed object replication and delivery over a network.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0003]
    Exemplary embodiments of the invention are illustrated in the accompanying drawings in which like references indicate similar or corresponding elements and in which:
  • [0004]
    FIG. 1 is a high-level block diagram of a topology of the managed object replication and delivery method and system according to embodiments of the invention;
  • [0005]
    FIG. 2 is a high-level block diagram illustrating the data flows of managed object replication and delivery method according to embodiments of the invention;
  • [0006]
    FIGS. 3(a), 3(b) and 3(c) are a flow chart of the managed object replication and delivery method and the object purging method according to embodiments of the invention;
  • [0007]
    FIG. 4 is a flow chart of a popularity computation according to embodiments of the invention;
  • [0008]
    FIG. 5 is a flow chart of a replication scheme according to embodiments of the invention;
  • [0009]
    FIG. 6 is a flow chart of a purge scheme according to embodiments of the invention; and
  • [0010]
    FIG. 7 is a block diagram of the managed object replication and delivery system according to embodiments of the invention.
  • DETAILED DESCRIPTION
  • [0011]
    A typical content delivery network (CDN) operator deploys one or more parent servers, hosting a plurality of objects, in a network and one or more edge servers at the edge of the network to facilitate more cost-effective and efficient delivery of such objects to an end-user (client). End-users or client proxies that access customers' objects are called clients. Content provider companies, organizations, etc. that subscribe to the CDN service are referred to as customers. As used herein, an object includes, without limitation, an audio file (such as, e.g., an MP3 (Motion Picture Experts Group-1 Layer 3) file and a RealNetworks, Inc. Real format file), a video file (such as an MPEG file), an image file (such as, e.g., a BMP (bitmap) file or JPEG (Joint Photographic Experts) file) and any other software or data file or object. It is typically desirable to serve objects from edge servers because the edge servers are typically closer (by various measures of distance) to end-users. For example, streaming content data from edge servers saves parent-to-edge bandwidth. Furthermore, the less the distance objects must travel can also mean reduced network congestion and packet losses, which can lead to a better experience for the end-user through faster response times and better quality of service.
  • [0012]
    It is typically not feasible to store all objects on the edge servers. The main difficulty is due to the fact that many such objects are very large (typically on the order of 10 MB (10,000,000 bytes)—in the neighborhood of 500 MB for movies). The storage and rack space required to accommodate often large and sometimes rarely requested objects at every edge server can be cost prohibitive as the number of customers grows and the number of their objects increases. It may not even be possible to store a good working set of objects, for example a set of objects thought to be requested often and/or better suited to be served from an edge server, because of the size and changing demand for objects in the working set.
  • [0013]
    One obvious solution is to pre-populate edge servers with objects for which there will likely be a significant or high demand. However, it is difficult to predict popularity and difficult to manage pre-populating. A related solution is to associate objects with two or more domains depending on popularity of the object, e.g., one domain for popular objects (served from edge servers) and another domain for less popular objects (served from parent servers). However, this requires some way to pre-determine what objects are popular and what objects are less popular statically, and build that popularity into the domain name of the object. As with pre-populating, it is difficult to predict popularity and to manage assignment of domains based on such popularity determinations.
  • [0014]
    Other solutions fetch objects on demand. In such schemes, when a requested object is not available on a handling edge server, a connection is made between a parent server having the requested object and the handling edge server to fetch the requested object from the parent server. Such fetching suffers however from having to go through the parent path (the network path between the handling edge server and the parent server with the object) whenever a client requests an object that is not already at the particular edge server.
  • [0015]
    Fetching a large object to the handling edge server through a parent path can be slow. For example, there may be limited available bandwidth from the parent server to the handling edge server, i.e., sometimes the parent path has less bandwidth than even the network path from the edge server to the client (e.g., the “last mile” in a broadband network). If a parent server uses too much bandwidth copying an object to an edge server, this can create congestion at that parent server. If storage fill bandwidth is matched to client bandwidth, it is difficult to handle a second, faster client and if fetch is done using a streaming protocol (for instance, the Real-Time Streaming Protocol (RTSP) and Real-Time Transport Protocol (RTP) standards), the quality of the copy made can be hurt due to lost packets (“thinning”).
  • [0016]
    Moreover, there may be an unreliable end-to-end parent path due to network congestion. And, if a parent server has to preprocess an object (e.g., to generate an image at a specific bit rate) or is otherwise busy with other tasks, this may further slow its ability to serve the request for the object fast enough. For example, if a client requests a bit rate higher than the parent-to-edge bit rate, delays will likely occur. Under such conditions, the parent server may fail, for example, to stream the object in time or to maintain the stream of an object at a requested bit rate thereby causing a thinned object, i.e., an object with lower quality due to lost packets in its transmission, to be populated at the edge server and delivered to subsequent clients requesting the same object.
  • [0017]
    Thus, it would be advantageous to populate edge servers with the most popular objects yet somehow serve the rest from parent servers with a goal to maximize the amount of object bits served from edge servers of the network. It would also be advantageous to populate edge servers by, for example, storage fill on demand when an object is popular enough, without having to make the end-user wait for such population. Therefore, it would be advantageous to provide a method and system for managed object replication and delivery over a network.
  • [0018]
    According to embodiments of the invention, a method and system for managed object replication and delivery over a network redirects, directly or indirectly, a client's request for an object that is not available at a best or optimal handling edge server of the network to a parent server of the network that has the requested object. So, where the requested object is not available at the handling edge server, the client's request is redirected directly to the parent server that can provide the requested object to the client or indirectly via one or more parent servers to a parent server that can provide the requested object to the client. The method and system further intelligently replicates the object to the edge server if the object is popular enough. Likewise, an object is removed from an edge server when the object is no longer popular. All redirection and replication operations are preferably transparent to the end-user and do not degrade the quality of service. Other embodiments of the invention are possible and some are described hereafter.
  • [0019]
    So, for example, under the framework described herein, a request for a streaming object will be served by a handling edge server if that handling edge server has a copy of that object. Otherwise, the request is redirected, directly or indirectly, to a parent server for service of the requested streaming object to the client. If the requested streaming object is popular, the object is replicated from a parent server that has the requested streaming object to the handling edge server so that the handling edge server will serve the object from the edge of the network when the object is requested in the future. If a streaming object is no longer popular, the object is removed from an edge server.
  • [0020]
    As used herein, replication generally refers to the permanent and/or volatile storage of an object in a server, particularly an edge server and if applicable, a parent server. Accordingly, the term replication will be considered synonymous to storing, caching and copying. In typical embodiments, replication of an object will usually refer to temporary storage of the object in an edge server and/or a parent server for an undefined duration.
  • [0021]
    A typical network for the managed object replication and delivery method according to embodiments of the invention is illustrated in FIG. 1. The network 100 comprises one or more parent server sites 120 and one or more edge server sites 130. The network also optionally has access to one or more origin server sites 110. The origin server sites are typically owned and/or maintained by the network provider's customers for storing and serving one or more objects. Each customer (content provider) may have its own origin server site. Furthermore, one or more clients 140 access the network to request one or more objects. A parent server site (or simply parent site or parent server) may comprise one parent server or a cluster of parent servers. Likewise, an edge server site (or simply edge site or edge server) may comprise one edge server or a cluster of edge servers and an origin server site (or simply origin site or origin server) may comprise one origin server or a cluster of origin servers. Typically, the network 100 is configured such that servers in a cluster share a common storage. In any event, configuration details of the parent server site, edge server site, and the origin server site are not important to the present invention.
  • [0022]
    In the typical network, the parent servers and edge servers are maintained by a network provider, wherein the parent servers are primarily used for storing and managing one or more objects and edge servers are primarily used for serving objects to clients. In some embodiments, all the objects are retrieved from origin servers and stored over one or more parent servers before any end-users can access each such object as the object is stored on the parent servers. Accordingly, in these embodiments, the origin servers play no significant role in the managed object replication and delivery method except to supply new and/or updated objects for storage on the parent servers. Moreover, only the parent servers communicate with the origin servers. In other embodiments, each requested object is replicated from one or more origin servers to one or more parent servers (and/or one or more edge servers) when the requested object becomes popular (as described in more detail below). In these embodiments, the origin servers play a more significant role in the managed object replication and delivery method to supply objects to parent and/or edge servers when requested. So, in these embodiments, the origin servers and parent servers communicate between each other and the origin servers and clients may also communicate between each other. In all of these embodiments, the communications relationships between origin servers and parent servers may be one-to-one, one-to-many or many-to-many.
  • [0023]
    Further, as shown in FIG. 1, the parent servers and edge servers communicate between each other, edge servers and clients communicate between each other and parent servers and clients communicate between each other. While in embodiments, as shown in FIG. 1, the edge servers have a one-to-one or one-to-many communications relationship with parent servers, edge servers may also have many-to-many communications relationships with parent servers. As discussed in more detail below, the edge servers act as the primary source of serving objects but if a requested object is not available at the edge server a parent server that has the requested object will serve the requested object to the clients. Also, FIG. 1 shows a single layer or level of parent servers and origin servers. As will be apparent to those skilled in the art, more than one layer or level of parent servers and/or origin servers may be used.
  • [0024]
    According to embodiments of the invention and referring to FIGS. 2, 3(a), 3(b) and 3(c), the method of managed object replication and delivery and the method of object purging is depicted. FIG. 2 depicts embodiments of the method in relation to a portion of the network 100, an origin server 110 and a client 140 as shown in FIG. 1. FIGS. 3(a), 3(b) and 3(c) depict embodiments of the method in flowchart form.
  • [0025]
    Initially, the method of managed object replication and delivery directs (at 200, 300) a client, requesting one or more objects, to an edge server in the network, whether or not the edge server has the requested object(s). Preferably, the client is directed to an optimal edge server, e.g., based on network traffic conditions and server load. As will be apparent to those skilled in the art, any number of currently known or future developed mechanisms may be used to select a best or optimal edge server. Determination of a best or optimal edge server preferably includes selection of an edge server most suitable for delivery of one or more objects to the client according to any number of currently known or future developed algorithms. For example, determination of a best or optimal edge server may be performed based on the likelihood of a copy of the requested object(s) being available at the candidate edge server, on the bandwidth between a candidate edge server and the client, on a best repeater selector (for example, as described in U.S. Pat. No. 6,185,598) and/or on any number of other criteria.
  • [0026]
    The selected best or optimal edge server 130 determines (at 305) whether the edge server already has the requested object and, if so, serves (at 205, 310) the object to the requesting client 140. For example, the selected edge server 130 will check its storage to determine whether the requested object is available and if so, may serve the object to the requesting client 140.
  • [0027]
    If the selected edge server does not have the requested object, a check is initiated (at 315) for the edge server to determine whether the requested object is popular and if so, to replicate the popular requested object to the edge server. In embodiments, the method depicted in FIG. 3(b) and discussed in more detail below is employed to determine whether the requested object is popular and if so, to replicate the popular requested object to the edge server.
  • [0028]
    In embodiments, the checking of whether the requested object is popular and replicating the popular requested object to the edge server may be performed independently of one or more functions of the method of managed object replication and delivery, such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client). Thus, in embodiments, the checking of whether the requested object is popular and replicating the popular object to the edge server may be performed in parallel with or before the performance of certain functions of the method of managed object replication and delivery such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client). Advantageously, should the checking, redirecting and serving of the requested object fail, the checking of whether the requested object is popular and replicating the popular object to the edge server can manage the continued delivery of objects to clients from edge servers. Similarly, if the checking of whether the requested object is popular and replicating the popular object to the edge server should fail, the checking, redirecting and serving of the requested object can manage the continued delivery of objects from servers in the network.
  • [0029]
    Further, if the selected edge server does not have the requested object, the selected edge server directs (at 210, 320) the requesting client 140 to a parent server 120. Preferably the client 140 is redirected to a parent server that has the requested object and is able to serve (at 215, 345) the requested object to the client. If a parent server does not have (at 325) the requested object, a check is initiated (at 330) for the parent server to determine whether the requested object is popular and if so, to replicate the popular requested object to the parent server. In embodiments, the method depicted in FIG. 3(b) and discussed in more detail below is employed to determine whether the requested object is popular and if so, to replicate the popular requested object to the parent server. As with the check for the edge server, in embodiments, the checking of whether the requested object is popular and replicating the popular requested object to the parent server is performed independently of one or more functions of the method of managed object replication and delivery such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client). Thus, in embodiments, the checking of whether the requested object is popular and replicating the popular requested object to the parent server may be performed in parallel with or before one or more functions of the method of managed object replication and delivery such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client).
  • [0030]
    Further, if a parent server does not have the requested object, the parent server could itself use a redirection technique recursively (at 325, 335, 320) until a final parent server is reached that has the requested object. The parent server that has the requested object serves (at 215, 345) the object to the client. If the object is determined to be unavailable (at 335) (from all parent servers), an error message is returned (at 340) regarding the unavailability of the requested object.
  • [0031]
    As will be apparent to those skilled in the art, numerous methods are available to redirect a requesting client to another parent server, depending on the protocol(s) used to request the object. A handling edge server may request information from a database about to which parent server the client should be redirected. In an implementation, the edge server might have a local database, populated by pushes of redirection data from one or more servers in the network. The edge server may also simply query one or more servers in the network to identify one or more parent servers to which the client can be directed. When more than one parent server responds, the edge server may redirect the client to the parent server that responds to the query first, the edge server may redirect the client to the parent server that is topologically closest to the edge server in the network or the edge server may redirect the client to the parent server that represents the best or optimal candidate based on criteria such as network efficiency, bandwidth requirement and/or cost. Alternatively, an edge server may always go to default parent servers. Or, as discussed in relation to edge servers, a best or optimal parent server may be determined using any of the techniques outlined above. Redirection may be performed by simply sending the request onto a parent server or returning redirection information to the client for accessing the parent server. As will be apparent to those skilled in the art, any number of implementations may be used to provide the redirection information to the handling edge server.
  • [0032]
    In other embodiments, where the parent servers collectively are not populated with all of the objects and the network has access to the origin server of a requested object, the client may be redirected (at 225, 320) to the origin server if the requested object is not available on the parent servers. If the origin server has the requested object (at 325), the origin server would serve (at 230, 345) the object directly to the client (not shown in FIG. 1). Otherwise if the object is unavailable (at 335), an error message would be returned (at 340) regarding the unavailability of the requested object.
  • [0033]
    Referring to FIG. 3(b), when an edge and/or parent server determines (at 350) that a requested object is popular (by some measure of popularity) but the edge and/or parent server does not have a copy of the object, the edge and/or parent server initiates a pull of the object to the edge and/or parent server. So, for example, when the edge server determines (at 350) that a requested object is popular but the edge server does not have a copy of the requested object, the edge server initiates the replicating (at 220, 360) of the popular requested object to the edge server from a parent server that has the requested object. Similarly, for example, when a parent server 120 determines (at 350) that a requested object is popular but the parent server does not have a copy of the requested object, the parent server initiates the replicating (at 240, 360) of the popular requested object to the parent server from an origin server that has the requested object. Alternatively, a parent and/or origin server may receive information regarding object popularity, such as popularity determinations for objects or data about object popularity, from one or more edge and/or parent servers and may push popular objects to the edge and/or parent servers. So, for example, when the parent server determines (at 350) that a requested object is popular at an edge server but the edge server does not have a copy of the requested object, the parent server may initiate the replicating (at 220, 360) of the popular requested object to the edge server from the parent server. Similarly, for example, when the origin server determines (at 350) that a requested object is popular at a parent server but the parent server does not have a copy of the requested object, the origin server initiates the replicating (at 240, 360) of the popular requested object to the parent server from the origin server.
  • [0034]
    In some embodiments, if none of the parent servers has the requested object, the edge server initiates the replication (at 235, 360) of the popular requested object to the edge server from the origin server having the requested object (if the network has access to the origin server). Preferably, in each case, the replicated object is not served or further replicated until the object has been completely copied to the respective server. Optionally, such replicating may be utilized by and between the parent servers themselves to facilitate the reduction of the traffic to and from the origin server. Further, if the edge and/or parent server does not have adequate space for the popular requested object, one or more objects may be purged (at 355) from the edge and/or parent server to make space for the popular object. In embodiments, the method depicted in FIG. 3(c) and discussed in more detail below is employed to determine whether any object(s) in the edge and/or parent server is no longer popular and if so, to delete the no longer popular object(s) from the edge and/or parent server. Also, as will apparent to those skilled in the art, servers other than the edge and/or parent server for which an object is determined popular may perform the actual determination of whether an object is popular by using for example, popularity information provided by the handling edge and/or parent server. The popularity determinations can then be used to initiate replication (for example, pushing or pulling) of the object to the edge and/or parent server for the which the object is determined popular.
  • [0035]
    Referring to FIG. 3(c), if an object in a server's storage is no longer popular (at 365), the server may delete the object (at 370) from the storage. For example, an edge server may delete (at 245, 370) any objects from the edge server's storage that are no longer popular. Similarly, a parent server may delete (at 250, 370) any objects from the parent server's storage that are no longer popular. As will be apparent to those skilled in the art, the determining of whether any object(s) in the server's storage is no longer popular and if so, deleting the no longer popular object(s) from the server's storage may be performed independently of, for example in parallel with or before, one or more functions of the method of managed object replication and delivery. In embodiments, the no longer popular objects are removed from edge servers and, if the no longer popular objects are hosted on an origin server, from parent servers.
  • [0000]
    Determining Popularity
  • [0036]
    Any number of techniques may be used to determine the popularity of an object. Determining the popularity can be based on the number of requests. Popularity can also be based on the request rate. Popular objects typically have higher request rates or higher number of requests than unpopular objects. Popularity can also be determined by tracking the last X number of request times for an object and then use the difference between the current time and these request times to calculate a running average for how often the object is requested. Determining the popularity can also be gauged on the request rate for an object that is perhaps weighted for more recent requests for the object (which is a predictor that the object will be requested again). An exponential decay method and an artificial neural network could also be used to determine popularity of an object.
  • [0037]
    According to some embodiments of a popularity computation and referring to FIG. 4, the popularity of an object is based on the request rate of the object and computed over a sliding time window in a discrete manner. In these embodiments, the variable I denotes the time interval over which the popularity of an object is measured. The time interval is divided into N equal sub-intervals of duration I/N. As will be apparent, the time interval is not required to be equally divided and may instead be divided in other manners.
  • [0038]
    A linked list P of size N is created for each object. The value of N determines the quality of approximation. The smaller the value of N, the coarser the approximation. In some embodiments, the value of N is set to 5.
  • [0039]
    The first element P[1] of the list records the number of requests that arrived when the current time was within the first sub-interval, the second element P[2] records the number of requests that arrived when the current time was within the 2nd interval, and so on. When a new sub-interval arrives, the list is rotated such that P[I] becomes P[I+1] except for P[N] which becomes P[1], so, e.g., P[1] becomes P[2], P[2] becomes P[3], and P[N] becomes P[1]. After the rotation, the new P[1] is reset to zero. Accordingly, only the end time of the first sub-interval needs to be recorded and compared against the current time to check if the list should be rotated. For each new request within the sub-interval, P[1] is simply incremented by 1. In this way, the arrival time of each request need not be recorded.
  • [0040]
    In preferred embodiments, the popularity of an object is simply the sum of all numbers in the list. To make the computation more efficient, the sum of P[2]+P[3]+ . . . +P[N] is stored in a register M. The popularity can be then computed by adding P[1] to M. When a rotation occurs, the new value of M becomes M+=P[1]−P[N]. The popularity of an object may be queried constantly. So, to avoid the extra addition involved for each such inquiry, the value of P[1] can be set to M after the rotation. Then, the value of P[1] is the popularity of the object.
  • [0041]
    The popularity computation algorithm may be summarized as follows. The linked list P of size N for an object, wherein each of P[1] . . . P[N] represents a time sub-interval, is initialized (at 400). The popularity M is also initialized (at 410). If there is a request for the object while the current time is within the current time sub-interval (at 420), then the value of P[1] is incremented (at 430) by 1. If the current time is within a new time sub-interval (at 440), then the value of P[1] is decremented by the value of M, M+=P[1]−P[N], the list P is rotated and P[1] is set to the value of M (at 450). Then, provided the popularity computation is continued (at 460) e.g., the popularity computation is not terminated, the popularity computation algorithm repeats itself.
  • [0000]
    Initiating Replication
  • [0042]
    Furthermore, any number of techniques may be used to initiate replication of an object. An edge server and/or a parent server might replicate an object on the first request by a client for the object. Alternatively, the edge server and/or parent server may be tuned to wait until the edge server and/or parent server receives a specific number or range of requests for the object. In other implementations, the object may be pulled if the object is more popular (e.g., a higher request rate) than the least popular object currently in the storage. In yet another alternative, the replicating decision can be a function of the popularity of the object, the cost of storing the object, the cost of pulling the object from the network and any other relevant cost factors. However, the popularity of objects may change significantly with time. Initiating a pull decision of an object purely based on a fixed threshold does not capture this dynamic nature of popularity.
  • [0043]
    A replication policy that compares against the least popularity of replicated objects has its limitations, although the policy does not use a fixed threshold. Consider where the storage is only half full but all the replicated objects are extremely popular. Since only objects exceeding the least popularity of the replicated objects will be replicated under this replication policy, objects with moderate popularity will be rejected despite that there is plenty of storage space available and that the objects are reasonably popular.
  • [0044]
    Accordingly, a replication scheme should be able to automatically adjust the replication threshold by taking into consideration the dynamic nature of popularity and the fullness of the storage. If there are more popular objects than the storage capacity allows, the replication scheme should raise the threshold. If there is more available storage capacity, the replication scheme should decrease the threshold so that more objects can be stored.
  • [0045]
    According to embodiments of a replication scheme and referring to FIG. 5, an object is replicated (at 520) into storage when the popularity P of the object is greater (at 500) than the initial threshold PI and when there is enough space (at 510) in the storage to replicate the object. If there is not enough storage to replicate the requested object, a replacement algorithm is performed in which the popularity P of the object is compared (at 530) against the popularity PL of the least popular object in the storage. If P is greater than PL, the current least popular object is removed (at 540) from the storage to free up more storage space, the next least popular object is identified (at 540), the value of the least popularity is updated (at 550), and a new iteration begins by checking if there is enough storage space to store the requested object (at 510). The storage space freeing iteration is terminated when either 1) enough storage space has been freed up to accommodate the requested object or 2) the requested object is not as popular as the least popular object in the storage. In embodiments, the least popular objects are removed from edge servers and, if there are origin servers with a copy of the least popular objects, from parent servers. Where no origin servers exist with a copy of the least popular objects, least popular objects are not removed from parent servers in order to keep a copy of the least popular objects in the network.
  • [0000]
    Purging
  • [0046]
    In some embodiments, the managed object replication and delivery method and system records the time on which an object was last requested. A purge scheme is invoked to clean up the storage of servers, for example, on a regular time interval basis or when a popular object is replicated to an edge and/or parent server but there is inadequate space at the edge and/or parent server. Referring to FIG. 6, in the purge scheme, all stale objects are removed from the storage (at 600), the remaining objects are sorted based on popularity (at 610), and the new values of PL and PI are determined (at 620, 630). An object is stale if its age (that is the time since the object was last requested) is over a pre-defined value, typically set to the duration of the sliding window used to measure the popularity multiplied by an adjustable factor. As will be apparent to those skilled in the art, the value may vary and indeed other staleness algorithms may be used. The popularity of the least popular object in the storage after purging is assigned as the new PL. The new PI is determined by using the sorted popularity and is set to the popularity of the last object that can fit into the storage if more popular objects are replicated first. Typically, PL should be greater than or equal to PI. If not, the value of PL is assigned to be the new PI. In some embodiments, the purge process is implemented as a separate thread in a multi-thread system. In embodiments, the stale objects are removed from edge servers and, if there are origin servers with a copy of the stale objects, from parent servers. Where no origin servers exist with a copy of the stale objects, stale objects are not removed from parent servers in order to keep a copy of the stale objects in the network.
  • [0047]
    At the outset when the system starts and there is no popularity data available yet, the initial values of both PL and PI can be set to zero. This forces the replication scheme to store the objects on their first request, but the purge scheme that is run on a regular basis will adjust the values of PL and PI automatically. The initial values of PL and PI can also be set to other values. Indeed, the initial values of PL and PI can be determined by taking into consideration the cost of storage, the cost of fetching, and the cost difference in deliveries from different servers. In any case, the system allows the specification of minimum PL and PI. If a computed PL or PI is smaller than the minimum specification, PL or PI is set to the minimum specification.
  • [0048]
    In some embodiments, to avoid or minimize stream thinning and other quality problems, storage fill is separated from data delivery. In this way, the data transfer between multiple sets of storages can tolerate a slower connection, and a server never streams an object unless the object is entirely in the storage. As will be apparent to those skilled in the art, it is possible to start streaming an object when there is enough data in the storage and that replication need not be completed before serving the object. Further, storage fill may be staged by copying to a separate location, then moving the copied data to a servable location when the data is complete.
  • [0049]
    Further, if an object is changed at an origin server, there may be a need to broadcast a message to remove the object at one or more parent servers and/or one or more edge servers. Similarly, if an object is changed at the parent server(s), there may be a need to broadcast a message to remove the object at one or more edge servers. In each case, future requests for the removed object would be handled as in the normal case where a requested object is not available at an edge server and/or a parent server.
  • [0000]
    Hardware and Software
  • [0050]
    In embodiments of the invention, referring to FIGS. 1 and 7, the system of managed object replication and delivery comprises one or more servers in a network designated as parent servers and one or more servers in the network designated as edge servers. In some embodiments, referring to FIG. 1, parent servers 120 have large storage capacity (on the order of 5 terabytes (TB)) while edge servers 130 have smaller storage space (ranging from 1 TB to 500 GB). One or more redirectors for implementing the method of managed object replication and delivery are installed on each edge server cluster. In some embodiments, one or more objects are replicated to one or more of the parent servers from the origin servers and then pulled from the parent servers to the edge servers as needed. In other embodiments, one or more objects are replicated to one or more of the edge servers and/or to one or more of the parent servers, from the origin servers as needed.
  • [0051]
    In some embodiments, a data transfer method 700, 710 is implemented to transfer data between parent servers and edge servers. The data transfer method supports the Transport Layer Security (TLS) protocol (described in the Internet Engineering Task Force (IETF) RFC 2246, located at “http://www.ietf.org/rfc/rfc2246.txt”, incorporated by reference herein) to ensure communication privacy. Further, the implementation of the method for managed object replication and delivery supports three popular object formats, namely Apple Computer, Inc.'s QuickTime™, RealNetworks, Inc.'s Real™, and Microsoft Corporation's WindowsMedia™ formats for streaming of requested object(s). As will be apparent to those skilled in the art, any number of other protocols and object formats may be used.
  • [0052]
    Further, in some embodiments, a number of software components are used to facilitate the method of managed object replication and delivery. A first component is a WindowsMedia redirector 720, 760 which is a service running on the Microsoft Windows NT operating system that processes requests from a Windows Media player and performs the redirection of the request for Windows Media objects. The WindowsMedia redirector is provided on edge servers and parent servers. Currently, the Microsoft Media Server (MMS) protocol is used for streaming of Windows Media objects and that protocol does not support redirection. To provide redirection for the streaming of Windows Media objects, the uniform resource identifier (URI) hyperlinks at the customer's site for such streaming Windows Media objects are modified. URIs as used herein generally have the following form (defined in detail in T. Bemers-Lee et al, Uniform Resource Identifiers (URI), IETF RFC 2396, August 1998, located at “http://www.ietf.org/rfc/rfc2396.txt”, incorporated by reference herein):
    scheme://host[port]/uri-path
  • [0053]
    where “scheme” can be a symbol such as “http” (see Hypertext Transfer Protocol—HTTP/1.1, IETF RFC 2616, located at “http://www.ietf.org/rfc/rfc2616.txt”, incorporated by reference herein) for an object on a Web server or “rtsp” (see Real Time Streaming Protocol (RTSP), IETF RFC 2326, located at “http://www.ietf.org/rfc/rfc2326.txt”, incorporated by reference herein) for an object on a streaming server. Other schemes can also be used and new schemes may be added in the future. The port number “port” 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 “uri-path” is relative to the computer specified in the “host” field. An uri-path is typically, but not necessarily, the path-name of a file in a media server directory. In a preferred embodiment, the HTTP protocol is used to effect the redirection of WindowsMedia objects. Therefore, the “scheme” field of the URIs of the WindowsMedia objects is changed from “mms” to “http”. For example, the URI for a sample object “sample.asf” in the Windows Media Advanced Streaming Format (ASF) will have a new URI of the form “http://host/path/sample.asf”. For objects using Windows Media ASX scripting, a sample URI for the “meta.asx” object will be in the form “http://host/?www.customer.com/path/meta.asx”, where “customer” is the name of the content provider of “meta.asx”. All URIs contained within the “meta.asx” object remain unchanged. Upon receiving the request “http://host/path/sample.asf”, the WindowsMedia redirector would respond to the request with the following example ASX script:
    <ASX version = “3.0”>
    <Entry><Ref href= “mms://servername/path/sample.asf” /></Entry>
    </ASX>
  • [0054]
    in the message body, if the requested object is found available either locally or on another server (parent or origin). In this example, “servername” is or resolves to the Internet Protocol (IP) address of a media server that will serve the requested object to the requesting client. If the requested object cannot be found, the WindowsMedia redirector would respond to the request with the following example ASX script:
    <ASX version = “3.0”>
    <Entry><Ref href= “http://redirname/path/sample.asf” /></Entry>
    </ASX>

    in the message body, where “redirname” is or resolves to the IP address of the redirector of a parent server, to trigger another round of redirection. A final round of redirection is reached when none of the parent servers (and the origin server, if applicable) has the requested object. In this case, the redirection process is terminated, and a “not found” error message is sent to the requesting client. Requests for ASX objects are processed in a similar way. Upon receiving the request for the sample object “meta.asx”, the WindowsMedia redirector checks the availability of the object pointed to by each URI inside “meta.asx” and rewrites the URI of each object accordingly. Then the WindowsMedia redirector sends a response to the request with the rewritten “meta.asx” in the message body of the response. The URI rewriting is done as follows. If a requested object, for example, “file.asf”, is found available locally or on another server, the corresponding URI would be rewritten to “mms://servername/path/file.asf”, where “servername” is or resolves to the IP address of the media server that will serve the requested object to the requesting client. If “file.asf” cannot be found, the corresponding URI is rewritten to “http://redirectorname/path/file.asf”, where “redirname” is or resolves to the IP address of a parent server redirector.
  • [0055]
    Another component is a Real/QuickTime redirector 730, 770 which is an application that processes Real-Time Streaming Protocol (RTSP) requests from a Real or QuickTime player for one or more objects and performs the redirection of the method for Real and QuickTime objects. The Real/QuickTime redirector is provided on edge servers and parent servers. The RTSP, described in detail in the IETF RFC 2326, is used for streaming Real and QuickTime objects, and the “REDIRECT” method supported in that protocol is used to effect redirection. A redirect request informs the client that it must reconnect to another server location and provides for the client the URI of that new server in the redirect request.
  • [0056]
    A best or optimal server selection mechanism is also provided (not shown in FIG. 7). The best or optimal server selection mechanism includes selection of an edge server most suitable for delivery of one or more objects to the client according to any number of currently known or future developed algorithms. In addition to redirection to a best or optimal edge server for handling a client request for an object, the best or optimal server mechanism may also be applied to trigger one or more further redirections to one or more parent server(s) when a requested object is not available at the handling edge server. In an implementation, to effect this operation, the hostname part of the URI for a requested object is modified. For example, in the link “http://customer-wm.fpondemand.net/customer/sample.asf”, “customer-wm.fpondemand.net” would be changed to “parent-wm.fpondemand.net” forcing the request to go through a further round of best or optimal server selection against parent servers only. In such embodiments, to effect best or optimal parent server selection, the parent-edge server topology is defined and the best or optimal server selection mechanism is provided a parent server table defining the relationships of such a topology. In some embodiments, the best or optimal server selection mechanism is similar to the best repeater selector described in U.S. Pat. No. 6,185,598.
  • [0057]
    A file replication manager application 740, 750 is also provided that manages object replication to and object removal from storage, retrieves objects from parent servers for replication to edge server storage, and performs storage cleanup as needed. The file replication manager is provided on edge servers and parent servers. In some embodiments, the file replication manager application uses the data transfer method and is in communication with the WindowsMedia and Real/QuickTime redirectors to provide, if available in the storage, objects requested by those redirectors.
  • [0058]
    In some embodiments, the message communicated between a WindowsMedia or a Real/QuickTime redirector and a file replication manager and between file replication managers is encapsulated using the User Datagram Protocol (UDP). This allows address handling and delivery to be handled by UDP and facilitates fast communication. Since UDP does not guarantee delivery, the message header contains a message number to be used to confirm that a response is to the current query, and not to a previous query. In addition, MD5 (See, e.g., Rivest, R., “The MD5 Message Digest Algorithm”, IETF RFC 1321, April 1992) is supported to provide a basic level of security. The MD5 hash is generated by running a MD5 hash algorithm on the message number, message, and a secret pass phrase only shared by components of the system of managed object replication and delivery. When a message is received, the MD5 hash of the message number, message, and secret pass phrase, is computed and compared against the MD5 hash provided in the message. If these two MD5 hashes do not match, the message is invalid, and will be discarded.
  • [0059]
    As will be apparent to those skilled in the art, FIG. 7 represents only some embodiments of the system according to the present invention. Many variations for implementing the system according to the teachings of the present invention are possible and are all within the scope of the invention.
  • [0000]
    Chunking
  • [0060]
    An extension of the above method and system is to provide chunking. Studies of log data show that, even for popular objects, a good percentage of requests for such objects exit before the object is completely served. To exploit this kind of object usage and further enhance the performance of the network, objects can be segmented into chunks and initial chunks of an object can be given preferential treatment in the replication scheme. For example, only the initial chunks of a object are replicated when a replication admission decision is made and the remaining chunks of the object are pulled to the storage only if the client does not exit before a certain amount or number (e.g., 90%) of the initial chunks of the object are served. The initial chunks of an object can be left in the storage even when the object becomes unpopular. By partitioning streams in this manner, a first part of an object can be served from edge servers quickly, even if most of the object stream must be fetched from a parent server or origin server.
  • [0000]
    Object Retention and Staleness
  • [0061]
    Optionally, some or all of the objects may be permanently retained in edge server storage or be retained depending on a quota. Similarly, a configurable or automatically adjusting threshold for storage filling and deletion may be provided.
  • [0062]
    Also, an edge server may be configured to determine whether a requested object in a server's storage is fresh and serve the requested object only when the object is not stale. In some embodiments, a file is maintained which lists the maximum storage age and storage quota in order to facilitate determining whether a requested object is fresh. If a request is received for a stale object a redirect is initiated to the relevant parent server or origin server to provide the requested object and a storage refresh will be performed if the requested object is popular.
  • [0000]
    Peers
  • [0063]
    Also, edge server storage fills of objects may be served by other peer edge servers instead of a relevant parent server or origin server. If a popular object has already been replicated to an edge server filling a new edge server request for that object from one of the peer edge servers may be more efficient than the parent server or origin server. Since there are typically more edge servers than parent servers and origin servers, there is an increased likelihood that a peer edge server may be closer in terms of network distance than a relevant parent server or origin server. Moreover, such peer edge server storage fills could also lessen the burden on the parent servers or origin servers.
  • [0064]
    The detailed descriptions may have been presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. The embodiments of the invention may be implemented as apparent to those skilled in the art in hardware or software, or any combination thereof. The actual software code or hardware used to implement the invention is not limiting of the invention. Thus, the operation and behavior of the embodiments often will be described without specific reference to the actual software code or hardware components. The absence of such specific references is feasible because it is clearly understood that artisans of ordinary skill would be able to design software and hardware to implement the embodiments of the invention based on the description herein with only a reasonable effort and without undue experimentation.
  • [0065]
    A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations comprise physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, objects, attributes or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
  • [0066]
    Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations of the invention described herein; the operations are machine operations. Useful machines for performing the operations of the invention include general purpose digital computers, special purpose computers or similar devices.
  • [0067]
    Each operation of the method may be executed on any general computer, such as a mainframe computer, personal computer or the like and pursuant to one or more, or a part of one or more, program modules or objects generated from any programming language, such as C++, Perl, Java™, Fortran, etc. And still further, each operation, or a file, module, object or the like implementing each operation, may be executed by special purpose hardware or a circuit module designed for that purpose. For example, the invention may be implemented as a firmware program loaded into non-volatile storage or a software program loaded from or into a data storage medium as machine-readable code, such code being instructions executable by an array of logic elements such as a processor or other digital signal processing unit. Any data handled in such processing or created as a result of such processing can be stored in any memory as is conventional in the art. By way of example, such data may be stored in a temporary memory, such as in the RAM of a given computer system or subsystem. In addition, or in the alternative, such data may be stored in longer-term storage devices, for example, magnetic disks, rewritable optical disks, and so on.
  • [0068]
    In the case of diagrams depicted herein, they are provided by way of example. There may be variations to these diagrams or the operations described herein without departing from the spirit of the invention. For instance, in certain cases, the operations may be performed in differing order, or operations may be added, deleted or modified.
  • [0069]
    Embodiments of the invention may be implemented as an article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method operations of the invention, a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the method operations of the invention, or a computer program product. Such an article of manufacture, program storage device or computer program product may include, but is not limited to, CD-ROM, CD-R, CD-RW, diskettes, tapes, hard drives, computer system memory (e.g., RAM or ROM), and/or the electronic, magnetic, optical, biological or other similar embodiments of the program (including, but not limited to, a carrier wave modulated, or otherwise manipulated, to convey instructions that can be read, demodulated/decoded and executed by a computer). Indeed, the article of manufacture, program storage device or computer program product may include any solid or fluid transmission medium, whether magnetic, biological, optical, or the like, for storing or transmitting signals readable by a machine for controlling the operation of a general or special purpose computer according to any or all methods of the invention and/or to structure its components in accordance with a system of the invention.
  • [0070]
    Embodiments of the invention may also be implemented in a system. A system may comprise a computer that includes a processor and a memory device and optionally, a storage device, an output device such as a video display and/or an input device such as a keyboard or computer mouse. Moreover, a system may comprise an interconnected network of computers. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such as a cellular telephone).
  • [0071]
    The system may be specially constructed for the required purposes to perform, for example, the method of the invention or the system may comprise one or more general purpose computers as selectively activated or reconfigured by a computer program in accordance with the teachings herein stored in the computer(s). The system could also be implemented in whole or in part as a hard-wired circuit or as a circuit configuration fabricated into an application-specific integrated circuit. The invention presented herein is not inherently related to a particular computer system or other apparatus. The required structure for a variety of these systems will appear from the description given.
  • [0072]
    While this invention has been described in relation to certain embodiments, it will be understood by those skilled in the art that other embodiments according to the generic principles disclosed herein, modifications to the disclosed embodiments and changes in the details of construction, arrangement of parts, compositions, processes, structures and materials selection all may be made without departing from the spirit and scope of the invention Changes, including equivalent structures, acts, materials, etc., may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation of the invention and that the specification and drawing(s) are, accordingly, to be regarded in an illustrative rather than a restrictive sense. As such, the invention is not intended to be limited to the embodiments shown above but rather is to be accorded the widest scope consistent with the principles and novel features disclosed in any fashion herein.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5568181 *May 1, 1995Oct 22, 1996International Business Machines CorporationMultimedia distribution over wide area networks
US5614940 *Oct 21, 1994Mar 25, 1997Intel CorporationMethod and apparatus for providing broadcast information with indexing
US5734719 *Dec 10, 1996Mar 31, 1998International Business Systems, IncorporatedDigital information accessing, delivery and production system
US5777988 *Apr 17, 1996Jul 7, 1998Bell Communications Research, Inc.System and method for equalizing delay in a dynamic packet switching network
US5778187 *May 9, 1996Jul 7, 1998Netcast Communications Corp.Multicasting method and apparatus
US5781909 *Feb 13, 1996Jul 14, 1998Microtouch Systems, Inc.Supervised satellite kiosk management system with combined local and remote data storage
US5819092 *Oct 6, 1997Oct 6, 1998Vermeer Technologies, Inc.Online service development tool with fee setting capabilities
US5832069 *Nov 17, 1995Nov 3, 1998Sprint Communications Co L.P.Object oriented system for modeling telecommunications circuits to estimate the access cost for leasing selected circuits
US5845090 *Sep 30, 1996Dec 1, 1998Platinium Technology, Inc.System for software distribution in a digital computer network
US5898456 *Apr 19, 1996Apr 27, 1999Alcatel N.V.Communication system with hierarchical server structure
US5913028 *Oct 6, 1995Jun 15, 1999Xpoint Technologies, Inc.Client/server data traffic delivery system and method
US5933835 *Apr 9, 1997Aug 3, 1999Intel CorporationMethod and apparatus for managing multimedia data files in a computer network by streaming data files into separate streams based on file attributes
US5940831 *Aug 22, 1997Aug 17, 1999Nec CorporationHypermedia system and method of managing directories and directory data originating from a node link structure in a directory server
US5951694 *Feb 3, 1997Sep 14, 1999Microsoft CorporationMethod of redirecting a client service session to a second application server without interrupting the session by forwarding service-specific information to the second server
US6016509 *Jan 9, 1998Jan 18, 2000Intel CorporationGeneral purpose metering mechanism for distribution of electronic information
US6016512 *Aug 18, 1998Jan 18, 2000Telcordia Technologies, Inc.Enhanced domain name service using a most frequently used domain names table and a validity code table
US6023470 *May 17, 1996Feb 8, 2000Lee; Warren S.Point of presence (POP) for digital facsimile network with virtual POPs used to communicate with other networks
US6078943 *Feb 7, 1997Jun 20, 2000International Business Machines CorporationMethod and apparatus for dynamic interval-based load balancing
US6081835 *Mar 11, 1997Jun 27, 2000British Telecommunications Public Limited CompanyInternet server and method of controlling an internet server
US6081840 *Oct 14, 1997Jun 27, 2000Zhao; YanTwo-level content distribution system
US6085193 *Sep 29, 1997Jul 4, 2000International Business Machines CorporationMethod and system for dynamically prefetching information via a server hierarchy
US6094706 *Mar 2, 1998Jul 25, 2000International Business Machines CorporationCaching in a data processing system using the pigeon hole principle
US6098096 *Dec 9, 1996Aug 1, 2000Sun Microsystems, Inc.Method and apparatus for dynamic cache preloading across a network
US6115752 *May 21, 1998Sep 5, 2000Sun Microsystems, Inc.System and method for server selection for mirrored sites
US6128623 *Apr 15, 1998Oct 3, 2000Inktomi CorporationHigh performance object cache
US6130890 *Sep 11, 1998Oct 10, 2000Digital Island, Inc.Method and system for optimizing routing of data packets
US6131095 *Dec 11, 1996Oct 10, 2000Hewlett-Packard CompanyMethod of accessing a target entity over a communications network
US6161137 *Mar 31, 1998Dec 12, 2000Mshow.Com, Inc.Method and system for providing a presentation on a network
US6185598 *Feb 10, 1998Feb 6, 2001Digital Island, Inc.Optimized network resource location
US6233623 *Jan 11, 1996May 15, 2001Cabletron Systems, Inc.Replicated resource management system for managing resources in a distributed application and maintaining a relativistic view of state
US6240462 *Oct 14, 1997May 29, 2001At&TSystem for providing enhanced grade of service for connections over a large network
US6266335 *Dec 19, 1997Jul 24, 2001Cyberiq SystemsCross-platform server clustering using a network flow switch
US6275470 *Jun 18, 1999Aug 14, 2001Digital Island, Inc.On-demand overlay routing for computer-based communication networks
US6317787 *Aug 11, 1998Nov 13, 2001Webtrends CorporationSystem and method for analyzing web-server log files
US6324580 *Sep 3, 1998Nov 27, 2001Sun Microsystems, Inc.Load balancing for replicated services
US6324582 *Oct 20, 1998Nov 27, 2001Sitara Networks, Inc.Enhanced network communication
US6332157 *Jun 29, 1999Dec 18, 2001Webtv Networks, Inc.Method of accessing multiple services from multiple service providers
US6343298 *Jun 13, 2000Jan 29, 2002Microsoft CorporationSeamless multimedia branching
US6345294 *Apr 19, 1999Feb 5, 2002Cisco Technology, Inc.Methods and apparatus for remote configuration of an appliance on a network
US6351775 *May 30, 1997Feb 26, 2002International Business Machines CorporationLoading balancing across servers in a computer network
US6351776 *May 12, 2000Feb 26, 2002Xdrive, Inc.Shared internet storage resource, user interface system, and method
US6389462 *Dec 16, 1998May 14, 2002Lucent Technologies Inc.Method and apparatus for transparently directing requests for web objects to proxy caches
US6415368 *Dec 22, 1999Jul 2, 2002Xerox CorporationSystem and method for caching
US6421714 *Aug 24, 1998Jul 16, 2002Lucent TechnologiesEfficient mobility management scheme for a wireless internet access system
US6427170 *Dec 8, 1998Jul 30, 2002Cisco Technology, Inc.Integrated IP address management
US6442588 *Aug 20, 1998Aug 27, 2002At&T Corp.Method of administering a dynamic filtering firewall
US6453319 *Apr 5, 2000Sep 17, 2002Inktomi CorporationMaintaining counters for high performance object cache
US6463454 *Jun 17, 1999Oct 8, 2002International Business Machines CorporationSystem and method for integrated load distribution and resource management on internet environment
US6466949 *Nov 23, 1998Oct 15, 2002Myway.Com CorporationPerforming event notification in a database having a distributed web cluster
US6487555 *May 7, 1999Nov 26, 2002Alta Vista CompanyMethod and apparatus for finding mirrored hosts by analyzing connectivity and IP addresses
US6502205 *Nov 10, 2000Dec 31, 2002Emc CorporationAsynchronous remote data mirroring system
US6591288 *May 19, 1998Jul 8, 2003Nortel Networks LimitedData network accelerated access system
US6594260 *Sep 3, 1999Jul 15, 2003Cisco Technology, Inc.Content routing
US6598121 *Nov 6, 2001Jul 22, 2003International Business Machines, Corp.System and method for coordinated hierarchical caching and cache replacement
US6651141 *Dec 29, 2000Nov 18, 2003Intel CorporationSystem and method for populating cache servers with popular media contents
US6678659 *Jun 20, 1997Jan 13, 2004Swisscom AgSystem and method of voice information dissemination over a network using semantic representation
US6732237 *Aug 29, 2000May 4, 2004Oracle International CorporationMulti-tier caching system
US6741990 *May 23, 2001May 25, 2004Intel CorporationSystem and method for efficient and adaptive web accesses filtering
US6785704 *Jul 3, 2000Aug 31, 2004Fastforward NetworksContent distribution system for operation over an internetwork including content peering arrangements
US6839758 *Sep 28, 2001Jan 4, 2005Intel CorporationNetwork processor for cache array routing
US6859840 *Jan 29, 2001Feb 22, 2005Kasenna, Inc.Prefix caching for media objects
US6915307 *May 6, 2002Jul 5, 2005Inktomi CorporationHigh performance object cache
US6976090 *Feb 16, 2001Dec 13, 2005Actona Technologies Ltd.Differentiated content and application delivery via internet
US6999988 *Mar 30, 2001Feb 14, 2006Lucent Technologies Inc.Method and system for data layout and replacement in distributed streaming caches on the Internet
US7254645 *Mar 27, 2001Aug 7, 2007Nec CorporationQuality assured network service provision system compatible with a multi-domain network and service provision method and service broker device
US20010049732 *May 29, 2001Dec 6, 2001Raciborski Nathan F.Content exchange apparatus
US20010051980 *May 29, 2001Dec 13, 2001Raciborski Nathan F.Preloading content objects on content exchanges
US20020078233 *Jul 9, 2001Jun 20, 2002Alexandros BilirisMethod and apparatus for content distribution network brokering and peering
US20020087797 *Dec 29, 2000Jul 4, 2002Farid AdrangiSystem and method for populating cache servers with popular media contents
US20020092026 *Aug 14, 2001Jul 11, 2002International Business Machines CorporationMethod and apparatus for broadcast delivery of content to a client-side cache based on user preferences
US20020152318 *Mar 4, 2002Oct 17, 2002Menon Satish N.Metadata enabled push-pull model for efficient low-latency video-content distribution over a network
US20020163882 *Mar 1, 2002Nov 7, 2002Akamai Technologies, Inc.Optimal route selection in a content delivery network
US20030031176 *May 17, 2001Feb 13, 2003Sim Siew YongMethod and apparatus for distributing large payload file to a plurality of storage devices in a network
US20030149581 *Feb 28, 2001Aug 7, 2003Imran ChaudhriMethod and system for providing intelligent network content delivery
US20030158923 *May 2, 2001Aug 21, 2003Reed BurkhartSystem and method for automated negotiation for and allocation of a broadcast satellite, communication and caching system resource
US20050021863 *May 25, 2004Jan 27, 2005Cloudshield Technologies, Inc.Apparatus and method for virtual edge placement of web sites
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7769822 *Jul 17, 2007Aug 3, 2010International Business Machines CorporationMethod for distributing file content from a selected target depot server in response to multiple client requests
US7908391 *Mar 25, 2008Mar 15, 2011Symantec CorporationApplication streaming and network file system optimization via feature popularity
US8090863Jul 13, 2010Jan 3, 2012Limelight Networks, Inc.Partial object distribution in content delivery network
US8200958Oct 5, 2009Jun 12, 2012Limelight Networks, Inc.Content delivery network encryption
US8219645 *Mar 26, 2010Jul 10, 2012Limelight Networks, Inc.Content delivery network cache grouping
US8219647 *Sep 26, 2011Jul 10, 2012Limelight Networks, Inc.Content delivery network cache grouping
US8239482Nov 13, 2008Aug 7, 2012At&T Intellectual Property I, LpSystem and method for selectively caching hot content in a content delivery system
US8275874Nov 14, 2011Sep 25, 2012Amazon Technologies, Inc.Locality based content distribution
US8291117Feb 15, 2012Oct 16, 2012Limelight Networks, Inc.Scaled domain name service
US8321588Sep 14, 2011Nov 27, 2012Amazon Technologies, Inc.Request routing utilizing client location information
US8331370Dec 17, 2009Dec 11, 2012Amazon Technologies, Inc.Distributed routing architecture
US8331371Dec 17, 2009Dec 11, 2012Amazon Technologies, Inc.Distributed routing architecture
US8346937Nov 30, 2010Jan 1, 2013Amazon Technologies, Inc.Content management
US8352613Nov 30, 2010Jan 8, 2013Amazon Technologies, Inc.Content management
US8352614Nov 30, 2010Jan 8, 2013Amazon Technologies, Inc.Content management
US8352615Nov 30, 2010Jan 8, 2013Amazon Technologies, Inc.Content management
US8356074Aug 9, 2012Jan 15, 2013Limelight Networks, Inc.Inter point of presence split architecture
US8370449 *Jun 18, 2012Feb 5, 2013Limelight Networks, Inc.Content delivery network cache grouping
US8370452Feb 10, 2011Feb 5, 2013Limelight Networks, Inc.Partial object caching
US8386596Mar 12, 2012Feb 26, 2013Amazon Technologies, Inc.Request routing based on class
US8392501 *Aug 29, 2011Mar 5, 2013Telefonaktiebolaget L M Ericsson (Publ)Methods and systems for resuming, transferring or copying a multimedia session
US8397073 *Mar 11, 2010Mar 12, 2013Amazon Technologies, Inc.Managing secure content in a content delivery network
US8402137Aug 8, 2008Mar 19, 2013Amazon Technologies, Inc.Content management
US8412823Mar 27, 2009Apr 2, 2013Amazon Technologies, Inc.Managing tracking information entries in resource cache components
US8423667Jun 21, 2012Apr 16, 2013Amazon Technologies, Inc.Updating routing information based on client location
US8438263Sep 13, 2012May 7, 2013Amazon Technologies, Inc.Locality based content distribution
US8447831Mar 31, 2008May 21, 2013Amazon Technologies, Inc.Incentive driven content delivery
US8452874Nov 22, 2010May 28, 2013Amazon Technologies, Inc.Request routing processing
US8458250Aug 6, 2012Jun 4, 2013Amazon Technologies, Inc.Request routing using network computing components
US8458360Sep 15, 2012Jun 4, 2013Amazon Technologies, Inc.Request routing utilizing client location information
US8463876Aug 1, 2012Jun 11, 2013Limelight, Inc.Partial object distribution in content delivery network
US8463877Sep 15, 2012Jun 11, 2013Amazon Technologies, Inc.Dynamically translating resource identifiers for request routing using popularitiy information
US8468247Sep 28, 2010Jun 18, 2013Amazon Technologies, Inc.Point of presence management in request routing
US8495220Sep 15, 2012Jul 23, 2013Amazon Technologies, Inc.Managing CDN registration by a storage provider
US8510448Sep 13, 2012Aug 13, 2013Amazon Technologies, Inc.Service provider registration by a content broker
US8521851Mar 27, 2009Aug 27, 2013Amazon Technologies, Inc.DNS query processing using resource identifiers specifying an application broker
US8521880Nov 17, 2008Aug 27, 2013Amazon Technologies, Inc.Managing content delivery network service providers
US8521885Sep 15, 2012Aug 27, 2013Amazon Technologies, Inc.Dynamically translating resource identifiers for request routing using popularity information
US8533293Mar 31, 2008Sep 10, 2013Amazon Technologies, Inc.Client side cache management
US8543702Sep 15, 2012Sep 24, 2013Amazon Technologies, Inc.Managing resources using resource expiration data
US8549531Sep 13, 2012Oct 1, 2013Amazon Technologies, Inc.Optimizing resource configurations
US8577992Sep 28, 2010Nov 5, 2013Amazon Technologies, Inc.Request routing management based on network components
US8583762Jul 5, 2012Nov 12, 2013At&T Intellectual Property I, L.P.System and method for selectively caching hot content in a content delivery system
US8583776Aug 6, 2012Nov 12, 2013Amazon Technologies, Inc.Managing content delivery network service providers
US8595778Oct 23, 2009Nov 26, 2013Level 3 Communications, LlcUser authentication in a content delivery network
US8601090Mar 31, 2008Dec 3, 2013Amazon Technologies, Inc.Network resource identification
US8606996Mar 31, 2008Dec 10, 2013Amazon Technologies, Inc.Cache optimization
US8626950Dec 3, 2010Jan 7, 2014Amazon Technologies, Inc.Request routing processing
US8639817Dec 19, 2012Jan 28, 2014Amazon Technologies, Inc.Content management
US8667127Jan 13, 2011Mar 4, 2014Amazon Technologies, Inc.Monitoring web site content
US8676918Sep 15, 2012Mar 18, 2014Amazon Technologies, Inc.Point of presence management in request routing
US8683002 *Jan 2, 2013Mar 25, 2014Limelight Networks, Inc.Content delivery network cache grouping
US8688837Mar 27, 2009Apr 1, 2014Amazon Technologies, Inc.Dynamically translating resource identifiers for request routing using popularity information
US8713156Feb 13, 2013Apr 29, 2014Amazon Technologies, Inc.Request routing based on class
US8719886Oct 23, 2009May 6, 2014Level 3 Communications, LlcDynamic processing of streamed content
US8732309Nov 17, 2008May 20, 2014Amazon Technologies, Inc.Request routing utilizing cost information
US8756325Mar 11, 2013Jun 17, 2014Amazon Technologies, Inc.Content management
US8756341 *Mar 27, 2009Jun 17, 2014Amazon Technologies, Inc.Request routing utilizing popularity information
US8762526Sep 15, 2012Jun 24, 2014Amazon Technologies, Inc.Optimizing content management
US8782236Jun 16, 2009Jul 15, 2014Amazon Technologies, Inc.Managing resources using resource expiration data
US8788671Jan 25, 2012Jul 22, 2014Amazon Technologies, Inc.Managing content delivery network service providers by a content broker
US8819283Sep 28, 2010Aug 26, 2014Amazon Technologies, Inc.Request routing in a networked environment
US8843625Sep 15, 2012Sep 23, 2014Amazon Technologies, Inc.Managing network data display
US8886814May 21, 2013Nov 11, 2014Level 3 Communications, LlcLoad-balancing cluster
US8902897Sep 14, 2012Dec 2, 2014Amazon Technologies, Inc.Distributed routing architecture
US8924528Sep 28, 2010Dec 30, 2014Amazon Technologies, Inc.Latency measurement in resource requests
US8930513Sep 28, 2010Jan 6, 2015Amazon Technologies, Inc.Latency measurement in resource requests
US8930538Mar 21, 2009Jan 6, 2015Level 3 Communications, LlcHandling long-tail content in a content delivery network (CDN)
US8930544Oct 29, 2013Jan 6, 2015Amazon Technologies, Inc.Network resource identification
US8938526Sep 28, 2010Jan 20, 2015Amazon Technologies, Inc.Request routing management based on network components
US8959179Nov 12, 2013Feb 17, 2015At&T Intellectual Property I, L.P.System and method for selectively caching hot content in a content distribution network
US8966003Sep 21, 2009Feb 24, 2015Limelight Networks, Inc.Content delivery network stream server vignette distribution
US8971328Sep 14, 2012Mar 3, 2015Amazon Technologies, Inc.Distributed routing architecture
US8984056Jan 14, 2013Mar 17, 2015Limelight Networks, Inc.Inter point of presence split architecture
US8996664Aug 26, 2013Mar 31, 2015Amazon Technologies, Inc.Translation of resource identifiers using popularity information upon client request
US9003035Sep 28, 2010Apr 7, 2015Amazon Technologies, Inc.Point of presence management in request routing
US9003040Apr 29, 2013Apr 7, 2015Amazon Technologies, Inc.Request routing processing
US9009286May 6, 2013Apr 14, 2015Amazon Technologies, Inc.Locality based content distribution
US9015348Jul 19, 2013Apr 21, 2015Limelight Networks, Inc.Dynamically selecting between acceleration techniques based on content request attributes
US9021127Mar 14, 2013Apr 28, 2015Amazon Technologies, Inc.Updating routing information based on client location
US9021128May 17, 2013Apr 28, 2015Amazon Technologies, Inc.Request routing using network computing components
US9021129Jun 3, 2013Apr 28, 2015Amazon Technologies, Inc.Request routing utilizing client location information
US9026616May 17, 2013May 5, 2015Amazon Technologies, Inc.Content delivery reconciliation
US9055085Mar 31, 2010Jun 9, 2015Comcast Cable Communications, LlcDynamic generation of media content assets for a content delivery network
US9083675Jun 4, 2013Jul 14, 2015Amazon Technologies, Inc.Translation of resource identifiers using popularity information upon client request
US9083743Jun 20, 2012Jul 14, 2015Amazon Technologies, Inc.Managing request routing information utilizing performance information
US9088460Mar 15, 2013Jul 21, 2015Amazon Technologies, Inc.Managing resource consolidation configurations
US9106701Nov 4, 2013Aug 11, 2015Amazon Technologies, Inc.Request routing management based on network components
US9106934 *Jan 29, 2013Aug 11, 2015Espial Group Inc.Distribution of adaptive bit rate live streaming video via hyper-text transfer protocol
US9130756 *Mar 11, 2013Sep 8, 2015Amazon Technologies, Inc.Managing secure content in a content delivery network
US9135048Sep 20, 2012Sep 15, 2015Amazon Technologies, Inc.Automated profiling of resource usage
US9154551Jun 11, 2012Oct 6, 2015Amazon Technologies, Inc.Processing DNS queries to identify pre-processing information
US9160641May 24, 2013Oct 13, 2015Amazon Technologies, Inc.Monitoring domain allocation performance
US9160703Dec 10, 2014Oct 13, 2015Amazon Technologies, Inc.Request routing management based on network components
US9167049Aug 21, 2012Oct 20, 2015Comcast Cable Communications, LlcContent distribution network supporting popularity-based caching
US9172674Jun 20, 2012Oct 27, 2015Amazon Technologies, Inc.Managing request routing information utilizing performance information
US9176894Jul 14, 2014Nov 3, 2015Amazon Technologies, Inc.Managing resources using resource expiration data
US9185012Nov 21, 2014Nov 10, 2015Amazon Technologies, Inc.Latency measurement in resource requests
US9191338Aug 25, 2014Nov 17, 2015Amazon Technologies, Inc.Request routing in a networked environment
US9191369Oct 30, 2014Nov 17, 2015Aryaka Networks, Inc.Application acceleration as a service system and method
US9191458Jun 5, 2014Nov 17, 2015Amazon Technologies, Inc.Request routing using a popularity identifier at a DNS nameserver
US9197699Nov 10, 2014Nov 24, 2015Level 3 Communications, LlcLoad-balancing cluster
US9208097Nov 12, 2013Dec 8, 2015Amazon Technologies, Inc.Cache optimization
US9210099Sep 30, 2013Dec 8, 2015Amazon Technologies, Inc.Optimizing resource configurations
US9210235Aug 28, 2013Dec 8, 2015Amazon Technologies, Inc.Client side cache management
US9237114Mar 14, 2013Jan 12, 2016Amazon Technologies, Inc.Managing resources in resource cache components
US9246776Mar 10, 2015Jan 26, 2016Amazon Technologies, Inc.Forward-based resource delivery network management techniques
US9251112Aug 26, 2013Feb 2, 2016Amazon Technologies, Inc.Managing content delivery network service providers
US9253065Nov 21, 2014Feb 2, 2016Amazon Technologies, Inc.Latency measurement in resource requests
US9253545 *Dec 4, 2013Feb 2, 2016Wowza Media Systems, LLCRouting media content based on monetary cost
US9288153Jun 13, 2014Mar 15, 2016Amazon Technologies, Inc.Processing encoded content
US9294391Jun 4, 2013Mar 22, 2016Amazon Technologies, Inc.Managing network computing components utilizing request routing
US9311020Aug 19, 2013Apr 12, 2016International Business Machines CorporationMethod and apparatus for automated migration of data among storage centers
US9317223 *Dec 17, 2012Apr 19, 2016International Business Machines CorporationMethod and apparatus for automated migration of data among storage centers
US9323577Sep 20, 2012Apr 26, 2016Amazon Technologies, Inc.Automated profiling of resource usage
US9332078Mar 5, 2015May 3, 2016Amazon Technologies, Inc.Locality based content distribution
US9391949Dec 3, 2010Jul 12, 2016Amazon Technologies, Inc.Request routing processing
US9407681Sep 28, 2010Aug 2, 2016Amazon Technologies, Inc.Latency measurement in resource requests
US9407699Jan 27, 2014Aug 2, 2016Amazon Technologies, Inc.Content management
US9444759Aug 12, 2013Sep 13, 2016Amazon Technologies, Inc.Service provider registration by a content broker
US9444884Jun 13, 2012Sep 13, 2016Level 3 Communications, LlcLoad-aware load-balancing cluster without a central load balancer
US9451040Feb 2, 2015Sep 20, 2016At&T Intellectual Property I, L.P.System and method for selectively caching hot content in a content distribution network
US9451046Jul 22, 2013Sep 20, 2016Amazon Technologies, Inc.Managing CDN registration by a storage provider
US9479476Mar 13, 2012Oct 25, 2016Amazon Technologies, Inc.Processing of DNS queries
US9495338Jan 28, 2010Nov 15, 2016Amazon Technologies, Inc.Content distribution network
US9497259Sep 15, 2012Nov 15, 2016Amazon Technologies, Inc.Point of presence management in request routing
US9515949Oct 24, 2013Dec 6, 2016Amazon Technologies, Inc.Managing content delivery network service providers
US9525659Sep 4, 2012Dec 20, 2016Amazon Technologies, Inc.Request routing utilizing point of presence load information
US9544394Nov 19, 2014Jan 10, 2017Amazon Technologies, Inc.Network resource identification
US9571389Apr 28, 2014Feb 14, 2017Amazon Technologies, Inc.Request routing based on class
US9584870 *Sep 7, 2009Feb 28, 2017Zte CorporationContent locating method and content delivery network node
US9590946Jan 21, 2016Mar 7, 2017Amazon Technologies, Inc.Managing content delivery network service providers
US20090024693 *Jul 17, 2007Jan 22, 2009Jeffrey Mark AchtermannMethod for distributing file content from a selected target depot server in response to multiple client requests
US20090125569 *Nov 8, 2007May 14, 2009Jeffrey Mark AchtermannDynamic replication on demand policy based on zones
US20090248697 *Mar 31, 2008Oct 1, 2009Richardson David RCache optimization
US20090254661 *Mar 21, 2009Oct 8, 2009Level 3 Communications, LlcHandling long-tail content in a content delivery network (cdn)
US20090319612 *Jun 17, 2009Dec 24, 2009Brother Kogyo Kabushiki KaishaInformation distribution system, terminal apparatus, distribution server and introduction server in the information distribution system, and recording medium on which program thereof is recorded
US20100077056 *Sep 21, 2009Mar 25, 2010Limelight Networks, Inc.Content delivery network stream server vignette distribution
US20100088505 *Oct 5, 2009Apr 8, 2010Limelight Networks, Inc.Content delivery network encryption
US20100121940 *Nov 13, 2008May 13, 2010At&T Corp.System and Method for Selectively Caching Hot Content in a Content Delivery System
US20100122303 *Oct 23, 2009May 13, 2010Level 3 Communications, LlcUser authentication in a content delivery network
US20100122305 *Oct 23, 2009May 13, 2010Level 3 Communications, LlcDynamic processing of streamed content
US20100198977 *Sep 27, 2006Aug 5, 2010Adobe Systems IncorporatedAutomatic live stream trees
US20100250772 *Mar 31, 2010Sep 30, 2010Comcast Cable Communications, LlcDynamic distribution of media content assets for a content delivery network
US20100250773 *Mar 31, 2010Sep 30, 2010Comcast Cable Communications, LlcDynamic generation of media content assets for a content delivery network
US20100251313 *Mar 31, 2010Sep 30, 2010Comcast Cable Communications, LlcBi-directional transfer of media content assets in a content delivery network
US20110072134 *Nov 30, 2010Mar 24, 2011Swaminathan SivasubramanianContent management
US20110072140 *Nov 30, 2010Mar 24, 2011Swaminathan SivasubramanianContent management
US20110078240 *Nov 30, 2010Mar 31, 2011Swaminathan SivasubramanianContent management
US20110082982 *Mar 26, 2010Apr 7, 2011Limelight Networks, Inc.Content delivery network cache grouping
US20110314134 *Aug 29, 2011Dec 22, 2011Telefonaktiebolaget L M Ericsson (Publ)Methods and systems for resuming, transferring or copying a multimedia session
US20120023530 *Sep 7, 2009Jan 26, 2012Zte CorporationContent location method and content delivery network node
US20120072527 *Sep 26, 2011Mar 22, 2012Limelight Networks, Inc.Content delivery network cache grouping
US20120254343 *Jun 18, 2012Oct 4, 2012Limelight Networks, Inc.Content delivery network cache grouping
US20130124371 *Nov 15, 2011May 16, 2013Verizon Patent And Licensing Inc.Determining local catalog of digital content
US20130191645 *Mar 11, 2013Jul 25, 2013Amazon Technologies, Inc.Managing secure content in a content delivery network
US20130246555 *Jan 2, 2013Sep 19, 2013Limelight Networks, Inc.Content devliery network cache grouping
US20140032714 *Jul 26, 2013Jan 30, 2014Interdigital Patent Holdings, Inc.Method and apparatus for publishing location information for a content object
US20140173229 *Dec 17, 2012Jun 19, 2014International Business Machines CorporationMethod and Apparatus for Automated Migration of Data Among Storage Centers
US20150156556 *Dec 4, 2013Jun 4, 2015Wowza Media Systems, LLCRouting Media Content Based on Monetary Cost
US20150319194 *Jul 15, 2015Nov 5, 2015Amazon Technologies, Inc.Managing secure content in a content delivery network
EP2274684A2 *Mar 21, 2009Jan 19, 2011Level 3 Communications, LLCHandling long-tail content in a content delivery network (cdn)
EP2274684A4 *Mar 21, 2009Dec 5, 2012Level 3 Communications LlcHandling long-tail content in a content delivery network (cdn)
EP2624524A1 *Feb 4, 2013Aug 7, 2013Comcast Cable Communications, LLCContent distribution network supporting popularity-based caching
EP2738979A1 *Aug 16, 2011Jun 4, 2014Huawei Technologies Co., Ltd.Data stream reused transmission method, duplicate point device and system
EP2738979A4 *Aug 16, 2011Jun 18, 2014Huawei Tech Co LtdData stream reused transmission method, duplicate point device and system
WO2009123868A3 *Mar 21, 2009Jan 7, 2010Level 3 Communications, LlcHandling long-tail content in a content delivery network (cdn)
WO2014195906A3 *Jun 5, 2014Apr 16, 2015Ericsson Television Inc.Defragmentation of adaptive streaming segment files in a content delivery network
Classifications
U.S. Classification709/203
International ClassificationH04L29/08, H04L29/06, G06F13/00, G06F15/173
Cooperative ClassificationH04L67/2814, H04L67/1002, H04L67/1095, H04L67/2842, H04L67/2852, H04L67/2885
European ClassificationH04L29/08N27S, H04L29/08N9R, H04L29/08N27D
Legal Events
DateCodeEventDescription
Oct 27, 2009ASAssignment
Owner name: DIGITAL ISLAND, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SEED, STEVEN L;HOBBS, KEVIN;GLYNN, SHANE M;AND OTHERS;REEL/FRAME:023428/0923;SIGNING DATES FROM 20020204 TO 20020207
Owner name: DIGITAL ISLAND, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SEED, STEVEN L;HOBBS, KEVIN;GLYNN, SHANE M;AND OTHERS;SIGNING DATES FROM 20020204 TO 20020207;REEL/FRAME:023428/0923
Mar 8, 2010ASAssignment
Owner name: CABLE & WIRELESS INTERNET SERVICES, INC.,CALIFORNI
Free format text: CHANGE OF NAME;ASSIGNOR:DIGITAL ISLAND, INC.;REEL/FRAME:024044/0676
Effective date: 20020212
Owner name: SAVVIS ASSET HOLDINGS, INC.,MISSOURI
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CABLE & WIRELESS INTERNET SERVICES, INC.;REEL/FRAME:024044/0814
Effective date: 20040213
Owner name: SAVVIS, INC.,MISSOURI
Free format text: CHANGE OF NAME;ASSIGNOR:SAVVIS ASSET HOLDING, INC.;REEL/FRAME:024044/0902
Effective date: 20040308
Owner name: SAVVIS COMMUNICATIONS CORPORATION,MISSOURI
Free format text: MERGER;ASSIGNOR:SAVVIS, INC.;REEL/FRAME:024044/0940
Effective date: 20050330
Owner name: MOUNT SHASTA ACQUISITION LLC,MISSOURI
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAVVIS COMMUNICATIONS CORPORATION;REEL/FRAME:024046/0218
Effective date: 20070122
Owner name: LEVEL 3 COMMUNICATIONS, LLC,COLORADO
Free format text: MERGER;ASSIGNOR:MOUNT SHASTA ACQUISITION LLC;REEL/FRAME:024046/0304
Effective date: 20070122
Nov 19, 2013ASAssignment
Owner name: LEVEL 3 COMMUNICATIONS, LLC, COLORADO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GREER, WILLIAM PATRICK;REEL/FRAME:031628/0714
Effective date: 20130827