DCT

2:24-cv-00886

Sandpiper CDN LLC v. Comcast Cable Communications LLC

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:24-cv-00886, E.D. Tex., 11/01/2024
  • Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendants maintain a regular and established place of business in the district, conduct business from locations in Plano, Texas, and have employees in Texas involved in the accused technology.
  • Core Dispute: Plaintiff alleges that Defendant’s Content Delivery Network (CDN) functionalities, which power services like the Xfinity X1 platform and Peacock streaming, infringe five patents related to foundational CDN technologies.
  • Technical Context: Content Delivery Networks (CDNs) are critical internet infrastructure that distribute content from servers geographically closer to end-users, reducing latency and improving performance for streaming video and other high-bandwidth applications.
  • Key Procedural History: The complaint details a corporate history where the asserted patents and underlying technology were developed by Sandpiper Networks, Inc. in the 1990s, later acquired by Digital Island, then Level 3 in 2007, and finally sold to the current Plaintiff, Sandpiper CDN, LLC, in early 2024.

Case Timeline

Date Event
1998-02-10 U.S. Patent No. 8,478,903 Priority Date
2000-01-28 U.S. Patent No. 7,013,322 Priority Date
2006-03-14 U.S. Patent No. 7,013,322 Issue Date
2008-04-04 U.S. Patent No. 9,762,692 Priority Date
2010-01-01 Approx. date Comcast began building its in-house CDN
2012-12-13 U.S. Patent No. 9,628,347 Priority Date
2012-12-13 U.S. Patent No. 9,660,876 Priority Date
2013-07-02 U.S. Patent No. 8,478,903 Issue Date
2015-04-01 Approx. date Comcast released "Traffic Control" as open source software
2017-04-18 U.S. Patent No. 9,628,347 Issue Date
2017-05-23 U.S. Patent No. 9,660,876 Issue Date
2017-09-12 U.S. Patent No. 9,762,692 Issue Date
2024-11-01 Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 9,628,347 - “Layered Request Processing in a Content Delivery Network (CDN)”

The Invention Explained

  • Problem Addressed: As CDNs grew, they were tasked with delivering diverse content types (video, images, text) from various origin servers, each with unique configurations. A conventional "one-size-fits-all" approach to processing content requests was inefficient for this complex environment (Compl. ¶38).
  • The Patented Solution: The invention proposes a method for processing content requests through a series of configurable "layers." Each layer can handle a specific aspect of the request, and layers can conditionally modify a "runtime environment" that is passed to subsequent layers. This allows for a modular and adaptable request processing flow, where the actions of one layer can influence the processing performed by the next (Compl. ¶39-40; ’347 Patent, col. 64:11-16).
  • Technical Importance: This layered approach allows for the creation of distinct levels of configuration for different services, potentially improving performance and lowering latency for content delivery (Compl. ¶40).

Key Claims at a Glance

  • The complaint asserts independent claim 1 (Compl. ¶63).
  • Essential elements of claim 1 include:
    • Receiving a request for a content delivery service.
    • The service defining a number of configurable layers of request processing in sequential order.
    • Processing the request starting at a first layer, based on a modifiable runtime environment.
    • Continuing processing conditionally through each layer until the request is terminated or the last layer processes it.
    • Wherein at least one layer modifies the modifiable control environment to produce a modified control environment.
    • Wherein processing by a subsequent layer is based on the modified control environment.
  • The complaint reserves the right to assert other claims, including dependent claims 2 and 4 (Compl. ¶63, fn. 34).

U.S. Patent No. 9,660,876 - “Collector Mechanisms in a Content Delivery Network”

The Invention Explained

  • Problem Addressed: Evolving CDNs faced challenges in configuring network components to handle different content types and delivery parameters (e.g., security, quality) in a scalable and efficient manner (Compl. ¶42).
  • The Patented Solution: The invention describes a system where a "collector" receives multiple "event streams" containing data about CDN operations. The system processes this event data to produce "state data," which is then used to inform a "peering policy" for a set of caches. This allows the CDN's behavior to be dynamically adjusted based on real-time operational data (Compl. ¶43; ’876 Patent, Abstract).
  • Technical Importance: Using state data from event streams to inform peering policies enables customization of CDN components, which can improve computational efficiency, fault tolerance, and the ability to handle specific requests for specific users (Compl. ¶44).

Key Claims at a Glance

  • The complaint asserts independent claim 1 (Compl. ¶76).
  • Essential elements of claim 1 include:
    • In a CDN with multiple content delivery services, operating a collector system.
    • The collector system receiving multiple event streams of event data, where each event has a timestamp.
    • The collector system producing state data based on the information in the event data.
    • While producing state data, the collector system asynchronously responds to at least one query relating to the state data.
    • In response to a query from a first content delivery service, providing at least some of the state data to that service.
    • Wherein the state data is used to inform a peering policy of a set of peer caches.
  • The complaint states its belief that other claims of the patent are also infringed (Compl. ¶76, fn. 51).

U.S. Patent No. 8,478,903 - "Shared Content Delivery Infrastructure"

  • Technology Synopsis: The patent addresses performance issues that arise when a single origin server is inundated with requests. The solution involves off-loading requests to a network of "repeater servers" that replicate and cache content, thereby improving performance and providing additional bandwidth (Compl. ¶46-47; ’903 Patent, col. 2:62-65). It also discloses technology for delivering resources from more than one content provider using a shared server and alias names (Compl. ¶48).
  • Asserted Claims: At least claim 28 is asserted (Compl. ¶87).
  • Accused Features: Comcast's CDN functionalities, which allegedly use alias names and shared repeater/cache servers to manage requests and deliver content from multiple origin servers for services like gaming and video playback (Compl. ¶88-91).

U.S. Patent No. 7,013,322 - "System and Method for Rewriting a Media Resource Request and/or Response between Origin Server and Client"

  • Technology Synopsis: The patent addresses network inefficiency caused by the number of "hops" required to transfer data between a source and a user. It proposes a distributed network that intercepts and modifies (or "rewrites") data resource requests and responses to optimize the delivery path, for instance by routing a user to a closer server (Compl. ¶53-54; ’322 Patent, col. 3:45-50).
  • Asserted Claims: At least claims 11 and 16 are asserted (Compl. ¶97).
  • Accused Features: Comcast's CDN functionalities, which allegedly use Apache Traffic Control and Traffic Server to intercept and modify HTTP requests and responses via "consistent hashing" and header rewrite plugins, thereby controlling the routing of data (Compl. ¶98-101).

U.S. Patent No. 9,762,692 - "Handling long-tail content in a content delivery network (CDN)"

  • Technology Synopsis: The patent addresses inefficiencies in handling "long-tail" (unpopular) content in a CDN. Caching unpopular content can waste storage and increase latency. The invention describes a tiered server system where a first tier of servers determines if a requested resource is popular; if so, it obtains and serves the resource, and if not, it directs the client to a second tier of servers that holds the less popular content (Compl. ¶58-60).
  • Asserted Claims: At least claims 1, 2, 7, and 8 are asserted (Compl. ¶105).
  • Accused Features: Comcast's CDN, which allegedly employs a tiered architecture of edge-tier and mid-tier cache servers. The system is accused of using a "Cache Promote Plugin" to determine resource popularity and direct requests for unpopular content to a mid-tier server, while serving popular content from the edge-tier (Compl. ¶106-110).

III. The Accused Instrumentality

Product Identification

  • The "accused Comcast CDN functionalities" (Compl. ¶33, 61). These functionalities are allegedly embodied in Comcast products and services that use Apache Traffic Control (ATC), Apache Traffic Server, Apache Kafka, and other bespoke CDN architecture (Compl. ¶27, 31, 61). Services identified as using these functionalities include Comcast's Xfinity X1 platform, NBCUniversal broadcast networks (e.g., Peacock), and business solutions such as CTSuite Services (Compl. ¶33).

Functionality and Market Context

  • The complaint alleges that Comcast's CDN is a large-scale, distributed system of servers designed for high-performance media delivery (Compl. ¶26, 28). It is described as having a tiered architecture, including "mid-tier" and "edge-tier" server assemblies, to manage traffic from origin servers to clients (Compl. ¶30). The complaint presents a diagram illustrating this tiered CDN structure, which is designed to minimize traffic to origin servers and maximize concurrent users (Compl. p. 12). The system allegedly uses open-source software like Apache Traffic Control as its core, which provides tools for routing, caching, and extending capabilities through a library of plugins (Compl. ¶27-29). The complaint further alleges the use of Apache Kafka, a distributed event streaming platform, to efficiently update the CDN based on event streams (Compl. ¶31).

IV. Analysis of Infringement Allegations

U.S. Patent No. 9,628,347 Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
a computer-implemented method...in a content delivery network (CDN)...receiving a request for a content delivery (CD) service of a particular service type... The accused functionalities receive client requests for content delivery via systems like Apache Traffic Control (ATC) that act as a traffic router or traffic server. ¶65 col. 63:63-65
wherein said CD service of said particular service type defines a fixed number of configurable layers of request processing...in sequential order from a particular first layer to a particular last layer... Comcast's ATC and Traffic Server allegedly use plugins that can be sequentially connected to form configurable layers of processing, and provide "continuations" to handle HTTP transactions sequentially. ¶66 col. 64:1-5
processing said request, starting at said particular first layer, said processing being based on a modifiable runtime environment... The accused functionalities allegedly deploy plugins (e.g., Denylist, Compress, Header Manipulation) to process the request, which starts at a first layer and is based on a modifiable runtime environment. ¶67 col. 64:6-8
said processing continuing conditionally through each of said particular layers in turn until either said request is terminated by one of said layers or said particular last layer processes said request... Processing allegedly continues through a sequence of plugins or "continuations," which are described as event-driven state machines that execute until a waiting point is reached or the transaction is complete. A diagram in the complaint illustrates a plugin architecture for Traffic Server (Compl. p. 27). ¶67 col. 64:8-12
wherein, in processing of said request, at least one of said layers modifies said modifiable control environment to produce a modified control environment... The accused functionalities allegedly use plugins, such as a Denylist plugin or a remap plugin, to modify the control environment by altering how an HTTP transaction is handled or by affecting the output of a request. ¶72 col. 64:12-16
and wherein processing of said request by a subsequent layer is based on the modified control environment. The system allegedly processes requests where a remap plugin is reloaded during runtime, modifying the runtime environment for subsequent processing based on the new file loaded by the plugin. ¶72 col. 64:16-18
  • Identified Points of Contention:
    • Scope Questions: A central dispute may be whether the sequential execution of software "plugins" and event-driven "continuations" within Apache Traffic Server constitutes "a fixed number of configurable layers of request processing" as required by the claim. The defense may argue that a plugin architecture is fundamentally different from the "layers" contemplated by the patent.
    • Technical Questions: The complaint alleges that one layer modifies a control environment that is then used by a subsequent layer. A technical question will be what specific data constitutes the "modifiable control environment" in the accused system and how that environment is passed between and acted upon by distinct, subsequent "layers" (plugins).

U.S. Patent No. 9,660,876 Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
...a collector system receiving multiple event streams of event data from a plurality of CD services in said CDN...each event of said event streams comprising a timestamp for said event... Comcast's CDN functionalities allegedly use Apache Kafka, an event streaming platform, which runs as a cluster of servers to publish and subscribe to streams of events, with each event conceptually having a key, value, and timestamp. ¶78, 80 col. 2:1-4
...said collector system producing state data relating to and based on information represented in said event data of said multiple event streams... The accused system allegedly uses Kafka to capture data in real-time from various sources and store these event streams durably as a log of state changes, such as in timestamped, versioned key-value stores. ¶81 col. 2:5-8
wherein, while said collector system is producing said state data, said collector system asynchronously responds to at least one query relating to said state data... Apache Kafka allegedly allows workers in a cluster to consume a topic asynchronously, creating a delay before a state change is visible via an API, while the system simultaneously produces state data. ¶82 col. 2:8-11
in response to a query...from a first CD service, said query relating to said state data, providing at least some of said state data to said first CD service... The accused system allegedly implements Kafka to provide a response to a web service call (a query) that relates to state data for a content delivery service. ¶83 col. 2:11-14
wherein said state data are used to inform a peering policy of a set of peer caches. The complaint alleges that the accused functionalities use state data to inform policy. One example cited is the use of a configurable "Pdflush" policy in Linux for maintaining data in a page cache, which is allegedly based on state data. A diagram in the complaint depicts updating a CDN cluster using Kafka (Compl. p. 38). ¶84 col. 2:14-16
  • Identified Points of Contention:
    • Technical Questions: The complaint's theory connects Apache Kafka's event streaming to informing a "peering policy." A key technical question will be what evidence shows that the state data produced by Kafka (e.g., for updating content or monitoring) is actually used to define or modify policies governing how different peer caches in the CDN interact with one another (e.g., how one cache decides to retrieve content from another).
    • Scope Questions: The term "peering policy" may be a point of contention. The defense could argue that the examples provided in the complaint, such as the "Pdflush" page cache policy, relate to single-server memory management rather than a "peering policy" governing a "set of peer caches" as the term is used in the patent.

V. Key Claim Terms for Construction

  • For the ’347 Patent:

    • The Term: "configurable layers of request processing"
    • Context and Importance: This term is the core of the asserted invention. The infringement case for the '347 patent depends on whether the accused architecture based on Apache Traffic Server's plugins and "continuations" meets this definition. Practitioners may focus on this term because the defendant will likely argue that its software plugin architecture, where functions can be chained, is not equivalent to the more structured "layers" required by the claim.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The specification states that the layers can be used to "augment or modify the subscriber/coserver sequence" and that the layered approach allows for "separate levels of configuration for each service," suggesting a focus on functional modularity rather than a rigid structural arrangement ('347 Patent, col. 65:67-66:2, col. 67:37-38).
      • Evidence for a Narrower Interpretation: The term "fixed number of configurable layers" in the claim itself, along with figures depicting sequential processing flows (e.g., Fig. 3F), may suggest a more defined, ordered, and structured sequence than a dynamically assembled chain of software plugins.

  • For the ’876 Patent:

    • The Term: "peering policy of a set of peer caches"
    • Context and Importance: The infringement allegation hinges on linking the "state data" produced by the accused Kafka system to the function of informing a "peering policy." The definition of this term will be critical to establishing that causal link. Practitioners may focus on whether "peering policy" is limited to rules governing how caches retrieve content from each other, or if it can be read more broadly to include any policy affecting a cache's behavior.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The abstract broadly states that "state data are used to inform a peering policy of a set of caches." The specification discusses using the policy to determine "the applicable chain of responsibilities," which could be interpreted broadly to cover more than just inter-cache fetching ('876 Patent, col. 52:16-18).
      • Evidence for a Narrower Interpretation: The specification provides a specific example where a policy determines how to combine a "previous allocation and the new allocation" when a node becomes unavailable or degraded, suggesting the policy is specifically about managing cache relationships and fault tolerance ('876 Patent, col. 53:35-39). This could support a narrower definition focused on inter-cache coordination.

VI. Other Allegations

The complaint does not contain specific counts or allege specific facts to support claims of indirect or willful infringement. The Prayer for Relief requests a finding that the case is "exceptional" but does not plead facts supporting a willfulness claim (Compl. p. 76).

VII. Analyst’s Conclusion: Key Questions for the Case

This case appears to center on whether modern, open-source-based CDN architectures fall within the scope of patent claims drafted for earlier generations of CDN technology. The key questions for the court will likely be:

  1. A core question of definitional scope: Does the modular software architecture of Apache Traffic Server, which uses chained "plugins" and event-driven "continuations," constitute the "configurable layers of request processing" as claimed by the '347 patent, or is there a fundamental structural and operational difference?
  2. A key question of functional linkage: What evidence connects the "state data" produced by the accused Apache Kafka event-streaming system to the specific function of informing a "peering policy" that governs how multiple peer caches interact, as required by the '876 patent?
  3. A central question of technological applicability: Can the foundational CDN concepts from the earlier-priority patents, such as rewriting requests ('322 Patent) and using shared servers with aliases ('903 Patent), be mapped onto the complex, multi-tiered, and highly distributed architecture of the modern Comcast CDN, or has the technology evolved beyond the scope of these claims?