DCT

5:25-cv-07179

Valtrus Innovations Ltd v. Google LLC

Log In
Key Events
Amended Complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
    • Plaintiff: Valtrus Innovations Ltd. and Key Patent Innovations Limited (Republic of Ireland)
    • Defendant: Google LLC (Delaware)
    • Plaintiff’s Counsel: Irell & Manella LLP
  • Case Identification: 5:25-cv-07179, N.D. Cal., 11/28/2025
  • Venue Allegations: Venue is alleged to be proper based on Google's corporate headquarters, multiple regular and established places of business, and commission of infringing acts within the Northern District of California.
  • Core Dispute: Plaintiff alleges that Google’s Cloud services, which utilize virtual machines running on AMD EPYC processors, infringe a patent related to hardware-level control of access to protected computer system resources.
  • Technical Context: The technology concerns fundamental computer architecture for creating secure computing environments by using a hardware-enforced "protected mode" to wall off sensitive resources even from the most privileged software, a concept relevant to virtualization and cloud computing.
  • Key Procedural History: The complaint alleges pre-suit knowledge based on three notice letters sent to Google in 2021 regarding other patents in the plaintiff's portfolio, which identified the accused products' use of AMD EPYC processors. During the patent’s prosecution, the Examiner's Statement of Reasons for Allowance noted that prior art failed to teach denying a resource request based on a "protected mode of operation" regardless of the software's access rights.

Case Timeline

Date Event
2004-08-03 ’539 Patent Priority Date
2011-04-19 ’539 Patent Issue Date
2021-04-14 Valtrus sends first of three notice letters to Google regarding other patents
2021-05-13 Valtrus sends second notice letter to Google
2021-09-09 Valtrus sends third notice letter to Google
2025-11-28 Complaint Filing Date

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

U.S. Patent No. 7,930,539 - “Computer system resource access control”

The Invention Explained

  • Problem Addressed: The patent describes a vulnerability in conventional computer architectures where even systems using "privilege levels" grant the operating system (OS) ultimate access to all system resources (’539 Patent, col. 1:46-48). This creates a security risk, as a "poorly-designed or malicious program" could compromise the OS and gain control of the entire system (Compl. ¶14; ’539 Patent, col. 1:30-34). The patent notes this is particularly problematic in "partitionable computer systems" where the OS of one partition should be prevented from interfering with another (’539 Patent, col. 15:8-23).
  • The Patented Solution: The invention proposes a hardware-enforced "protected mode" of operation that functions independently of software privilege levels (’539 Patent, Abstract). When this mode is active, all software, including the most-privileged OS, is denied access to designated "protected resources" (Compl. ¶18; ’539 Patent, col. 3:35-39). This is controlled by a "protected mode indicator" implemented in the hardware layer, which cannot be modified by the OS, thus creating a secure boundary that software cannot bypass (Compl. ¶¶19-20; ’539 Patent, Fig. 2B, col. 8:64-9:2).
  • Technical Importance: This technique provides a more robust method for securing critical system data (like partition configuration information) from unauthorized access or modification, even by a compromised operating system (Compl. ¶22; ’539 Patent, col. 15:4-8).

Key Claims at a Glance

  • The complaint asserts infringement of at least independent claim 1 (Compl. ¶27).
  • The essential elements of independent claim 1 are:
    • Receiving a request from a software program to access a resource.
    • Determining if the resource is a "protected resource."
    • If it is a protected resource, then:
      • If the computer system is in a "protected mode of operation," denying the request "regardless of access rights associated with the software program including software programs having a most-privileged level."
      • If the computer system is not in a protected mode, processing the request based on the software program's associated access rights.
  • The complaint alleges infringement of "one or more claims" but provides infringement analysis only for claim 1 (Compl. ¶25).

III. The Accused Instrumentality

Product Identification

  • The "Accused Products" are identified as Google Cloud offerings that use virtual machines ("VMs") running on AMD EPYC processors, specifically including C3D, N2D, T2D, and C2D VMs (Compl. ¶26). The complaint provides a marketing graphic from Google Cloud that lists these VM families and their associated AMD EPYC processors (Compl. p. 10).

Functionality and Market Context

  • The complaint alleges that the accused AMD EPYC processors implement AMD's virtualization technology (AMD-V), also known as Secure Virtual Machine (SVM), which provides hardware-level support for running multiple guest operating systems on a single machine (Compl. ¶31). This technology uses a "virtual machine control block (VMCB)" to define the execution environment for a guest VM and to intercept certain instructions or events, which allows a hypervisor to manage and isolate guest systems (Compl. ¶33). The complaint asserts that this hardware-assisted virtualization technology provides significant performance improvements over software-only virtualization (Compl. ¶39).

IV. Analysis of Infringement Allegations

’539 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
(A) receiving a request from a software program to access a specified one of the plurality of resources; A guest operating system running within a Google Cloud VM on an AMD EPYC processor requests access to a system resource, such as a processor register. ¶31 col. 17:19-21
(B) determining whether the specified one of the plurality of resources is a protected resource; The AMD-V architecture uses a Virtual Machine Control Block (VMCB) that contains a list of instructions and events (e.g., access to control register CR3) to "intercept," thereby designating certain resources as protected from direct access by the guest OS. ¶33 col. 17:22-24
(C)(1) if the computer system is operating in a protected mode of operation, then denying the request regardless of access rights associated with the software program including software programs having a most-privileged level; When a guest OS is executing (following a "VMRUN" instruction), the complaint alleges the system is in a "protected mode." An attempt by the guest OS (which may be running at its own highest privilege level) to access an intercepted resource (e.g., CR0/CR3 registers) is trapped by the hardware and denied by the hypervisor, regardless of the guest's privilege level. A diagram of the "Pacifica" virtualization architecture illustrates this interception process (Compl. p. 11). ¶36 col. 17:25-30
(C)(2) processing the request based on the access rights associated with the software program if the computer system is not operating in the protected mode of operation. When the system is not in the "protected mode" (e.g., the hypervisor is executing, not the guest VM), requests to access resources are processed based on the processor's standard Current Privilege Level (CPL). Access to privileged resources like control registers is granted only if the software is running at the most privileged level (CPL=0). The complaint includes a table from an AMD manual showing that access to "Control Registers" is a privileged instruction limited to CPL=0 (Compl. p. 17). ¶38 col. 17:31-32
  • Identified Points of Contention:
    • Scope Questions: The central dispute may turn on whether AMD's virtualization architecture, designed to isolate a guest OS from a host hypervisor, falls within the scope of the patent's "protected mode." A question for the court is whether the execution of a guest VM constitutes the entire "computer system... operating in a protected mode," or if this claim language requires a system-wide state that restricts even the highest-level controlling software (the hypervisor), which the accused technology does not appear to do.
    • Technical Questions: The complaint equates the privilege level of a guest OS with the "most-privileged level" recited in the claim. A potential point of contention is whether this term refers to the highest privilege level within the context of the guest VM, as Plaintiff alleges, or the highest privilege level on the physical system as a whole, which is occupied by the hypervisor.

V. Key Claim Terms for Construction

  • The Term: "computer system is operating in a protected mode of operation"

    • Context and Importance: This term is the foundation of the infringement theory. Its construction will determine whether the state of a guest VM executing under AMD-V technology can be considered the "protected mode" envisioned by the patent. Practitioners may focus on this term because the plaintiff's case depends on mapping the specific, limited context of a guest VM's operation onto this broad, functional claim language.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent defines the mode functionally: a mode in which "all software programs ... are denied access to the protected resources" (’539 Patent, col. 3:35-37). Plaintiff may argue that from the perspective of the guest VM, this condition is met, as the hypervisor denies its access.
      • Evidence for a Narrower Interpretation: The specification describes the protected mode as being controlled by a specific "protected mode indicator" (206) in the hardware, which governs the entire system state (’539 Patent, Fig. 2B, col. 8:45-49). This indicator is modifiable only by a "hardware fault initiated by the hardware interface layer," not by any OS (’539 Patent, col. 8:64-9:2). This suggests a global security state fundamentally different from a hypervisor managing a guest process.

  • The Term: "most-privileged level"

    • Context and Importance: The definition of this term is critical for determining whether the accused technology performs the claimed denial of access. The dispute will be whether this refers to privilege within the guest's virtualized environment or privilege on the overall physical system.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: Plaintiff’s theory relies on this term referring to the highest privilege level attainable by software running within the guest VM (e.g., the guest OS kernel). The complaint alleges the intercept denies access to the guest OS even when it is executing with what it perceives to be maximum privileges (Compl. ¶36).
      • Evidence for a Narrower Interpretation: The patent’s background discusses the problem of the main system OS having the "most-privileged level" and accessing all resources (’539 Patent, col. 2:26-31). A defendant may argue that the term must refer to the true highest privilege level of the entire computer system (i.e., the hypervisor), which is never denied access in the accused products; on the contrary, it is the entity that enforces the denial upon the less-privileged guest.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges Google induces infringement by selling and offering for sale the Accused Products with the intent to "encourage and facilitate infringing uses" (Compl. ¶42).
  • Willful Infringement: Willfulness is alleged based on pre-suit knowledge of the ’539 Patent (Compl. ¶45). The complaint's basis for this knowledge is a series of three notice letters Valtrus sent to Google regarding infringement of other patents in its portfolio. The complaint alleges these letters put Google on notice because they identified the infringing use of AMD EPYC processors in Google's products (Compl. ¶41).

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

The resolution of this case appears to depend on how the court construes the scope of the patent claims relative to the operation of modern virtualization technology.

  • A core issue will be one of definitional scope: can the patent's concept of a monolithic, system-wide "protected mode," which restricts even the primary system OS, be construed to read on the nuanced relationship between a hypervisor and a guest OS in a virtualized environment?
  • A key technical question will be one of hierarchical privilege: does the claimed denial of access to a program at the "most-privileged level" refer to the highest privilege within a subordinate guest system, or must it apply to the highest-privilege software on the physical machine (the hypervisor), which the accused systems do not restrict?