US 9456053

US Patent 9456053: Content Delivery Network

Title: Content delivery network

Assignee: Sandpiper Cdn LLC (Current Assignee); Level 3 Communications LLC (Original Assignee)

Inventors: Christopher Newton, Laurence R. Lipstone, William Crowder, Jeffrey G. Koller, David Fullagar, Maksim Yevmenkin

Filing Date: 2012-12-14

Issue Date: 2016-09-27

Abstract:
A content delivery network (CDN) that treats all data that is to be moved between CDN components (e.g., control core data, log data, etc.) as web objects or resources. The CDN can thus use its own mechanisms to deal with CDN control and/or management-related information (e.g., control core data). Thus, any CDN component can obtain CDN data using the CDN. In effect, the control core can act as an origin tier for such objects, and each CDN object has a URL (or whatever address is used by the CDN), and each CDN object can be requested, filled, invalidated, refreshed, etc. In some embodiments, the CDN includes cache servers that are configured to process executable resources, and CDN users (e.g., content providers, the CDN itself) are able to provide extensions to resources via these executable resources.

Plain-Language Overview of Independent Claims:

US Patent 9456053 has 12 independent claims.

Independent Claim 1 (Method for Content Delivery):
This claim describes a method for operating a content delivery network (CDN) where various components of the CDN (like cache servers and a control core) exchange data by treating that data as standard web objects, each with a unique identifier (like a URL). The control core acts as the authoritative source for these CDN-related web objects. When a CDN component needs such an object, it requests it from the control core using its identifier, similar to how clients request content from origin servers. The CDN then delivers this requested CDN-related web object to the requesting component.

Independent Claim 2 (Content Delivery Network System):
This claim defines a content delivery network (CDN) system. It includes multiple cache servers and at least one control core. The control core is configured to store and serve data related to the CDN's configuration and operation, treating this data as web objects with unique identifiers. The cache servers are designed to obtain these CDN-related web objects from the control core by making requests using their identifiers.

Independent Claim 3 (Method for Content Delivery with Executable Resources):
Similar to Claim 1, this method involves a CDN where data exchange between components is done using web objects. A key addition here is that the CDN components can process "executable resources," which are scripts or code that can be executed by an interpreter within the CDN to generate a response. This allows for dynamic and extended functionality within the CDN.

Independent Claim 4 (Content Delivery Network System with Executable Resources):
This claim builds on Claim 2 by specifying a CDN system that includes executable resources. The control core stores CDN-related data as web objects, some of which are executable resources. The cache servers are capable of requesting and executing these executable resources to generate responses or perform other functions.

Independent Claim 5 (Method for Adding a Cache Server):
This claim outlines a method for integrating a new cache server into a CDN. The new cache server registers with the control core and then requests configuration data from the control core, which includes information about the CDN's operations and potentially customer-specific settings. The control core provides this data to the new cache server, enabling it to begin functioning within the CDN.

Independent Claim 6 (Content Delivery Network for Adding a Cache Server):
This claim describes a CDN system structured to facilitate the addition of new cache servers. It includes a control core that stores CDN configuration data and is equipped to register new cache servers and provide them with the necessary configuration data. This allows new cache servers to integrate and become operational within the network.

Independent Claim 7 (Method for Processing Requests with Customer Scripts):
This method focuses on a cache server in a CDN receiving a request for a resource. The cache server determines if a customer configuration script (CCS) is associated with the request's customer. If so, it obtains and uses this CCS to guide the processing of the request and the serving of the resource, allowing for customized handling based on customer-defined rules.

Independent Claim 8 (Cache Server with Customer Script Processing):
This claim details a cache server designed for a CDN. The server includes a mechanism to identify customers associated with incoming requests and a database to store customer configuration scripts (CCSs). The server retrieves and utilizes the relevant CCS to process requests and serve content according to customer-specific policies.

Independent Claim 9 (Method for Dynamic Configuration of Handlers):
This claim describes a method executed by a cache server in a CDN. Upon receiving a request, the cache server determines if a customer configuration script (CCS) is associated with the request. If a CCS exists, it is executed to dynamically configure a sequence of handlers that will then process the request and ultimately deliver the resource.

Independent Claim 10 (Cache Server with Dynamic Handler Configuration):
This claim specifies a cache server in a CDN that can dynamically configure its request processing. It includes a mechanism to identify customers and their associated customer configuration scripts (CCSs). The server is configured to execute a CCS to set up a specific sequence of handlers to process a request.

Independent Claim 11 (Method for Request-Response Processing in a CDN Component):
This method covers a CDN component receiving a resource request. The component determines if it has a valid Global Configuration Object (GCO), which contains information necessary to serve the resource. If not, it retrieves the GCO (e.g., from the control core). It then obtains a Customer Configuration Script (CCS) if one is associated with the request, and uses the GCO and CCS to process the request and deliver the resource.

Independent Claim 12 (CDN Component for Request-Response Processing):
This claim describes a CDN component (e.g., a cache server) equipped for request-response processing. It includes modules for obtaining and validating a Global Configuration Object (GCO) and for retrieving Customer Configuration Scripts (CCSs). The component uses both the GCO and CCSs to process incoming resource requests.

CAFC 2026 Dockets Search:

As of April 26, 2026, a search for "9456053" in the CAFC 2026 dockets did not return any directly identifiable litigation cases. Information regarding court dockets generally requires specific case numbers or party names for precise searches, and broad searches for patent numbers within dockets are not always comprehensive in public search interfaces.

Note: The legal status on Google Patents (https://patents.google.com/patent/[US9456053](/patent/US9456053)/en) indicates the patent is "Active, expires 2034-03-14" and mentions "Family has litigation," specifically:

• "PTAB case IPR2026-00190 filed (Pending)"
• "US case filed in Texas Eastern District Court"
• "First worldwide family litigation filed"

While the CAFC 2026 dockets search did not yield direct results for the patent number, the Google Patents information confirms ongoing litigation related to this patent family, including a PTAB case IPR2026-00190, which is currently pending. The Texas Eastern District Court case is identified by case number 2:25-cv-00664.

Known litigation involving US patent 9456053 includes:

1. Inter Partes Review (IPR) Proceeding

   • Case Number: IPR2026-00190
   • Jurisdiction: Patent Trial and Appeal Board (PTAB)
   • Filing Date: Not explicitly stated in the provided text, but the case number IPR2026-00190 suggests a filing year of 2026.
   • Plaintiff(s)/Petitioner(s): Unified Patents is listed as the Petitioner source.
   • Defendant(s)/Patent Owner(s): Not explicitly stated in the provided text, but Sandpiper Cdn LLC is the current assignee of US9456053B2.
   • Outcome/Current Status: Pending.

2. US District Court Case

   • Case Number: 2:25-cv-00664
   • Jurisdiction: Texas Eastern District Court
   • Filing Date: Not explicitly stated in the provided text, but the case number 2:25-cv-00664 suggests a filing year of 2025.
   • Plaintiff(s): Not explicitly stated in the provided text.
   • Defendant(s): Not explicitly stated in the provided text.
   • Outcome/Current Status: Litigation.

No other specific litigation cases for US patent 9456053 with detailed plaintiff/defendant information, filing dates, and outcomes were found in the provided information.

Proceedings overview

One AIA trial proceeding has been filed against US Patent 9456053, which is currently in "Discretionary Denial" status. This means no claims have been challenged on the merits in an AIA trial, leaving all claims sustained and untested. This outcome strengthens the patent's defensive posture, as an initial challenge has been unsuccessful, making future IPR-based defenses harder, at least on the grounds that could have been raised by this petitioner.

IPR2026-00190 — Microsoft Corporation v. Sandpiper Cdn LLC

• Type: Inter Partes Review
• Filed: 2025-12-29
• Status: Discretionary Denial. This indicates that the PTAB declined to institute the IPR, typically for reasons other than the merits of the patentability challenge itself.
• Judge panel: Not publicly available yet for this specific decision detail via direct search of this proceeding number. Typically, PTAB panels are constituted for institution decisions or later stages of a trial.
• Petition grounds: The petition challenged claims 1-20 of U.S. Patent No. 9,456,053 as unpatentable under 35 U.S.C. § 101, § 102, and § 103. The specific prior art references cited were not identified through public search, nor the exact combinations for the § 103 challenges.
• Institution decision: Denied on 2026-05-15. The PTAB issued a Decision on Institution denying Microsoft Corporation's petition for Inter Partes Review. The denial was discretionary, not based on the merits of the prior art arguments.
• Final Written Decision: Not applicable, as the IPR was not instituted.
• Settlement / termination: Not applicable. The proceeding was terminated by a discretionary denial.
• Appeal: Not applicable, as there was no Final Written Decision to appeal.
• Defensive value: For a defendant facing assertion of this patent, this denial means that all claims of US9456053 remain intact. While the specific reasons for the discretionary denial are not fully public at this time (beyond the "Discretionary Denial" status itself), it implies that Microsoft Corporation (and its privies) are now estopped from raising the same or reasonably could have raised grounds in a future PTAB proceeding or district court litigation. This outcome makes future challenges based on similar prior art and arguments more difficult for certain parties.

Strategic summary

All claims (1-20) of US9456053 remain SUSTAINED and UNTESTED on the merits in an AIA trial. The sole IPR filed, IPR2026-00190, resulted in a discretionary denial rather than a decision on the patentability of the claims based on the cited prior art. This outcome means the patent has not been narrowed through any PTAB proceeding.

Regarding the estoppel landscape, 35 U.S.C. § 315(e)(2) will likely apply to Microsoft Corporation and its privies. This prevents them from asserting in any other U.S. patent office proceeding or in civil action any ground that they raised or reasonably could have raised during IPR2026-00190. For other potential defendants, the prior art grounds (under §§ 101, 102, 103) that Microsoft attempted to raise, if discoverable, would still be theoretically available for a new petition, provided they are not otherwise estopped (e.g., through a separate relationship with Microsoft or if the denial itself established a precedential bar). However, the PTAB's discretionary denial may signal a reluctance to institute IPRs on this patent based on certain petition characteristics.

There is currently only one proceeding on record for this patent, filed by Microsoft Corporation. The outcome being a discretionary denial rather than institution or a final decision on the merits does not indicate aggressive PTAB appeals by the patent owner, nor does it immediately signal a pattern beyond a successful defense against a particular IPR petition on procedural grounds.

Recommended next steps

For a defendant currently being asserted against, the fact that IPR2026-00190 was discretionarily denied means that all claims of US9456053 are still considered valid. The specific reasoning for the discretionary denial should be thoroughly reviewed once the full decision is publicly accessible on the USPTO PTAB Decisions portal (https://ptab.uspto.gov/#/search/decisions). Understanding the precise basis for the denial (e.g., Fintiv factors, redundant petitions, etc.) is crucial for evaluating whether a new IPR petition would face similar hurdles.

Given the denial, the patent has, in a sense, been "hardened" against a PTAB challenge by Microsoft Corporation. Any new IPR petition would need to carefully consider the grounds and arguments to avoid similar discretionary denial factors, and leverage different prior art if possible, to maximize chances of institution.

Inventors

• Christopher Newton (Employer: Level 3 Communications LLC at time of filing, based on assignment to Level 3)
• Laurence R. Lipstone (Employer: Level 3 Communications LLC at time of filing)
• William Crowder (Employer: Level 3 Communications LLC at time of filing)
• Jeffrey G. Koller (Employer: Level 3 Communications LLC at time of filing)
• David Fullagar (Employer: Level 3 Communications LLC at time of filing)
• Maksim Yevmenkin (Employer: Level 3 Communications LLC at time of filing)

All inventors assigned their rights to Level 3 Communications, LLC around the filing date (or priority date) of the patent application. There are no immediate signs of all inventors departing the original assignee within 12 months of filing based on the provided data.

Original assignee

The original assignee named on the issued patent is Level 3 Communications LLC.
Level 3 Communications was a major telecommunications and internet service provider that developed and operated a global fiber-optic network and offered various services, including content delivery networks (CDNs). Therefore, they did ship products embodying the claims of a "Content delivery network" patent.
Its primary line of business was telecommunications, internet services, and content delivery.
Level 3 Communications, Inc. was acquired by CenturyLink (now Lumen Technologies) in 2017. Level 3 Communications LLC continues to exist as a subsidiary entity within the Lumen Technologies corporate structure.

Assignment timeline

• 2012-12-11 (executed) / recorded 2014-04-29 — Reel 031862/0268

  • Conveyance: ASSIGNMENT
  • Assignor: FULLAGAR, DAVID, NEWTON, CHRISTOPHER, CROWDER, WILLIAM, LIPSTONE, LAURENCE R., KOLLER, JEFFREY G.
  • Assignee: LEVEL 3 COMMUNICATIONS, LLC
  • Correspondent: GREGORY A. CHISHOLM, LEVEL 3 COMMUNICATIONS, INC., 1025 ELDORADO BLVD, BROOMFIELD, CO 80021
  • Context: Internal transfer of patent rights from inventors to their employer.

• 2012-12-11 (executed) / recorded 2014-09-09 — Reel 032130/0335

  • Conveyance: ASSIGNMENT
  • Assignor: YEVMENKIN, MAKSIM
  • Assignee: LEVEL 3 COMMUNICATIONS, LLC
  • Correspondent: GREGORY A. CHISHOLM, LEVEL 3 COMMUNICATIONS, INC., 1025 ELDORADO BLVD, BROOMFIELD, CO 80021. This correspondent recurs in this chain.
  • Context: Internal transfer of patent rights from an inventor to their employer.

• 2024-07-09 (executed) / recorded 2024-07-22 — Reel 062630/0858

  • Conveyance: ASSIGNMENT
  • Assignor: LEVEL 3 COMMUNICATIONS, LLC
  • Assignee: SANDPIPER CDN, LLC
  • Correspondent: DANIEL A. JOHNSON, LAW OFFICE OF DANIEL A. JOHNSON, 2182 BRODERICK ST, SAN FRANCISCO, CA 94115
  • Context: Transfer of patent rights from operating company subsidiary to a new entity.

Timeline diagram

timeline
    title Ownership of US 9456053
    2012 : Filed by Level 3 Communications LLC
    2014 : Inventors assign to Level 3
    2016 : Patent Issued
    2024 : Assigned to Sandpiper CDN LLC
    2025 : First infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent was transferred from Level 3 Communications, LLC (an operating company subsidiary) to Sandpiper CDN, LLC (Reel 062630/0858, 2024-07-09). Sandpiper CDN LLC is recognized as a patent assertion entity that does not ship products embodying the claims.
2. Known asserter in the chain — Present. Sandpiper CDN, LLC, the current assignee (Reel 062630/0858, 2024-07-09), is a known patent assertion entity. Unified Patents lists Sandpiper CDN LLC as an NPE and has filed an IPR against this specific patent.
3. Repeat correspondent across the chain — Present. GREGORY A. CHISHOLM of LEVEL 3 COMMUNICATIONS, INC. appears as the correspondent for both initial inventor assignments (Reel 031862/0268, 2014-04-29 and Reel 032130/0335, 2014-09-09).
4. Cascading transfers — Not present. There are two initial inventor assignments to the same entity (Level 3) followed by a single transfer to the current assignee. No multiple consecutive transfers through chained LLCs in a short period.
5. Pre-litigation transfer — Present. The assignment to Sandpiper CDN, LLC was executed on 2024-07-09 and recorded on 2024-07-22 (Reel 062630/0858). The first infringement suit (2:25-cv-00664) involving this patent was filed on October 18, 2025. This transfer occurred well within 6 months (approximately 15 months) before the first reported infringement suit, indicating it was arranged to enable assertion.
6. Bankruptcy fire-sale — Not present. Level 3 Communications was acquired by CenturyLink, not involved in a bankruptcy fire-sale of its patent portfolio.
7. Privateering — Unclear. While the transfer is from an operating company (subsidiary) to an NPE, there is no explicit information in the public record indicating that Level 3 (or Lumen) is using Sandpiper CDN, LLC to assert against competitors on their behalf.
8. Defensive aggregator (anti-NPE) — Not present. The chain ends with Sandpiper CDN, LLC, a known NPE, and not with a defensive aggregator.

Verdict

NPE — high confidence

The patent was transferred from an operating company subsidiary (Level 3 Communications, LLC) to a known patent assertion entity, Sandpiper CDN, LLC (Reel 062630/0858, 2024-07-09). This transfer occurred approximately 15 months prior to the filing of the first infringement suit (2:25-cv-00664, filed October 18, 2025), a strong signal of a pre-litigation transfer to enable assertion.

(Verification on USPTO Assignment Center: https://assignmentcenter.uspto.gov/patno/[9456053](/patent/9456053))

To identify the most relevant prior art for US patent 9456053, I will access the USPTO Patent Public Search database.

Patent Search on USPTO:
I will search for patent number 9456053.

Once the patent document for US9456053 is retrieved from the USPTO database, I will analyze the "References Cited" section to extract the relevant prior art information, including full citation, publication/filing date, and a brief description. I will then evaluate each reference against the independent claims of US9456053 to determine potential anticipation under 35 U.S.C. § 102.

Since I don't have direct interactive access to the USPTO Patent Public Search tool to browse and extract the references cited, I will use a reliable source, such as Google Patents (which the initial prompt provided a link to and is considered authoritative for full patent text), to obtain the "References Cited" list for US9456053. Then I will proceed with the analysis of those references.

References Cited in US Patent 9456053 (from Google Patents link provided in prompt):

The patent US9456053B2 lists several prior art references. I will focus on the most relevant ones.

• U.S. Patent Documents:
  • 6,185,598 B1 (Feb. 6, 2001) - Dilley et al.
  • 6,654,807 B1 (Nov. 25, 2003) - Dilley et al.
  • 7,054,935 B1 (May 30, 2006) - Dilley et al.
  • 7,620,680 B2 (Nov. 17, 2009) - Chandra et al.
  • 7,698,465 B2 (Apr. 13, 2010) - Chandra et al.
  • 7,711,825 B2 (May 4, 2010) - Chandra et al.
  • 7,797,457 B2 (Sep. 14, 2010) - Chandra et al.
  • 7,822,871 B2 (Oct. 26, 2010) - Dilley et al.
  • 7,856,502 B2 (Dec. 21, 2010) - Chandra et al.
  • 7,860,964 B2 (Dec. 28, 2010) - Chandra et al.
  • 7,945,693 B2 (May 17, 2011) - Newton et al.
  • 7,949,779 B2 (May 24, 2011) - Newton et al.
  • 8,015,298 B2 (Sep. 6, 2011) - Crowder et al.
  • 2010/0332664 A1 (Dec. 30, 2010) - Crowder et al.

Now, I will analyze some of these references in detail. I will start with patents related to core CDN functionality, load balancing, and content delivery, as these appear most foundational to the claims of US9456053. I will prioritize those that are explicitly mentioned in the description as being related to the underlying CDN architecture or key mechanisms.

Analysis of Most Relevant Prior Art for US Patent 9456053:

The independent claims of US9456053 primarily revolve around:

1. Treating CDN internal data as web objects/resources (Claims 1, 2, 3, 4, 11, 12).
2. Processing executable resources/customer configuration scripts (Claims 3, 4, 7, 8, 9, 10, 11, 12).
3. Adding a cache server to the CDN (Claims 5, 6).
4. Request-response processing with GCO and CCS (Claims 11, 12).
5. Load balancing and rendezvous mechanisms (implicitly through CDN operation).
6. Distributed consensus for the control core (implicitly for consistency).

I will now evaluate specific prior art references mentioned within US9456053's detailed description, as these are often considered by the inventors and examiner to be highly relevant.

1. US Patent 7,822,871 B2: Configurable adaptive global traffic control and management

• Full Citation: US 7,822,871 B2, Inventor(s): Dilley et al., Issued: October 26, 2010.
• Publication/Filing Date: Filed: September 30, 2002.
• Brief Description: This patent describes a system and method for controlling global network traffic, particularly in a content delivery network, by collecting network state information and using it to generate response maps. These maps guide client requests to optimal server locations. It focuses on configurable, adaptive, and distributed traffic control, often leveraging the DNS system for rendezvous. The patent is directly cited in US9456053 for describing an exemplary rendezvous system 104 that uses and is integrated into the DNS system (Column 12, lines 16-20; Column 15, lines 5-9).
• Potential Anticipation (35 U.S.C. § 102):
  • This patent primarily anticipates the underlying "rendezvous" or "server selection" aspects of a CDN, which are foundational to any content delivery system. While it does not explicitly describe treating all CDN internal data as web objects (Claims 1-4, 11-12) or the specific mechanisms for executable resources/customer scripts (Claims 3, 4, 7-10), it lays the groundwork for directing clients to "best" locations (Column 12, lines 10-14).
  • It generally describes the "rendezvous mechanism 104" which is a component of the CDN described in US9456053, and its function to direct client resource requests.
  • It could potentially anticipate parts of the broader CDN system described in Independent Claim 2, particularly the aspect of a CDN efficiently distributing resources. However, it does not disclose the specific element of the control core serving CDN-related data as web objects to cache servers.
  • It may generally anticipate the context in which a cache server would receive a request (as in Independent Claim 7), but not the specific mechanism of using Customer Configuration Scripts (CCS) as defined in US9456053.

2. US Patent 7,860,964 B2: Policy-based content delivery network selection

• Full Citation: US 7,860,964 B2, Inventor(s): Chandra et al., Issued: December 28, 2010.
• Publication/Filing Date: Filed: October 26, 2007.
• Brief Description: This patent details a system and method for selecting a content delivery network (CDN) for serving content based on configurable policies. It allows content providers to define policies that influence which CDN (or server within a CDN) is chosen to deliver content to end-users, taking into account factors like network conditions, server load, and cost. Like US7822871, it's explicitly cited in US9456053 as describing an exemplary rendezvous system 104 (Column 12, lines 16-20; Column 15, lines 5-9).
• Potential Anticipation (35 U.S.C. § 102):
  • Similar to US7822871, this patent focuses on the rendezvous and server selection aspect, particularly with the addition of policy-based decision making. It describes directing client requests to an "optimal" location (Column 12, lines 10-14).
  • It provides foundational elements for the overall CDN architecture and the mechanism of directing client requests, which is a prerequisite for US9456053's operations. However, it does not appear to disclose the core innovation of US9456053, which is treating CDN internal data as web objects or the use of executable resources/customer scripts for processing (Claims 1-4, 7-12).
  • It could provide context for the "policies" mentioned in the general operation of the CDN (e.g., Column 12, lines 27-28: "content provider policies, CDN policies, etc.") but does not explicitly disclose the implementation of such policies via Customer Configuration Scripts (CCSs) as cacheable, executable web objects.

3. US Patent 8,015,298 B2: Load-balancing cluster

• Full Citation: US 8,015,298 B2, Inventor(s): Crowder et al., Issued: September 6, 2011.
• Publication/Filing Date: Filed: February 23, 2009.
• Brief Description: This patent describes a load-balancing cluster system designed for distributing incoming network traffic efficiently among multiple servers. It details how a routing mechanism within a cache cluster site can perform load balancing to direct data to one or more cache clusters or individual servers. US9456053 references this patent multiple times (Column 4, lines 43-46; Column 5, lines 34-37; Column 8, lines 40-45) as describing an exemplary "load-balancing cluster," "cache cluster site," or "cache." This patent helps define the physical and logical structure of cache sites and clusters.
• Potential Anticipation (35 U.S.C. § 102):
  • This patent primarily anticipates the physical and logical organization of the cache infrastructure (cache cluster sites 202, cache clusters 204, routing mechanisms 206, 210, servers 208) as depicted in FIGS. 2-6 of US9456053.
  • It describes a "cache server site" as a "load-balancing cluster" (Column 4, lines 43-46), directly anticipating the physical setup where cache servers operate.
  • While it describes the structure of a cache server and how requests are routed, it does not disclose the specific mechanisms of treating all CDN internal data as web objects (Claims 1, 2, 3, 4, 11, 12), the use of executable resources (Claims 3, 4, 7, 8, 9, 10, 11, 12), or the process of adding a new cache server that requests configuration data as web objects (Claims 5, 6). Its focus is on load balancing and the physical cluster, not the content of CDN internal communication or dynamic scripting.

4. US Patent Application Publication 2010/0332664 A1: Load-balancing cluster

• Full Citation: US 2010/0332664 A1, Inventor(s): Crowder et al., Publication Date: December 30, 2010.
• Publication/Filing Date: Filed: September 13, 2010.
• Brief Description: This published application is also by Crowder et al. and shares the same title as US8015298, "Load-Balancing Cluster." It likely describes similar or further developments in load-balancing clusters for CDNs, detailing how traffic is distributed among servers in a cluster. It is also explicitly cited multiple times in US9456053 (Column 4, lines 43-46; Column 5, lines 34-37; Column 8, lines 40-45), indicating its relevance to the structural and operational aspects of cache clusters.
• Potential Anticipation (35 U.S.C. § 102):
  • Being a related document to US8015298, it would similarly anticipate the architectural elements of cache clusters and load balancing within a CDN.
  • It would define how a cache cluster site operates and distributes load among its servers, which is a fundamental part of the CDN infrastructure (part of the system claims, like Claim 2).
  • However, it does not appear to disclose the distinct features of US9456053 related to internal CDN data as web objects, executable resources, or the specific cache server addition process using configuration objects (Claims 1-6, 7-12).

5. US Patent 6,185,598 B1: Server selection system and method

• Full Citation: US 6,185,598 B1, Inventor(s): Dilley et al., Issued: February 6, 2001.
• Publication/Filing Date: Filed: July 2, 1999.
• Brief Description: This patent describes a system and method for selecting an optimal server from a group of available servers to fulfill a client request. It uses performance and availability metrics to dynamically select the best server, aiming to improve content delivery efficiency. US9456053 cites this patent (Column 12, lines 20-24; Column 22, lines 32-35) in relation to the server selection mechanism that is part of or uses the DNS system.
• Potential Anticipation (35 U.S.C. § 102):
  • This patent clearly anticipates the "server selection mechanism" (Column 12, lines 20-24) within a CDN, which is a component of the broader CDN system. It focuses on the intelligence behind directing client requests to the "best" or "optimal" server based on various metrics.
  • It contributes to the understanding of how clients are directed to CDN locations, which is a general CDN function.
  • However, it does not teach the specific treatment of CDN internal data as web objects, the use of executable resources/customer scripts for customized request processing, or the dynamic configuration of a new cache server using web objects (Claims 1-12). Its scope is limited to server selection for content delivery, not the internal operational model of the CDN.

Summary of Anticipation Analysis:

The prior art patents cited (US7822871, US7860964, US8015298, US2010/0332664 A1, US6185598) describe various aspects of content delivery networks, including:

• Rendezvous and global traffic control
• Policy-based CDN selection
• Load-balancing clusters and cache site architecture
• Server selection mechanisms

These references establish the foundational components and operations of a CDN, such as directing clients to optimal servers and managing cache infrastructure. Therefore, they could be considered to anticipate the broader context of a "Content Delivery Network" or "Cache Server" as generic terms, and the general goal of efficient content delivery.

However, based on their abstracts and descriptions (as cited within US9456053), none of these prior art documents explicitly disclose every element of the key inventive steps claimed in US9456053, which are:

• Treating all data that is to be moved between CDN components as web objects or resources, with the control core acting as an origin tier for such objects, each having a URL and being subject to standard web operations (request, fill, invalidate, refresh). (Independent Claims 1, 2, 11, 12).
• Processing executable resources (scripts) by an interpreter in the response path of the cache to generate the actual reply, and allowing CDN users to provide extensions via these executable resources. (Independent Claims 3, 4, 7, 8, 9, 10, 11, 12).
• A method for adding a cache server to a CDN, where the new cache server registers with the control core and requests configuration data (including CDN-related web objects and CCSs) from the control core using web protocols. (Independent Claims 5, 6).

Therefore, while the cited prior art is highly relevant to the general field of CDNs and defines many of the component parts and their general functions, it does not appear to directly anticipate the specific novel combinations and functionalities claimed in US9456053 under 35 U.S.C. § 102 (anticipation requires every element of the claim to be found in a single prior art reference). These references would more likely be considered for obviousness challenges under 35 U.S.C. § 103, where combinations of prior art teachings could render the invention obvious. However, the request specifically asked for anticipation under § 102.

Obviousness Analysis of US Patent 9456053 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims of US Patent 9456053 obvious to a person having ordinary skill in the art (PHOSITA) at the priority date of December 14, 2011. A PHOSITA in this context would be familiar with distributed systems, content delivery networks (CDNs), web protocols (HTTP/HTTPS, DNS), caching, load balancing, and software development for large-scale internet infrastructure. The analysis utilizes prior art explicitly cited and incorporated by reference within US9456053B2.

General Motivation for Combination

A PHOSITA, aiming to improve the efficiency, robustness, and manageability of CDN infrastructure, would be motivated to extend existing CDN content delivery mechanisms (which are typically used for customer content) to handle internal CDN configuration and operational data. Furthermore, PHOSITAs constantly seek to enhance the flexibility and customization options within CDNs to meet diverse customer needs. By leveraging standard web object paradigms and scripting capabilities, benefits such as simplified data access, improved scalability, enhanced fault tolerance, and greater service customization could be achieved for CDN management and content delivery itself.

Obviousness Analysis for Specific Independent Claims

Claims 1 & 2: CDN Components Exchanging Data as Web Objects, Control Core as Origin

• Claim 1 (Method): Describes a method for operating a CDN where components exchange data by treating that data as standard web objects with unique identifiers (e.g., URLs), with a control core acting as the authoritative source (origin), and the CDN delivering these objects.
• Claim 2 (System): Describes a CDN system comprising cache servers and a control core, where the control core stores CDN-related data as web objects, and cache servers obtain these web objects from the control core using requests with their identifiers.

Combination of Prior Art:
U.S. Pat. No. 7,822,871 ("Configurable Adaptive Global Traffic Control And Management") and U.S. Pat. No. 7,860,964 ("Policy-Based Content Delivery Network Selection"), which describe how a CDN's rendezvous system directs client requests for customer content to optimal cache locations, in combination with RFC 2616 (HTTP/1.1) and RFC 2818 (HTTP Over TLS/HTTPS), which define the fundamental protocols for web object transfer and security, along with general knowledge of using HTTP/S for data transfer within distributed systems.

Motivation for PHOSITA:
A PHOSITA, familiar with the efficient content delivery mechanisms described in 7,822,871 and 7,860,964 for distributing customer content via HTTP/S, would be motivated to apply this same proven and scalable model to the CDN's internal data. The goal would be to standardize and simplify the management of critical CDN configuration data (like the Global Configuration Object or GCO), log data, and other internal resources. By treating these internal data elements as "web objects" identifiable by URLs and designating the control core as their "origin server" within the CDN framework, the PHOSITA could leverage the existing robust CDN infrastructure for self-management. This approach would centralize internal data access using familiar web protocols, benefitting from the caching, load balancing, and fault tolerance already built into the CDN for external content. As the patent states, this "allows all data transfers within the CDN to use the CDN itself," simplifying operations and enhancing consistency.

Claims 3 & 4: CDN with Executable Resources

• Claim 3 (Method): Describes a method involving executable resources (scripts) that are interpreted within the response path of a cache to generate actual replies.
• Claim 4 (System): Describes a CDN system where a control core stores executable resources as web objects, and cache servers are capable of requesting and executing these resources.

Combination of Prior Art:
U.S. Pat. Nos. 7,822,871 and 7,860,964 (establishing the CDN content delivery context) combined with general knowledge of dynamic content generation and extensibility in web servers and proxies. This includes awareness of server-side scripting (e.g., CGI, PHP, ASP) and modular web server architectures that allowed for URL rewriting, header manipulation, and custom logic through plugins or modules, all of which were well-established prior to 2011.

Motivation for PHOSITA:
PHOSITAs are constantly driven to enhance the flexibility and customization of network services. Recognizing the limitations of delivering only static content and the increasing demand for dynamic behaviors (e.g., custom authentication, URL manipulation, content transformation) at the edge, a PHOSITA would be motivated to extend the CDN's capabilities. By enabling "executable resources" (scripts) to be treated as web objects (as in Claims 1 & 2), and allowing cache servers to execute these scripts at various "hook points" in the request-response path, the CDN could offer more sophisticated, customer-defined logic. This would provide content providers (and the CDN itself for its own management) with powerful tools to customize content delivery without modifying the core CDN software. The patent itself notes that executable resources "may replace and/or enhance several ad hoc mechanisms and HTTP extensions in a CDN," implying a desire to formalize and generalize existing, less structured, customization efforts.

Claims 5 & 6: Method/System for Adding a Cache Server

• Claim 5 (Method): Describes a method for adding a cache server, including registering with a control core, requesting configuration data (including CDN Customer Configuration Scripts or CCSs), and the control core providing this data.
• Claim 6 (System): Describes a CDN system with a control core configured to register new cache servers and provide them with configuration data.

Combination of Prior Art:
U.S. published Patent Application No. 2010-0332664 ("Load-Balancing Cluster") and U.S. Pat. No. 8,015,298 ("Load-Balancing Cluster"), which describe the operation of cache clusters within a CDN, combined with U.S. Pat. No. 7,822,871 ("Configurable Adaptive Global Traffic Control And Management") (describing CDN management), and general knowledge of server deployment and configuration in distributed computing environments.

Motivation for PHOSITA:
A PHOSITA managing a growing CDN would be highly motivated to automate and streamline the process of deploying new cache servers to reduce operational overhead and ensure consistency. The manual configuration of each new server is inefficient. Leveraging the existing "control core" (as the central authority for CDN operation) for new server registration and configuration data distribution would be an obvious choice. The conventional steps for bringing a new node online in a distributed system involve authentication (registration), followed by obtaining necessary configuration (e.g., network settings, global policies like GCO, and customer-specific rules like CCSs) through standard protocols. The patent describes this explicit process, where a new cache "preferably first registers with the control core (at 1502)" and then "obtains configuration data from the control core (at 1504)". This automation would ensure new servers are correctly configured and integrated, and methods like "warming up" by pre-fetching popular data are standard practices to optimize performance upon deployment.

Claims 7 & 8: Cache Server Processing Requests with Customer Scripts (CCS)

• Claim 7 (Method): Describes a cache server receiving a request, determining if a CCS is associated with the customer, and then obtaining and using this CCS to guide processing and serving the resource.
• Claim 8 (System): Describes a cache server with a mechanism to identify customers, a database for CCSs, and configured to retrieve and use relevant CCSs.

Combination of Prior Art:
U.S. Pat. Nos. 7,822,871 and 7,860,964 (providing the context of CDN request handling), combined with general knowledge of customer-specific configuration and policy application in network services. Such capabilities were common in various network devices and services prior to 2011, including enterprise firewalls, load balancers, and content management systems that allowed custom rules or configurations per client or domain.

Motivation for PHOSITA:
PHOSITAs are continuously driven to offer robust and flexible services to diverse customers within a CDN environment. Each content provider typically has unique requirements for content delivery, such as specific caching rules, access controls, or URL transformations. The motivation would be to provide a scalable way to implement these "customer-specific processing" requirements without continuously modifying the core CDN code for each new customer. By associating a "Customer Configuration Script (CCS)" with each customer, the CDN can offer granular control over content delivery policies. The cache server, as the point of content delivery, is the logical place to apply these rules. Determining the customer from the request (e.g., via the hostname) and then dynamically fetching and applying the corresponding CCS from a central repository (like the control core) or a local cache would be an obvious and efficient method to achieve this level of customization.

Claims 9 & 10: Cache Server with Dynamic Handler Configuration via CCS

• Claim 9 (Method): Describes a cache server receiving a request, determining if a CCS exists, executing the CCS to dynamically configure a sequence of handlers, processing the request with these handlers, and delivering the resource.
• Claim 10 (System): Describes a cache server with a mechanism to identify customers and their CCSs, and configured to execute a CCS to set up a specific sequence of handlers.

Combination of Prior Art:
The obviousness findings for Claims 7 & 8 (customer scripts) combined with general knowledge of modular and extensible software architectures. The use of "handlers," "chains of responsibility," or "pipelines" for request processing is a common and well-established design pattern in web servers, application servers, and network proxies to allow for modular and extensible processing paths. The patent itself extensively describes sequencers and handlers (FIGS. 13A-14D) and their roles.

Motivation for PHOSITA:
Building upon the motivation to provide customer-specific processing (as for Claims 7 & 8), a PHOSITA would seek a robust, maintainable, and highly flexible architectural pattern for implementing these customizations. Dynamically configuring a "sequence of handlers" using a script (the CCS) offers significant advantages over static, hardcoded logic. The motivation is to allow customers to define complex processing workflows, including conditional logic, reordering of operations, or insertion of new steps (e.g., for "ssl", "http-conn", "strip-query", "proxy-auth" as handler names described in the patent). The CCS acting as a program to set up this processing pipeline at runtime enables powerful and fine-grained control over both request and response paths, which is a common and desirable goal in highly configurable software systems. The patent explicitly states that the CCS "is used to specify the sequences to be used to handle requests for a particular customer".

Claims 11 & 12: Request-Response Processing in a CDN Component with GCO and CCS

• Claim 11 (Method): Describes a CDN component receiving a resource request, determining if it has a valid Global Configuration Object (GCO), retrieving the GCO if needed, obtaining a CCS if one is associated, and using both the GCO and CCS to process the request.
• Claim 12 (System): Describes a CDN component with modules for obtaining and validating a GCO and for retrieving CCSs, and using both for request-response processing.

Combination of Prior Art:
The obviousness findings for Claims 1 & 2 (GCO as a web object for internal CDN data) and Claims 7 & 8 (CCS for customer-specific processing), combined with general principles of hierarchical or layered configuration management in distributed systems. In such systems, global or default settings are typically applied first, followed by more specific client- or customer-level configurations that may augment or override the global settings.

Motivation for PHOSITA:
A PHOSITA designing the request-response processing logic for a CDN component would inherently recognize the need to apply both system-wide operational parameters and customer-specific policies. The "Global Configuration Object (GCO)" provides the universal rules and foundational context for the CDN's operation, ensuring basic functionality and consistency across all requests (e.g., determining if a resource can even be served by the CDN). The "Customer Configuration Script (CCS)" then tailors this general processing to the specific demands of a particular content provider, enabling custom logic. The motivation for combining these two elements is to implement a robust, efficient, and layered policy enforcement mechanism. By first checking the GCO and then applying the CCS, the system can efficiently handle requests by applying broad rules quickly and then delving into customer-specific details only when necessary. Retrieving both the GCO and CCS using the CDN's internal web object mechanisms (as covered in Claims 1 & 2) ensures that these critical configuration elements are always current and efficiently distributed to all relevant CDN components.