VirtaMove Corp v. Oracle Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:

  • Plaintiff: VirtaMove, Corp. (Canada)
  • Defendant: Oracle Corporation (Delaware)
  • Plaintiff’s Counsel: Russ August & Kabat

• Case Identification: 7:25-cv-00368, W.D. Tex., 08/27/2025

• Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Defendant resides in the district, maintains a regular and established place of business there, and has committed acts of infringement within the district.

• Core Dispute: Plaintiff alleges that Defendant’s cloud containerization products infringe a patent related to systems and methods for enabling a software application to execute on an incompatible computer platform.

• Technical Context: The technology at issue is software containerization, a method of packaging an application with its dependencies to ensure it runs reliably across different computing environments, which is a foundational technology for modern cloud computing and application deployment.

• Key Procedural History: The complaint notes that Plaintiff's predecessor, Appzero, was recognized by Gartner as a "Cool Vendor in Cloud Computing" in April 2009, which Plaintiff presents as evidence of the technology's non-conventional nature at the time.

Case Timeline

Date	Event
2003-10-20	’762 Patent Priority Date
2009-04-01	Gartner recognizes Plaintiff's predecessor AppZero as a "Cool Vendor"
2010-08-10	’762 Patent Issue Date
2025-08-27	Complaint Filing Date

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

U.S. Patent No. 7,774,762 - "System Including Run-Time Software to Enable a Software Application to Execute on an Incompatible Computer Platform," issued August 10, 2010

The Invention Explained

• Problem Addressed: The patent's background section describes the technical problem that software applications are typically designed to run on a specific computer platform and operating system, and will not function on an incompatible platform without being rewritten, a costly and time-consuming process (’762 Patent, col. 1:35-50).
• The Patented Solution: The invention provides a system for running an application on an incompatible host platform by packaging the application and its required files into an isolated environment, termed a "capsule" (’762 Patent, col. 2:20-30). This capsule contains the application-specific files and the files from its native operating system that it depends on (’762 Patent, col. 2:20-29). "Capsule runtime software," which includes a kernel module and application libraries, intercepts system service requests from the application. This software redirects file access requests to the files within the capsule and modifies other system information to provide "capsule specific values," effectively making the application behave as if it were running on its original, native platform (’762 Patent, col. 2:31-62).
• Technical Importance: This technology allows software applications, particularly legacy ones, to be migrated to and executed on modern or different computer platforms without modification, offering a path to modernization while preserving existing software investments (’762 Patent, col. 1:54-64).

Key Claims at a Glance

• The complaint states it asserts "only method claims" (Compl. ¶21, pg. 7). The likely independent claim at issue is Claim 17.
• Independent Method Claim 17 requires, in essence:
  • Providing a set of files that includes both the software application and the specific operating system files it requires.
  • Executing the application on an incompatible platform, using the provided OS-specific files instead of the host platform's local system files.
  • Executing runtime software that includes a kernel module and an "application filter library" to manage the application's state and file locations.
  • Using this runtime software to filter system service requests from the application, modifying values that would otherwise be returned by the host's operating system.
  • Executing the application by accessing the provided files instead of the host's operating system files, and providing predetermined values related to platform identity.

III. The Accused Instrumentality

Product Identification

• The accused products are Oracle Cloud Infrastructure (“OCI”), Oracle Kubernetes Engine (“OKE”), Oracle Cloud Native Environment (“OCNE”), and Oracle Cloud Infrastructure Container Registry (Compl. ¶15).

Functionality and Market Context

• The complaint alleges these products provide containerization services that allow customers to deploy and manage applications in isolated environments within Oracle's cloud infrastructure (Compl. ¶15). These products are part of the rapidly growing application container market, which enables scalable and portable application deployment (Compl. ¶5). The complaint does not provide specific technical details about the internal operation of the accused products beyond their general function as containerization platforms.

IV. Analysis of Infringement Allegations

The complaint references a claim chart in an exhibit that was not provided with the filing (Compl. ¶19). The narrative infringement theory alleges that the Accused Products "satisfy all claim limitations" by providing containerization systems that enable applications to run in isolated environments, which allegedly corresponds to the patented method of using a "capsule" and "runtime software" to execute an application on an incompatible platform (Compl. ¶19). The complaint includes a "Virtualization Landscape" chart from 2009, which depicts Plaintiff's predecessor "appzero" as operating uniquely at the "Application" and "Cloud/Server" level, distinct from machine or OS-level virtualization technologies (Compl. p. 4). This visual is used to support the argument that the patented technology was a novel approach to application portability (Compl. ¶12).

• Identified Points of Contention:
  • Scope Questions: The patent describes a specific architecture involving a "capsule" and runtime software with a "kernel module" and "application filter library." A central question will be whether Oracle's modern containerization technology, which is based on industry standards like Kubernetes and relies on native Linux kernel features (e.g., cgroups, namespaces), can be considered to practice the method described in the patent.
  • Technical Questions: The complaint does not specify how the Accused Products allegedly perform the claimed step of "filtering one or more system service requests" and "providing values... to modify values that otherwise would have been returned." Establishing a direct mapping between the functionality of Oracle's Kubernetes-based services and these specific claim limitations may be a key technical hurdle.

V. Key Claim Terms for Construction

• The Term: "incompatible computer platform"

  • Context and Importance: This term defines the problem the patent purports to solve. The outcome of the case may depend on whether the typical use case for the Accused Products—running a containerized application designed for Linux on a different Linux distribution within a cloud environment—falls within the patent's definition of "incompatible."
  • Intrinsic Evidence for a Broader Interpretation: The patent provides examples such as running a Solaris 2.6 application on a Solaris 9 platform, or a Red Hat Enterprise Linux application on a Suse Linux Enterprise Server platform, suggesting that different versions or distributions of the same OS family can be considered "incompatible" (’762 Patent, col. 2:49-62).
  • Intrinsic Evidence for a Narrower Interpretation: The patent's background frames the problem around applications that "will not run on one it is not designed for," which could be argued to imply a more fundamental incompatibility, such as between different OS families (e.g., Solaris vs. Linux), rather than between different, largely compatible Linux distributions. (’762 Patent, col. 1:43-45).

• The Term: "filtering one or more system service requests"

  • Context and Importance: This phrase describes the core technical mechanism of the claimed invention. Whether Oracle's products infringe will likely turn on the construction of this term.
  • Intrinsic Evidence for a Broader Interpretation: The specification suggests this can be accomplished through "a number of well known capabilities," including "library preload services" and "system call trace facilities," which could support a construction that covers any method of intercepting and redirecting system calls (’762 Patent, col. 9:32-38).
  • Intrinsic Evidence for a Narrower Interpretation: The patent consistently describes this filtering in the context of a specific "application filter library" working in concert with a "kernel module" (e.g., ’762 Patent, col. 2:31-40; Fig. 9). This may support a narrower construction that requires an architecture similar to the one explicitly disclosed, potentially distinguishing it from modern container runtimes that use kernel-native isolation primitives.

VI. Other Allegations

• Indirect Infringement: The complaint alleges that Oracle induces infringement by providing customers with user manuals and online instructions that guide them to use the Accused Products in an infringing way (Compl. ¶17). It also alleges contributory infringement, asserting the products are especially adapted for infringement and are not staple articles of commerce (Compl. ¶18).
• Willful Infringement: Willfulness is alleged based on Oracle’s purported knowledge of the ’762 patent "at least as early as when this Complaint was filed" (Compl. ¶17).

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

• A core issue will be one of technological translation: can the specific architecture described in the 2010-issued patent—a "capsule" managed by a "kernel module" and "application filter library"—be construed to cover modern, Kubernetes-based containerization systems that achieve isolation through different mechanisms, such as native kernel namespaces and control groups?
• A second key question will be one of definitional scope: does the term "incompatible computer platform," as used in the patent, encompass the common cloud computing scenario of running a container on different distributions of the same underlying operating system (e.g., Linux), or is it limited to platforms with more fundamental software and architectural differences?