DCT

1:26-cv-00417

Munich Re America Services Inc v. Intellectual Ventures I LLC

Log In
Key Events
Complaint
complaint Intelligence

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:26-cv-00417, D. Del., 04/10/2026
  • Venue Allegations: Venue is alleged to be proper as each Defendant is a resident of, incorporated in, or subject to personal jurisdiction in the District of Delaware. The complaint also alleges Defendants have purposefully availed themselves of the forum by filing prior patent enforcement actions in the district.
  • Core Dispute: Plaintiff Munich Re America Services Inc v. Intellectual Ventures I LLC seeks a declaratory judgment that its use of common third-party software platforms-Docker, Kubernetes, and Spark-does not infringe five U.S. patents that Defendants have asserted against it in a licensing campaign.
  • Technical Context: The technologies at issue are foundational to modern distributed computing, relating to application containerization, container orchestration, and large-scale parallel data processing.
  • Key Procedural History: The action was filed in response to a patent licensing campaign initiated by Defendants in January 2024, which included a formal notice letter in June 2025 and the provision of claim charts in August 2025. The complaint alleges that Defendants have engaged in similar litigation against numerous other companies over the same patents and accused software. The complaint also raises prosecution history estoppel arguments for two of the patents-in-suit, alleging the patentees disclaimed software-only embodiments to secure the patents.

Case Timeline

Date Event
2001-12-18 Priority Date for U.S. Patent No. 8,266,124
2002-03-13 Priority Date for U.S. Patent No. 7,257,582
2004-12-30 Priority Date for U.S. Patent No. 8,332,844
2006-09-27 Priority Date for U.S. Patent No. 7,669,081
2007-08-14 Issue Date for U.S. Patent No. 7,257,582
2007-10-30 Priority Date for U.S. Patent No. 8,352,584
2010-02-23 Issue Date for U.S. Patent No. 7,669,081
2012-09-11 Issue Date for U.S. Patent No. 8,266,124
2012-12-11 Issue Date for U.S. Patent No. 8,332,844
2013-01-08 Issue Date for U.S. Patent No. 8,352,584
2024-01-03 Defendants first contacted Plaintiff to initiate licensing dialogue
2025-06-06 Defendants sent "formal notice" letter accusing Plaintiff of infringement
2025-08-01 Defendants sent claim charts to Plaintiff
2026-01-30 Defendants sent follow-up email regarding infringement allegations
2026-04-10 Complaint for Declaratory Judgment 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 Management

  • Issued: December 11, 2012.

The Invention Explained

  • Problem Addressed: The patent's background describes the inefficiency of managing software images in large computing clusters, noting that creating unique boot images for each server is slow, pre-creating them wastes disk space, and updating them is cumbersome U.S. 8,332,844 B1, col. 1:47-2:4
  • The Patented Solution: The invention proposes a block-level storage system using a common, read-only "root" image and individual, writable "leaf" images for each compute node U.S. 8,332,844 B1, abstract A leaf image stores only the data blocks that are new or changed relative to the root image, which significantly reduces storage overhead and allows for faster creation of new node environments U.S. 8,332,844 B1, col. 2:14-22 The system also includes caching frequently accessed blocks from the root image and sharing indexing results between nodes to improve performance and reduce redundant processing U.S. 8,332,844 B1, abstract
  • Technical Importance: This block-level, copy-on-write approach provided a more efficient method for managing and deploying applications in large-scale distributed computing environments, a precursor to modern containerization technologies.

Key Claims at a Glance

  • The complaint identifies independent claim 7 as the asserted claim Compl. ¶45
  • Essential elements of independent claim 7 include:
    • A method for providing data to a plurality of compute nodes;
    • storing blocks of a root image on a first storage unit;
    • storing leaf images for respective compute nodes on respective second storage units, where the leaf images include only additional data blocks not previously in the root image and changes made to blocks of the root image, and do not include blocks of the root image that are unchanged; and
    • caching blocks of the root image that have been accessed by at least one compute node.
  • The complaint seeks a declaration of non-infringement for all claims of the '844 patent but focuses its non-infringement arguments on claim 7 Compl. ¶¶43, 45

U.S. Patent No. 7,257,582 - Load Balancing with Shared Data

  • Issued: August 14, 2007.

The Invention Explained

  • Problem Addressed: The patent addresses the challenge of distributing a large data processing workload across multiple processors, which may have different performance capacities (heterogeneous), in a way that maximizes overall efficiency (U.S. 7257582B2, col. 1:20-30).
  • The Patented Solution: The patent describes a method where an input file is logically subdivided into multiple partitions without being read first U.S. 7,257,582 B2, abstract Descriptions of these partitions are distributed to a plurality of processors, each of which executes a subtask. After a processor completes its subtask on one partition, it requests another unprocessed partition on a "first-come/first-served basis" U.S. 7,257,582 B2, col. 6:14-22 This "pull" model allows faster processors to naturally take on more work, achieving dynamic load balancing U.S. 7,257,582 B2, abstract
  • Technical Importance: The invention describes a form of dynamic task allocation for parallel data processing, a core concept for achieving efficiency and scalability in distributed computing systems.

Key Claims at a Glance

  • The complaint identifies independent claim 1 as the sole independent claim and the focus of the infringement assertion Compl. ¶¶57, 60
  • Essential elements of independent claim 1 include:
    • A method of effecting on a preexisting input file a computer-executable process, comprising the steps of:
    • (a) automatically... logically subdividing records of said input file into a plurality of partitions;
    • (b) distributing descriptions of all of said partitions to each of a plurality of subtask processors;
    • (c) simultaneously executing... subtasks... on a respective one of the partitions;
    • (d) thereafter repeating step (c)... with another unprocessed partition on a first-come/first-served basis; and
    • (e) generating a combined output.
  • The complaint seeks a declaration of non-infringement for all claims of the '582 patent, focusing its arguments on claim 1 Compl. ¶¶58, 60

Multi-Patent Capsule

  • Patent Identification: U.S. Patent No. 7,669,081, Systems and Methods for Scheduling, Processing, and Monitoring Tasks, issued February 23, 2010.

  • Technology Synopsis: The patent addresses limitations of operating system-level task schedulers by proposing an application-level scheduling framework (U.S. 7669081B2, col. 3:45-4:3). The invention uses "checkpoints," which are logical stages in a process, each associated with rules that define how the process should proceed, enabling complex, stateful workflows with built-in monitoring and recovery capabilities U.S. 7,669,081 B2, abstract

  • Asserted Claims: The complaint identifies independent claim 1 as asserted Compl. ¶76

  • Accused Features: The complaint states Defendants have asserted the '081 Patent against Plaintiff's use of Apache Spark and/or PySpark Compl. ¶73 Compl. ¶34 Compl. Ex. 10

  • Patent Identification: U.S. Patent No. 8,352,584, System for Hosting Customized Computing Clusters, issued January 8, 2013.

  • Technology Synopsis: The patent addresses the high cost and complexity for businesses to own and operate specialized computing clusters (U.S. 8352584B2, col. 1:36-55). It describes a system for remotely hosting multiple, customized computing clusters for different clients, where each client's cluster is isolated from others but managed by a central monitoring system, allowing clients to access tailored computing power as a service U.S. 8,352,584 B2, abstract

  • Asserted Claims: The complaint identifies independent claim 1 as asserted Compl. ¶89

  • Accused Features: The complaint states Defendants have asserted the '584 Patent against Plaintiff's use of Kubernetes Compl. ¶86 Compl. ¶34

  • Patent Identification: U.S. Patent No. 8,266,124, Integrated Asset Management, issued September 11, 2012.

  • Technology Synopsis: The patent describes a system to improve the management of physical IT hardware assets throughout their lifecycle (U.S. 8266124B2, col. 1:19-31). The method involves aggregating information about assets (e.g., location, ownership, software) into a centralized database, which is then used to schedule and manage "transition events" like installations, moves, and maintenance. Information from these events is then recorded back into the database U.S. 8,266,124 B2, abstract

  • Asserted Claims: The complaint identifies independent claim 1 as asserted Compl. ¶109

  • Accused Features: The complaint states Defendants have asserted the '124 Patent against Plaintiff's use of Kubernetes Compl. ¶106 Compl. ¶34

III. The Accused Instrumentality

Product Identification

  • The accused instrumentalities are third-party, open-source software platforms that the complaint alleges Plaintiff uses: Docker, Apache Spark (and its Python API, PySpark), and Kubernetes Compl. ¶34

Functionality and Market Context

  • The complaint describes the accused products as standard, off-the-shelf software, not custom configurations unique to the Plaintiff Compl. ¶33
  • Docker is described as a containerization platform that uses a layered file system with a read-only "image layer" and a writable "container layer" operating on a copy-on-write basis Compl. ¶¶47-48 The complaint includes a diagram from Docker's public documentation showing this layered architecture Compl. p. 14
  • Apache Spark is described as a distributed computing system for large-scale data processing that operates on Resilient Distributed Datasets (RDDs), which are partitioned across the nodes of a cluster for parallel processing Compl. ¶61
  • Kubernetes is described as an open-source platform for automating the deployment, scaling, and management of containerized applications, which are run on clusters of "nodes" Compl. ¶¶90-91 Compl. ¶97
  • The complaint alleges that these are foundational technologies for modern cloud computing, networking, and data processing, and notes that Defendants are engaged in a broad licensing campaign targeting numerous companies for their use of this same software Compl. ¶25 Compl. ¶33 Compl. ¶36

IV. Analysis of Infringement Allegations

'844 Patent Infringement Allegations

Claim Element (from Independent Claim 7) Alleged Infringing Functionality Complaint Citation Patent Citation
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; Defendants allege that Docker's writable "container layer" is a "leaf image" and that its copy-on-write strategy meets this limitation. ¶47 col. 5:6-9
caching blocks of said root image that have been accessed by at least one of said compute nodes in a cache memory. Defendants' allegations are understood to map Docker's underlying storage driver and memory management to this element. ¶45 col. 5:40-45
  • Identified Points of Contention:
    • Technical Question: A central dispute is whether Docker's functionality meets the "only" and "do not include" limitations of the "leaf image" element. The complaint argues that when a file is modified in a Docker container, the underlying storage driver (e.g., OverlayFS) copies the entire file from the read-only "root image" to the writable "leaf image," not just the modified data blocks (Compl. ¶48). This raises the question of whether the accused "leaf image" impermissibly includes blocks from the "root image" that are unchanged, which would run contrary to the explicit claim language.
    • Scope Question: The analysis may also focus on whether a Docker "container" qualifies as a "compute node" under the patent's definition. The complaint argues that a container is merely an isolated software process, whereas the patent defines a "compute node" as a system that "typically includes at least one processing unit 102 and memory 104," suggesting a hardware-based definition not met by the accused software Compl. ¶49 '844 Patent, col. 4:29-31

'582 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
(b) distributing descriptions of all of said partitions to each of a plurality of subtask processors [sic] Defendants allege that Spark's creation of a Resilient Distributed Dataset (RDD) and its partitioning across cluster nodes meets this limitation. ¶61 col. 6:49-53
(d) [sic] thereafter repeating step (c)... in at least some of the subtask processors each with another unprocessed partition on a first-come/first-served basis; and Defendants' infringement theory is alleged to rely on Spark's general job scheduling and task execution model. The complaint provides a diagram of Spark's architecture showing a central driver and worker nodes Compl. p. 21 ¶63 col. 6:14-22
  • Identified Points of Contention:
    • Scope Question: A key dispute may be the interpretation of "distributing descriptions of all of said partitions to each" of the processors. The complaint contends that Spark distributes the data partitions themselves to various nodes, not "descriptions of all" partitions to "each" node Compl. ¶62 This raises the question of whether the system metadata held by Spark's central driver program, which is not distributed to each worker, can satisfy this limitation.
    • Technical Question: The infringement analysis will likely scrutinize whether Spark's task execution model matches the claimed "first-come/first-served basis" "pull" model. The complaint argues that in Spark, tasks operate on partitions located on their specific worker node and do not independently "pull" new, unprocessed partitions from a common pool as required by the claim Compl. ¶¶64-65

V. Key Claim Terms for Construction

  • '844 Patent, Claim 7

    • The Term: "leaf images... including only additional data blocks not previously contained in said root image... wherein said leaf images... do not include blocks of said root image that are unchanged"
    • Context and Importance: This term is central because the complaint's primary non-infringement argument is that Docker's copy-on-write functionality violates these negative limitations. Practitioners may focus on this term because its construction will determine whether proof that Docker copies entire files upon modification-including unchanged portions-is a viable non-infringement defense.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: A party might argue that "blocks of said root image that are unchanged" should be interpreted in the context of the entire file system, and that if a block is part of a file that is changed, it is no longer an "unchanged" block in the claimed sense.
      • Evidence for a Narrower Interpretation: The plain language with its explicit "only" and "do not include" limitations provides strong support for a narrow construction. The patent's abstract distinguishes the leaf image as containing "additional data blocks" and "changes," reinforcing a definition that excludes duplicated, unchanged content from the root image '844 Patent, abstract

  • '584 Patent, Claim 1 (Analyzed in Multi-Patent Capsule)

    • The Term: "at least one hardware processor"
    • Context and Importance: This term is critical because the accused instrumentality, Kubernetes, is a software platform that orchestrates software containers. The complaint argues that Kubernetes itself does not meet this hardware limitation and that the patentee is barred by prosecution history estoppel from arguing that a software or virtualized processor meets the limitation Compl. ¶¶96-98 Practitioners may focus on this term because the patentee explicitly added it to overcome a Section 101 rejection for lacking a hardware component Compl. ¶¶94-95
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: A party could argue that a Kubernetes "node," which can be a physical machine, is the claimed "hardware processor" and that the cluster as a whole meets the claim.
      • Evidence for a Narrower Interpretation: The complaint points to the prosecution history of the parent '841 patent, where the applicant added "hardware processor" to overcome a rejection and argued the amendment was to "include hardware components," expressly disclaiming "any software or virtualized processor" Compl. ¶¶95-96 Compl. Ex. 17 at 9 This file history suggests a narrow interpretation limited to a physical, non-virtualized processor.

VI. Other Allegations

  • Indirect Infringement: As this is a complaint for declaratory judgment of non-infringement, Plaintiff denies all theories of liability. The complaint asserts that because the accused systems do not directly infringe any claim, there can be no indirect infringement (whether induced or contributory) as a matter of law Compl. ¶51 Compl. ¶67 Compl. ¶80 Compl. ¶100 Compl. ¶117
  • Willful Infringement: Willfulness is not alleged by the Plaintiff. However, the complaint establishes a basis for what would be Defendants' potential willfulness claim by citing the "formal notice" letter sent on June 6, 2025, which provided Plaintiff with knowledge of the patents and the infringement allegations Compl. ¶29 Any infringement by Plaintiff after this date could be alleged by Defendants to be willful.

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

  1. A question of technical operation: Does the actual functionality of the accused open-source platforms-Docker, Spark, and Kubernetes-align with the specific and sometimes restrictive mechanisms described in the patents? For example, does Docker's file-based copy-on-write system satisfy the '844 patent's block-level claim that a "leaf image" must only contain new or changed data and not include unchanged blocks from the root image?
  2. A question of claim scope and estoppel: Can claim terms requiring physical hardware, such as "at least one hardware processor" ('584 patent) and "computer-related hardware devices" ('124 patent), be construed to cover the software-based, virtualized constructs of Kubernetes? The case may turn on whether the doctrine of prosecution history estoppel bars such a broad interpretation, given the complaint's allegations that these limitations were added specifically to disclaim software-only embodiments and overcome patent eligibility rejections.
  3. A question of definitional scope: What is the proper construction of "distributing descriptions of all of said partitions to each" processor in the '582 patent? A central issue will be whether this requires a literal broadcast of all partition information to every worker node, as the complaint argues, or if it can be satisfied by the architectural model of Spark, where a central driver maintains global knowledge while workers operate on local data partitions.
Loading Complaint