1:26-cv-01150
Intellectual Ventures II LLC v. United Parcel Service Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Intellectual Ventures II LLC (Delaware)
- Defendant: United Parcel Service, Inc. (Delaware)
- Plaintiff’s Counsel: Sorey & Hoover, LLP; Prince Lobel Tye LLP
- Case Identification: Intellectual Ventures II LLC v. United Parcel Service Inc, 1:26-cv-01150, W.D. Tex. (Austin Division), 07/31/2026
- Jurisdiction & Standing: The complaint pleads that the Court has subject matter jurisdiction under, inter alia, 28 U.S.C. §§ 1331 and 1338(a), and alleges both specific and general personal jurisdiction over UPS. Plaintiff also pleads standing as the owner and assignee of all right, title, and interest in the asserted patents (e.g., the ’844 Patent), including the right to grant licenses, to exclude others, and to recover damages for infringement.
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Defendant maintains a regular and established place of business in the District, including a major distribution facility in Round Rock, Texas, and has allegedly committed acts of infringement within the District.
- Core Dispute: Plaintiff alleges that Defendant’s On-Road Integrated Optimization and Navigation (ORION) system, which runs on a Kubernetes-based computing platform, infringes three patents related to managing and hosting customized, distributed computing clusters.
- Technical Context: The lawsuit concerns foundational technologies in cluster computing, which involves linking multiple computers to work as a single, powerful system, a practice now central to cloud computing, large-scale data analysis, and artificial intelligence workloads.
- Key Procedural History: The filing is a First Amended Complaint. The complaint alleges that Defendant received notice of the asserted patents via an original complaint on May 11, 2026, forming the basis for allegations of willful infringement. The complaint also includes a prayer for relief and a demand for jury trial. Separately, the source bundle includes PTAB inter partes review proceedings on the asserted patents: institution was denied on the ’844 Patent (IPR2025-00931), while an inter partes review of claims 1–5, 7, and 8 of the ’841 Patent was instituted (IPR2022-00906).
Case Timeline
| Date | Event |
|---|---|
| 2003 | UPS launches Package Flow Technology (PFT) foundation |
| 2004-12-30 | Earliest Priority Date for ’844 Patent |
| 2007-10-30 | Earliest Priority Date for ’584 and ’841 Patents |
| 2010-10-26 | ’841 Patent Issued |
| 2012-12-11 | ’844 Patent Issued |
| 2013-01-08 | ’584 Patent Issued |
| 2026-05-11 | UPS allegedly receives notice of asserted patents |
| 2026-07-31 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,332,844 - "ROOT IMAGE CACHING AND INDEXING FOR BLOCK-LEVEL DISTRIBUTED APPLICATION MANGEMENT"
The Invention Explained
- Problem Addressed: The patent addresses inefficiencies in traditional cluster computing, where deploying and updating applications required creating, storing, and distributing complete, identical "boot images" for every compute node in a cluster. This process was resource-intensive, consumed significant storage and bandwidth, and made updates cumbersome. Prior solutions were often tied to a specific operating system, hindering flexibility Compl. ¶¶32-33 ’844 Patent, col. 1:35-2:31
- The Patented Solution: The invention proposes a block-level, operating system-independent method for distributing an application environment. It utilizes a common, read-only "root image" stored on a first storage unit, accessible by all nodes. Individual node-specific modifications are stored in separate, writable "leaf images" on second storage units. These leaf images only contain the new or changed data blocks, not a full copy of the root image. The system also caches frequently accessed blocks from the root image to accelerate boot times for new or restarting nodes Compl. ¶31 Compl. ¶34 ’844 Patent, abstract ’844 Patent, col. 5:21-48
- Technical Importance: This "root-and-leaf" architecture was designed to significantly reduce storage and bandwidth requirements, streamline updates, and improve cluster bring-up times, making large-scale distributed systems more efficient and manageable Compl. ¶¶31-32 Compl. ¶35
Key Claims at a Glance
- The complaint asserts at least independent method claim 7 Compl. ¶37
- Claim 7 includes the following essential elements:
- Storing blocks of a "root image" of compute nodes on a first storage unit.
- Storing "leaf images" for respective compute nodes on second storage units, where the leaf images include only additional or changed data blocks and do not include unchanged blocks from the root image.
- Caching blocks of the "root image" that have been accessed by at least one compute node in a cache memory.
- The complaint does not explicitly reserve the right to assert additional claims but follows standard pleading practice.
U.S. Patent No. 8,352,584 - "SYSTEM FOR HOSTING CUSTOMIZED COMPUTING CLUSTERS"
The Invention Explained
- Problem Addressed: The patent identifies two primary problems with clustered computing at the time of the invention: clusters were expensive and difficult to administer, and available systems often required a uniform design for all clusters. This inflexibility was ill-suited for clients with diverse computational needs who might require different cluster configurations (e.g., high-performance computing versus high-availability) for different tasks Compl. ¶46 Compl. ¶48 ’584 Patent, col. 1:43-53
- The Patented Solution: The patent discloses a system for hosting multiple, customized computing clusters. The architecture uses distinct "gateway" mechanisms to connect each cluster to a common private network. These gateways serve to isolate the network traffic between the different clusters, allowing each to be configured independently for a specific client task. This isolation, combined with connectivity to a common network, enables centralized administration and monitoring of numerous, heterogeneous clusters Compl. ¶47 ’584 Patent, abstract ’584 Patent, col. 5:2-50
- Technical Importance: This invention provided a framework for a "cluster-as-a-service" model, where a provider could host and manage diverse, customized computing environments for multiple clients, abstracting the complexity of the underlying hardware and configuration from the end-user Compl. ¶¶46-47
Key Claims at a Glance
- The complaint asserts at least independent system claim 1 Compl. ¶50
- Claim 1 recites a computer system comprising, among other elements:
- A "private communications network" linked to a "public communications network".
- A "first cluster" in a "first configuration" and a "second cluster" in a "second configuration", where the configurations differ.
- A "monitoring system" for monitoring the clusters.
- A "first gateway" communicatively linked between the first cluster and the private network, and a "second gateway" for the second cluster.
- A requirement that "communications between the first cluster and the second cluster are isolated".
- A requirement that both the first and second clusters are "high performance" clusters.
- The complaint follows standard pleading practice, implicitly reserving the right to assert other claims.
U.S. Patent No. 7,822,841 - "METHOD AND SYSTEM FOR HOSTING MULTIPLE, CUSTOMIZED COMPUTING CLUSTERS"
- Technology Synopsis: The ’841 Patent, a parent to the ’584 Patent, addresses the difficulty of monitoring large, complex, and customized multi-cluster systems. It proposes a layered monitoring architecture comprising a "main monitor" to oversee a plurality of clusters for operational and connectivity issues, and per-node monitors to check for specific hardware and software problems within each node. This allows for scalable monitoring across differentially configured clusters Compl. ¶¶64-65 ’841 Patent, abstract
- Asserted Claims: The complaint asserts at least independent system claim 1 Compl. ¶67 Beyond the monitoring limitation summarized below, asserted claim 1 also recites additional elements that should be charted in parallel with the ’844 and ’584 patents — a private communications network linked to a public communications network, a first cluster and a differently configured second cluster, a monitoring system, and an alert indicating the affected cluster. Count III further alleges that the first configuration differs from the second configuration in the Accused ’841 Products Compl. ¶73
- Accused Features: Plaintiff alleges that the monitoring capabilities within Defendant's Kubernetes-based ORION platform infringe. Specifically, it points to the use of the Kubernetes API as a "main monitor" to oversee cluster health and tools like Node Problem Detectors as "monitors for each node" Compl. ¶¶74-75
III. The Accused Instrumentality
Product Identification
The primary accused instrumentality is United Parcel Service, Inc.’s (UPS) "On-Road Integrated Optimization and Navigation" (ORION) system. The complaint specifies that this system operates on a Kubernetes-based computing infrastructure Compl. ¶39 Compl. ¶52
Functionality and Market Context
ORION is described as a large-scale logistics and route-optimization platform that uses artificial intelligence and machine learning to determine the most efficient delivery routes for UPS drivers Compl. ¶52 The complaint alleges that ORION's architecture, built on Kubernetes, manages containerized optimization workloads across multiple availability zones and is composed of several cluster configurations for specific uses like data ingestion, decision-making, and continuous learning Compl. ¶54 The complaint cites public materials stating the system replans millions of stops every 30 seconds and has saved UPS hundreds of millions of dollars in fuel expenses, positioning it as a mission-critical, high-performance computing system (public materials quoted in the complaint's infringement allegations, not at ¶13 or ¶33).
IV. Analysis of Infringement Allegations
- Across the asserted patents, the complaint pleads direct infringement under 35 U.S.C. § 271(a) — alleging that UPS makes, uses, sells, offers for sale, and/or imports the accused systems (e.g., Compl. ¶37 for the ’844 Patent) — in addition to the element-by-element technical mappings below.
’844 Patent Infringement Allegations
| Claim Element (from Independent Claim 7) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method for providing data to a plurality of compute nodes, comprising: storing blocks of a root image of said compute nodes on a first storage unit; | The complaint alleges the accused ORION products, which run on Kubernetes, store container images in a "read-only layer" or "content store," which functions as the claimed "root image." | ¶40 | col. 7:29-31 |
| storing leaf images for respective compute nodes on respective second storage units, said leaf images including only additional data blocks not previously contained in said root image and changes made by respective compute nodes to the blocks of the root image, wherein said leaf images of respective compute nodes do not include blocks of said root image that are unchanged by respective compute nodes; and | It is alleged that when a container runs, Kubernetes creates a "writeable layer" or "Active snapshot" on top of the original image to store modifications. This writeable layer allegedly functions as the claimed "leaf image," storing only changes. | ¶41; ¶42 | col. 8:1-14 |
| caching blocks of said root image that have been accessed by at least one of said compute nodes in a cache memory. | Plaintiff alleges that the accused Kubernetes-based system uses a "centralized image cache" or "pull-through proxy cache" to store images locally on nodes, preventing repeated downloads from a remote registry. This functions as the claimed "cache memory." A diagram from a technical article depicts this caching architecture. Compl. p. 22 | ¶43 | col. 8:34-40 |
- Identified Points of Contention:
- Scope Question: A central question will be whether the term "root image of said compute nodes", as described in a patent with a 2004 priority date, can be construed to read on a modern "container image" used in Kubernetes. The defense may argue the patent contemplates a full operating system boot image for a server or virtual machine, whereas a container image is a more lightweight, application-focused construct. The complaint uses a diagram depicting the "containerd Image Storage Process" to equate the "content store" with the root image and "snapshots" with the leaf image Compl. p. 20
- Technical Question: The infringement theory for the "leaf image" limitation depends on whether the "writeable layer" in the accused "containerd" runtime functions as claimed—specifically, that it contains only new or changed blocks and does not include unchanged blocks. The complaint cites technical materials to support this Compl. ¶¶41-42, but the actual block-level operation of the accused system will be a critical factual issue for discovery.
’584 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a first cluster comprising a set of computing resources... in a first configuration... a second cluster... in a second configuration... wherein the first configuration differs from the second configuration; | The complaint alleges ORION uses multiple Kubernetes clusters with different configurations for distinct tasks, such as a "Data Ingestion" cluster and a "Decision-Making" cluster. | ¶54; ¶56 | col. 11:13-22 |
| a monitoring system to monitor operations of the first cluster and the second cluster for communications problems; | The accused products allegedly include Kubernetes' native monitoring capabilities, which provide insight into the health, performance, and network status of containerized applications and clusters. | ¶55 | col. 11:23-26 |
| wherein the first cluster establishes communications between the set of computing resources of the first cluster and a first gateway... wherein the second cluster establishes communications... and a second gateway...; | Plaintiff alleges that the accused ORION system uses the Kubernetes Gateway API or a similar ingress mechanism to link each cluster to UPS's private network, with each API instance serving as a claimed "gateway." | ¶59 | col. 11:31-40 |
| wherein the communications between the first cluster and the second cluster are isolated; | The complaint alleges that multi-cluster Kubernetes architectures, as used in ORION, provide for "Workload Isolation" between different clusters, which improves fault tolerance and enforces security policies. A diagram shows two clusters managed via a global load balancer. Compl. p. 36 | ¶61 | col. 12:41-43 |
| wherein the first cluster is a high performance cluster; and wherein the second cluster is a high performance cluster. | The complaint points to public statements that ORION is a massive optimization engine that runs constantly on a bank of servers sized to perform 30,000 optimizations per minute, qualifying the underlying clusters as "high performance." | ¶62 | col. 11:44-46 |
- Identified Points of Contention:
- Scope Question: Practitioners may focus on whether a Kubernetes "Ingress" or "Gateway API", which manages application-layer traffic routing, meets the definition of the claimed "gateway". The defense may argue the patent's depiction of a gateway between a "private company network" and a "private cluster network" implies a more distinct network-level boundary than what is typically provided by a Kubernetes ingress controller operating within a single, flat cluster network.
- Technical Question: The claim requires that communications between the clusters are "isolated". The nature and degree of this isolation will be a key factual dispute. The complaint alleges "workload isolation" Compl. ¶61, but the defense may argue that standard Kubernetes networking does not provide the strict traffic and communication separation implied by the patent's gateway mechanism, which is described as a key benefit of the invention Compl. ¶47
V. Key Claim Terms for Construction
Patent: ’844 Patent
- The Term: "root image of said compute nodes"
- Context and Importance: This term is foundational to the infringement case against the Kubernetes-based ORION system. Its construction will determine whether a modern "container image" falls within the scope of the claim. A narrow construction focused on traditional OS boot images could be dispositive for the defense.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes distributing an "application environment" (e.g., ’844 Patent, col. 2:50-52), which Plaintiff may argue is a functional description that can encompass a modern container.
- Evidence for a Narrower Interpretation: The background repeatedly discusses "boot images" required for a "server" or "compute node" to be "activated" (e.g., ’844 Patent, col. 1:44-54), language that evokes the booting of a full operating system on a physical or virtual machine, not the more lightweight startup of a container.
Patent: ’584 Patent
- The Term: "gateway"
- Context and Importance: The "gateway" is the structural element that allegedly enables the claimed "isolation" between clusters. The complaint equates this term with the Kubernetes Gateway API or Ingress controllers Compl. ¶59 Whether this mapping is correct will be an important disputed issue.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the gateway's function as ensuring "that network traffic for one cluster does not interfere with network traffic for another cluster" ’584 Patent, col. 8:8-10 Plaintiff could argue that any component performing this function, regardless of its name, is a "gateway."
- Evidence for a Narrower Interpretation: The patent figures depict the "gateway" as a distinct architectural component separating a "Private Company Network" from a "Private Cluster Network" ’584 Patent, Fig. 2 The defense may argue this structure implies a formal network-to-network interface, not an application-level router like an Ingress controller that operates within a larger cluster environment.
VI. Other Allegations
Direct Infringement: The complaint expressly pleads direct infringement under 35 U.S.C. § 271(a), alleging that UPS makes, uses, sells, offers for sale, and/or imports systems covered by the asserted claims (e.g., Compl. ¶37).
Prayer for Relief and Jury Demand: The complaint seeks, among other relief, a judgment of infringement, a permanent injunction, an accounting of damages, a mandatory future royalty, enhanced damages under 35 U.S.C. § 284, costs, expenses, and pre- and post-judgment interest, and a determination that the case is exceptional under 35 U.S.C. § 285; Plaintiff also demands a trial by jury.
Indirect Infringement: The complaint alleges induced infringement, stating that UPS encourages and instructs its partners, vendors, customers, employees, and other third parties to use the infringing ORION system Compl. ¶77 Compl. ¶78 It also pleads contributory infringement, alleging ORION is especially made or adapted for infringement and has no substantial non-infringing use Compl. ¶¶79-80
Willful Infringement: Willfulness is alleged based on UPS's purported knowledge of the asserted patents since at least May 11, 2026, the date it allegedly received the original complaint in this matter Compl. ¶76 The allegation is thus based on post-suit conduct.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope and technological evolution: can the claim terms from these 2004-2007 priority-date patents, conceived in an era of physical servers and early virtualization, be construed to cover modern, open-source, cloud-native technologies? Specifically, does a "container image" meet the definition of a "root image" ’844 Patent, and does a "Kubernetes Ingress" function as the claimed isolating "gateway" ’584 Patent?
- A second key question will be evidentiary and functional: beyond general descriptions of how Kubernetes works, what factual evidence will demonstrate that UPS's specific ORION implementation performs the precise functions required by the claims? For instance, does ORION’s "writeable layer" operate exactly as the claimed "leaf image" requires by only storing deltas, and is the "isolation" between its Kubernetes clusters of the same nature and degree as that described in the patents?