Obviousness

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.