VirtaMove Corp v. Google LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: VirtaMove, Corp. (Canada)
  • Defendant: Google LLC (Delaware / California)
  • Plaintiff’s Counsel: Russ August & Kabat
• Case Identification: 5:26-cv-00704, W.D. Tex., 08/08/2025
• Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Defendant Google LLC has a regular and established place of business in the district, citing a corporate office in Austin, Texas.
• Core Dispute: Plaintiff alleges that Defendant’s cloud containerization products and services infringe a patent related to systems for executing software applications on incompatible computer platforms.
• Technical Context: The dispute centers on containerization technology, a method of packaging an application with its dependencies to ensure it runs reliably when moved from one computing environment to another, which is foundational to modern cloud computing.
• Key Procedural History: The complaint alleges that representatives of VirtaMove (then known as Appzero) and Google met in 2015, 2020, and 2021, during which VirtaMove demonstrated its technology. These alleged pre-suit interactions form the basis of the complaint's willfulness allegations.

Case Timeline

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

The Invention Explained

• Problem Addressed: The patent addresses the technical problem that software applications are typically designed for a specific computer platform and operating system and will not run on a different, incompatible platform without being rewritten, a process that can take significant time and resources (Compl. ¶15; ’762 Patent, col. 1:42-64).
• The Patented Solution: The invention provides a system that creates an isolated "capsule" environment for an application. This capsule contains the files the application needs from its original operating system. Special "capsule runtime software," including a kernel module and application libraries, intercepts system service requests from the application and modifies them, providing values that trick the application into functioning correctly on the new, incompatible host platform (’762 Patent, Abstract; col. 2:27-53). Figure 1a of the patent illustrates this "Application Container" (100) operating with its own filters (112, 118), distinct from applications running outside the capsule.
• Technical Importance: This approach provided a method for migrating legacy applications to newer hardware and operating systems without requiring recoding, addressing a significant challenge in enterprise IT management (Compl. ¶15; ’762 Patent, col. 1:54-64).

Key Claims at a Glance

• The complaint states it provides a claim chart for an independent claim in an exhibit, but the exhibit is not attached to the publicly filed document Compl. ¶20 Claim 1 is the first independent claim of the ’762 Patent.
• Essential elements of Claim 1 include:
  • A set of "associated capsule-related files" comprising files for the application itself and files specific to the original operating system it was designed for.
  • "Capsule runtime software" for managing the application's state and file location.
  • This runtime software must include both a "kernel module resident in kernel mode" and "at least one application filter library resident in user mode."
  • The purpose of this software is to filter system service requests made by the application and provide modified values from the filter library.
  • The outcome is that the application accesses the "capsule-related files" instead of the host system's native files.
• The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

Google Kubernetes Engine (GKE), Cloud Run, Migrate to Containers, Google Container Registry, Google Artifact Registry, and the Google Cloud Platform (collectively, the "Accused Products") Compl. ¶16

Functionality and Market Context

The complaint describes the Accused Products as a suite of cloud services that allow customers to "deploy, manage, and scale containerized applications" Compl. ¶16 A key feature highlighted is "Migrate to Containers," which is alleged to "modernize traditional applications away from virtual machine (VM) instances and into native containers," allowing users to "containerize your existing workloads with ease" Compl. ¶16 The complaint asserts that containerization is a rapidly growing market, projected to reach over $19 billion by 2029 Compl. ¶5

IV. Analysis of Infringement Allegations

The complaint alleges that the Accused Products infringe the ’762 patent but does not provide a detailed, element-by-element infringement analysis in the body of the document Compl. ¶16, ¶20 It states that a claim chart is attached as Exhibit 2, but this exhibit was not included with the filing Compl. ¶20 The narrative infringement theory is that Google's containerization services, which create portable computing environments for applications, practice the patented invention of using an isolated "capsule" to run software on what would otherwise be an incompatible platform Compl. ¶3, ¶16

The complaint includes a "Virtualization Landscape" chart, which it attributes to a 2009 Gartner report, to support its contention that the patented technology was non-conventional Compl. p. 5 This visual places "appzero" (Plaintiff's former name) in a unique quadrant for "Application" level virtualization, separate from competitors like VMWare and Microsoft, which are categorized under "Cloud," "Server," "Machine," or "OS" virtualization Compl. ¶13, p. 5

• Identified Points of Contention:
  • Scope Questions: A potential issue is whether the term "incompatible computer platform" as used in the patent, which provides examples of migrating between different versions of Solaris or Linux, can be construed to read on the environment managed by modern container platforms like Kubernetes, where the host and container often share the same kernel and "incompatibility" relates more to software dependencies and libraries.
  • Technical Questions: The complaint does not specify which components of Google's architecture constitute the claimed "kernel module" and "application filter library." A central technical question will be whether Google's container architecture, which relies on Linux kernel features such as namespaces and control groups, can be mapped to the specific two-part (kernel-mode and user-mode) filtering structure required by the asserted patent's claims.

V. Key Claim Terms for Construction

• The Term: "capsule runtime software including a kernel module resident in kernel mode and at least one application filter library resident in user mode" (from Claim 1).

• Context and Importance: This term defines the core technical structure of the invention. The infringement analysis will depend heavily on whether the architecture of the Accused Products can be shown to meet this specific two-part structural limitation. Practitioners may focus on this term because modern container runtimes may achieve similar isolation results using different architectural means native to the operating system kernel.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent specification describes the system's function as "modifying the behaviour of a local operating system" so that an application can run (’762 Patent, col. 3:12-14). A party could argue this functional description supports a broader reading that covers any software architecture achieving this result via modifications at both the kernel and user levels.
  • Evidence for a Narrower Interpretation: The patent repeatedly and specifically describes a "loadable kernel module" and a separate "shared library" in user mode as the implementation of the filters (’762 Patent, col. 9:18-24, 9:28-30). Figures 9 and 11 also distinctly depict a "kernel module" (94, 1108) and "user mode filters" or "filter lib(s)" (91, 1105). This may support a narrower construction requiring two distinct and separate software components matching these descriptions.

• The Term: "incompatible computer platform" (from Claim 1).

• Context and Importance: The definition of this term establishes the scope of the problem the patent claims to solve. Whether the Accused Products operate on platforms that are "incompatible" in the sense meant by the patent will be a critical issue.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent states an object of the invention is to provide a system for applications to run on a platform "which heretofore, the applications could not be run on" (’762 Patent, col. 1:56-58). This suggests "incompatible" could mean any platform where the application would fail to run correctly without the invention's intervention.
  • Evidence for a Narrower Interpretation: The specification provides specific examples of incompatibility, such as an application designed for "Solaris version 2.6" running on a "Solaris 9 platform" or applications for different Linux distributions (e.g., Red Hat EL3 on Suse SLES 9) (’762 Patent, col. 2:50-59). This could be used to argue that the term is limited to incompatibilities between different core operating system versions or distributions, rather than more routine software dependency conflicts.

VI. Other Allegations

• Indirect Infringement: The complaint alleges that Google induces infringement by providing "user manuals and online instruction materials" that encourage and instruct customers to use the Accused Products in an infringing manner Compl. ¶18 It also alleges contributory infringement, asserting the products are especially made for infringing use and are not staple articles of commerce Compl. ¶19
• Willful Infringement: Willfulness is alleged based on pre-suit knowledge. The complaint asserts that Google was aware of VirtaMove’s patented technology due to meetings and technology demonstrations in 2015, 2020, and 2021, and that Google was either aware of the patent through "basic due diligence" or was "willfully blind" to its existence Compl. ¶10 The complaint also alleges ongoing knowledge from the date the complaint was filed Compl. ¶18

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

• A core issue will be one of architectural mapping: Can the specific two-part structure of the claimed "capsule runtime software," requiring both a "kernel module" and a "user mode... filter library," be found in Google's container services, which are built upon integrated Linux kernel features like namespaces and cgroups?
• A second central question will be one of definitional scope: Will the term "incompatible computer platform," which is rooted in the context of migrating between different OS versions in the patent’s examples, be construed broadly enough to cover the types of library and dependency conflicts that modern containerization platforms are designed to solve?
• A key evidentiary question will concern pre-suit knowledge: What evidence will emerge regarding the substance of the alleged 2015-2021 meetings, and can VirtaMove establish that these interactions were sufficient to put Google on notice of the specific patent-in-suit to support the claim of willful infringement?