DCT
5:24-cv-04740
Red Hat Inc v. VirtaMove Corp
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Red Hat, Inc. (Delaware)
- Defendant: VirtaMove, Corp. (Canada)
- Plaintiff’s Counsel: Kirkland & Ellis LLP
- Case Identification: 3:24-cv-04740, N.D. Cal., 08/05/2024
- Venue Allegations: Plaintiff Red Hat, Inc. brings this declaratory judgment action in the Northern District of California, alleging venue is proper due to Defendant VirtaMove's business contacts within the district. These contacts include past and present partnerships with California-based companies (e.g., HP, Google), use of servers located in the district, the residence of a former CEO and a current board member in the district, and the fact that the underlying open-source technologies at issue, Kubernetes and Docker, were substantially developed in the district.
- Core Dispute: Plaintiff seeks a declaratory judgment that its OpenShift product does not infringe two of Defendant's patents, which Defendant is actively asserting against other major technology companies (including Plaintiff's parent, IBM) for their use of the same underlying containerization and orchestration technologies.
- Technical Context: The technology at issue is software containerization, a method for packaging applications with their dependencies to run in isolated environments on a shared operating system, which is a foundational technology for modern cloud computing and application deployment.
- Key Procedural History: This action follows a series of lawsuits filed by VirtaMove in Texas against IBM, Amazon, Google, and HPE, alleging infringement of the same two patents. Red Hat states that VirtaMove’s infringement theories in those cases are based on the use of open-source Docker and Kubernetes technology, which Red Hat also uses in its OpenShift product, creating an immediate and justiciable controversy. The complaint also notes that VirtaMove was aware of OpenShift and its use of these technologies, as evidenced by a 2020 blog post on VirtaMove's website.
Case Timeline
| Date | Event |
|---|---|
| 2003-09-15 | U.S. Patent No. 7,519,814 Priority Date |
| 2003-09-22 | U.S. Patent No. 7,784,058 Priority Date |
| 2009-04-14 | U.S. Patent No. 7,519,814 Issued |
| 2010-08-24 | U.S. Patent No. 7,784,058 Issued |
| 2010-11-01 | OpenShift Version 1 Released |
| 2012-05-01 | OpenShift Released as Open Source Project |
| 2013-01-01 | Docker Software First Publicly Released |
| 2013-11-13 | AppZero (VirtaMove Predecessor) Partners with HP |
| 2014-01-01 | Google Announces Kubernetes Launch |
| 2020-04-15 | VirtaMove Announces Partnership with CloudPhysics |
| 2024-01-26 | VirtaMove Sues Amazon.com Services LLC |
| 2024-01-31 | VirtaMove Sues Google LLC |
| 2024-01-31 | VirtaMove Sues International Business Machines Corp. (IBM) |
| 2024-02-09 | VirtaMove Sues Hewlett Packard Enterprise (HPE) |
| 2024-08-05 | Complaint for Declaratory Judgment Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,519,814 - "System for Containerization of Application Sets" (issued Apr. 14, 2009)
The Invention Explained
- Problem Addressed: The patent addresses the cost and complexity of deploying separate physical computer systems for different sets of applications, particularly when those applications have conflicting resource needs (e.g., different library versions) or require secure separation of data ('814 Patent, col. 1:19-45). It notes that existing solutions like full virtualization (e.g., VMware) impose significant performance overhead ('814 Patent, col. 1:51-64).
- The Patented Solution: The invention describes a lightweight virtualization method using "secure containers." A container is a logical grouping of an application and its necessary system files, but importantly, it excludes a full operating system kernel ('814 Patent, Abstract). These containers run in isolation on a host server's single, shared kernel. This allows multiple, otherwise-conflicting applications to coexist efficiently on one machine by providing each with its own virtualized environment, including a unique file system, without the overhead of a full virtual machine ('814 Patent, col. 2:28-48; col. 4:18-24).
- Technical Importance: This technology provided a conceptual framework for a more resource-efficient approach to server consolidation than full virtualization, which was a significant concern in managing growing data centers. ('814 Patent, col. 1:46-50).
Key Claims at a Glance
- The complaint notes VirtaMove has asserted claims 1, 2, 6, 9, and 10 in related litigation (Compl. ¶67). Independent claim 1 is central and requires:
- A plurality of "secure containers" of application software.
- Each container includes applications and "associated system files" for use with a local, permanent kernel, but "excluding a kernel" itself.
- The system files in the container are "utilized in place of" the local system files on the server.
- The application software "cannot be shared" between containers.
- Each container has a "unique root file system that is different from an operating system's root file system".
U.S. Patent No. 7,784,058 - "Computing System Having User Mode Critical System Elements as Shared Libraries" (issued Aug. 24, 2010)
The Invention Explained
- Problem Addressed: The patent identifies limitations caused by the centralized control of "critical system elements" (CSEs) within a single operating system kernel. Such centralization can lead to conflicts when different applications require different versions of the same file or have incompatible needs for a shared network service ('058 Patent, col. 1:20-33).
- The Patented Solution: The invention proposes an architecture where replicas of kernel-level CSEs are provided as user-mode components, termed "Shared Library Critical System Elements" (SLCSEs), and stored in a shared library ('058 Patent, Abstract). An application can then link to a specific instance of an SLCSE, giving it a private, un-shared copy of that system resource that runs within the application's own context. This allows multiple applications with conflicting dependencies to run simultaneously on the same OS without interfering with each other ('058 Patent, col. 2:6-21).
- Technical Importance: This approach allows for the creation of customized, isolated execution environments for individual applications, enabling greater flexibility for deploying legacy or otherwise incompatible software on a single, modern operating system. ('058 Patent, col. 1:46-54).
Key Claims at a Glance
- The complaint notes VirtaMove has asserted claims 1, 2, 3, 4, and 18 in related litigation (Compl. ¶72). Independent claim 1 is central and requires:
- An operating system with an OS kernel having "OS critical system elements (OSCSEs)" for running in kernel mode.
- A "shared library" having "shared library critical system elements (SLCSEs)" which are "functional replicas" of the OSCSEs.
- An "instance of a SLCSE" provided from the shared library runs in the context of a first application "without being shared" with other applications.
- A second application can simultaneously run a "second instance of the SLCSE".
III. The Accused Instrumentality
Product Identification
- The complaint seeks a declaration of non-infringement for Plaintiff's Red Hat OpenShift product, particularly the OpenShift Container Platform (Compl. ¶27).
Functionality and Market Context
- Red Hat OpenShift is described as an enterprise-grade platform for building, deploying, and managing containerized applications at scale (Compl. ¶37). It is built upon a foundation of open-source technologies, primarily using Kubernetes for container orchestration and OCI-compliant formats (like Docker) for container images (Compl. ¶¶37, 39). The platform allows developers to package an application with its dependencies (e.g., libraries, configuration files) into a portable container image using a "Dockerfile" (Compl. ¶54). These containers are then deployed on servers where they share the host's operating system kernel but run in isolated processes (Compl. ¶29). The complaint characterizes OpenShift as a "leading enterprise Kubernetes platform" (Compl. ¶37).
IV. Analysis of Infringement Allegations
The complaint does not contain infringement allegations by Red Hat, but rather describes Red Hat's understanding of VirtaMove's infringement theories from parallel litigation. The following charts summarize these anticipated allegations.
'814 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality (per Red Hat's understanding of VirtaMove's theory) | Complaint Citation | Patent Citation |
|---|---|---|---|
| a plurality of secure containers of application software... each container comprising one or more of the executable applications and a set of associated system files | VirtaMove's theory is that Docker containers, Kubernetes containers, or pods, which are used by OpenShift, are the claimed "secure containers." These containers bundle application software with necessary user-space libraries and files (e.g., libc/glibc). | ¶¶54-55 | col. 2:28-39 |
| the containers of application software excluding a kernel | VirtaMove's theory relies on the fact that containerization technology, as used in OpenShift, involves containers sharing the host machine's OS kernel rather than bundling their own. The complaint includes a diagram from IBM documentation illustrating that containers share the same base kernel. (Compl. p. 15). | ¶56 | col. 2:38-39 |
| wherein each of the containers has a unique root file system that is different from an operating system's root file system | VirtaMove's theory is that building a Docker image from a Dockerfile, as is done in OpenShift, creates a container with a root file system that is distinct from the host OS's root file system. | ¶57 | col. 4:20-24 |
'058 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality (per Red Hat's understanding of VirtaMove's theory) | Complaint Citation | Patent Citation |
|---|---|---|---|
| a shared library having shared library critical system elements (SLCSEs) stored therein for use by the plurality of software applications in user mode | VirtaMove's theory is that the process of creating a container image (e.g., a Docker image from a Dockerfile) that packages an application with all of its dependencies constitutes providing the claimed "SLCSEs." The complaint includes a diagram from OpenShift's own documentation showing the process of building a container image from a Dockerfile. (Compl. p. 13). | ¶¶58, 17 | col. 2:10-14 |
| wherein an instance of a SLCSE provided... is run in a context of said... software application without being shared with other software applications | VirtaMove's theory is that when an application runs inside its container, its dependencies are isolated and not shared with applications in other containers, thereby meeting this limitation. | ¶¶11-12 | col. 2:15-18 |
Identified Points of Contention:
- Scope Questions: A primary issue will be whether the claims, which appear to describe a specific, bespoke system involving a "kernel module" ('814 Patent, Fig. 4) and replicated OS services in "shared libraries" ('058 Patent, col. 2:45-48), can be construed to cover modern containerization platforms like Docker and Kubernetes. These platforms rely on different underlying mechanisms like kernel namespaces and cgroups, which were developed years after the patents' priority dates.
- Technical Questions: The complaint raises direct technical disputes. For the '814 patent, Red Hat argues its containers are not "mutually exclusive" as required by claim language because they can be configured to share read/write files (Compl. ¶61). For the '058 patent, Red Hat argues that its applications do not access "functional replicas of OSCSEs" from a "shared library"; instead, dependencies are installed into a container base image, suggesting a fundamental operational difference from the claimed invention (Compl. ¶62).
V. Key Claim Terms for Construction
Term: "secure container" ('814 Patent)
- Context and Importance: The definition of this term is critical to determining whether modern Docker/OCI containers, the foundation of OpenShift, fall within the patent's scope. Practitioners may focus on whether the term is limited to the specific implementation disclosed or can be read more broadly to encompass any technology that isolates applications.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification provides a functional definition: "An environment where each application set appears to have individual control of some critical system resources and/or where data within each application set is insulated from effects of other application sets" ('814 Patent, col. 2:42-48). This could be argued to describe the outcome of modern container isolation.
- Evidence for a Narrower Interpretation: The detailed description and figures repeatedly reference a "kernel module" that intercepts system calls to create the containerized environment ('814 Patent, Fig. 4, col. 7:60-65). This suggests the invention may be tied to a specific intercept-based architecture, not the namespace-based architecture of modern containers.
Term: "shared library having shared library critical system elements (SLCSEs)" ('058 Patent)
- Context and Importance: This term is the core of the '058 invention. The case may turn on whether bundling dependencies into a container image is legally equivalent to providing "SLCSEs" in a "shared library." Red Hat's non-infringement argument is centered here (Compl. ¶62).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: VirtaMove may argue that a container image functionally serves as the "library" that delivers the replicated system elements (SLCSEs) to the application in user mode, regardless of the exact file format.
- Evidence for a Narrower Interpretation: The specification states that "SLCSEs are placed in shared libraries, thereby becoming application libraries, loaded when the application is loaded" ('058 Patent, col. 2:45-48). This language, along with the term "shared library" itself (akin to a
.soor.dllfile), suggests a specific dynamic linking and loading process, which may be technically distinct from simply packaging files into a static image that is mounted as a file system.
VI. Other Allegations
Indirect Infringement
- As this is a declaratory judgment action, Red Hat asserts its own non-infringement. It states that it "has not caused, directed, requested, or facilitated any such infringement, much less with the specific intent to do so," and that OpenShift is "a product with substantial uses that do not infringe" (Compl. ¶60).
Willful Infringement
- Willfulness has not been alleged against Red Hat. However, the complaint preemptively addresses the knowledge element that would be required for such a claim by noting VirtaMove's public statements about OpenShift, which demonstrate VirtaMove's awareness of the technology (Compl. ¶51). This proactive filing may be intended to mitigate future willfulness claims.
VII. Analyst’s Conclusion: Key Questions for the Case
Jurisdictional Ripeness
- A threshold question will be whether an "actual controversy" exists between Red Hat and VirtaMove sufficient for a declaratory judgment action. The court will need to decide if VirtaMove's aggressive litigation against Red Hat's parent company (IBM) and other industry players using the same open-source components creates a sufficiently "real and immediate" threat of suit to Red Hat.
Definitional Scope
- The central dispute will likely be one of claim construction and technological evolution: can the terms of these early-2000s patents, such as "secure container" and a "shared library" of replicated OS components, be interpreted to cover modern, open-source containerization technologies like Docker and Kubernetes, which function using different architectural principles developed years later?
Operational Mismatch
- A key evidentiary question will be one of technical function: does OpenShift's method of building containers by layering dependencies onto a base image constitute providing "functional replicas of OSCSEs" in a "shared library" as required by the '058 patent, or is this a fundamentally different technical operation, as the complaint alleges?