DCT
3:25-cv-07179
Valtrus Innovations Ltd v. Google LLC
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 / California)
- 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 maintaining its corporate headquarters and multiple regular and established places of business within the Northern District of California.
- Core Dispute: Plaintiff alleges that Google’s Cloud computing products, which utilize certain AMD processors with hardware virtualization features, infringe a patent related to computer system resource access control.
- Technical Context: The technology concerns hardware-level security mechanisms designed to protect sensitive computer system resources from unauthorized access, even by software operating with the highest system privileges.
- Key Procedural History: The complaint alleges that Plaintiff sent Google three notice letters in 2021 regarding infringement of other patents in its portfolio by the same accused technology (AMD EPYC processors), which may be used to support allegations of pre-suit knowledge for willfulness.
Case Timeline
| Date | Event |
|---|---|
| 2004-08-03 | U.S. Patent No. 7,930,539 Priority Date |
| 2011-04-19 | U.S. Patent No. 7,930,539 Issues |
| 2021-04-14 | Plaintiff sends first notice letter to Google on other patents |
| 2021-05-13 | Plaintiff sends second notice letter to Google on other patents |
| 2021-09-09 | Plaintiff sends third notice letter to Google on other patents |
| 2025-11-28 | Complaint Filed |
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 flaw in computer architectures that rely solely on "privilege levels" for security. In such systems, the operating system is typically granted the highest privilege level, giving it unrestricted access to all system resources. This creates a risk, particularly in partitioned systems, where it may be desirable to protect certain configuration data even from the operating system itself to prevent one partition from interfering with another (’539 Patent, col. 2:38-48; Compl. ¶¶14-17).
- The Patented Solution: The invention proposes a hardware-enforced "protected mode of operation." When this mode is active, all software programs, including those with the most-privileged level, are denied access to designated "protected resources." Access control is managed by a "protected mode indicator," a hardware value that, in one embodiment, can only be modified by a hardware fault initiated by a secure hardware interface layer, preventing software from disabling the protection (’539 Patent, col. 3:30-39, col. 8:58-67, Fig. 2B).
- Technical Importance: This approach creates an additional layer of resource protection that is independent of the operating system, which is advantageous for securing multi-partition and virtualized computer systems (’539 Patent, col. 15:23-28).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 of the ’539 Patent (Compl. ¶27).
- Claim 1 requires, in essence:
- 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 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 system is not in a protected mode, processing the request based on the program's standard access rights.
- The complaint states that Google infringes "one or more claims" of the patent, reserving the right to assert others (Compl. ¶25).
III. The Accused Instrumentality
Product Identification
- Google Cloud suite products and services that use virtual machines ("VMs") relying on AMD EPYC processors, including the C3D, N2D, T2D, and C2D VM families (Compl. ¶26). A table in the complaint identifies specific Google Cloud machine families and the AMD EPYC processors they use (Compl. p. 10).
Functionality and Market Context
- The accused products use AMD's hardware virtualization technology, known as AMD-V or Secure Virtual Machine ("SVM"), to create and manage VMs (Compl. ¶31). The complaint alleges that this technology provides "hardware resources that allow a single machine to run multiple operating systems efficiently, while maintaining secure, resource-guaranteed isolation" (Compl. ¶33). Within this architecture, a guest operating system runs inside a VM, managed by a hypervisor. The complaint alleges that the AMD-V architecture allows the hypervisor to intercept attempts by the guest OS to access certain protected hardware resources, such as specific processor control registers (Compl. ¶36).
IV. Analysis of Infringement Allegations
U.S. Patent No. 7,930,539 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving a request from a software program to access a specified one of the plurality of resources | A guest operating system ("OS") running in a VM on an AMD EPYC processor requests access to a physical resource, such as a processor control register (e.g., CR0, CR3). The complaint provides a diagram illustrating this process (Compl. p. 11). | ¶¶30-31 | col. 1:50-54 |
| 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 or events to "intercept." This list effectively defines which resources are protected from direct access by the guest OS. | ¶33 | col. 1:54-55 |
| if the computer system is operating in a protected mode of operation | This is alleged to occur when the computer system executes a VM by calling the "VMRUN" instruction, placing the system in a hardware-virtualized state. | ¶36 | col. 3:35-37 |
| then denying the request regardless of access rights associated with the software program including software programs having a most-privileged level | When VMRUN is active, an attempt by the guest OS to access an intercepted resource (e.g., a read/write of CR0 or CR3) is automatically intercepted by the hardware and "denied," regardless of the privilege level (e.g., CPL=0) at which the guest OS is executing. A provided table illustrates these "Instruction Intercepts" (Compl. p. 13). | ¶36 | col. 8:58-62 |
| 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 | If the processor is not operating in the hardware-virtualized mode (i.e., not executing a VM via VMRUN), access to resources is processed based on the standard Current Privilege Level (CPL), where CPL=0 is the most privileged level and allows access to control registers. | ¶¶37-38 | col. 3:38-39 |
Identified Points of Contention
- Scope Questions: A central dispute may arise over whether AMD's virtualization architecture constitutes the "protected mode of operation" described in the patent. This raises the question: Does the patent’s concept of a system-wide "protected mode," controlled by a single indicator that denies access to "all software programs," read on a virtualization scheme where a hypervisor specifically isolates and manages a guest OS?
- Technical Questions: The analysis may focus on the meaning of "denying the request regardless of access rights." This raises the question: Does the AMD-V hardware "intercept" function as an absolute denial as claimed in the patent, or is it a mechanism that transfers control to a hypervisor, which then makes a decision based on its own set of rules and permissions?
V. Key Claim Terms for Construction
The Term: "protected mode of operation"
Context and Importance
- This term is the core of the invention. Its construction will determine whether the accused AMD-V virtualization environment falls within the scope of the claims. Practitioners may focus on this term because the infringement theory equates running a virtual machine with entering the claimed "protected mode."
Intrinsic Evidence for Interpretation
- Evidence for a Broader Interpretation: The specification describes the mode’s function as one in which "all software programs (including software programs having the most-privileged privilege level) are denied access to the protected resources" (’539 Patent, col. 3:35-39). This functional definition could support an interpretation that covers any hardware state achieving this result.
- Evidence for a Narrower Interpretation: The specification discloses a specific embodiment where the mode is indicated by "a one-bit value PM" in a processor status register (’539 Patent, col. 8:49-54). This, along with Figure 2B depicting a single "Protected Mode Indicator," could support an argument that the term requires a specific, system-wide hardware flag rather than the more complex state management of a hypervisor-guest relationship.
The Term: "denying the request regardless of access rights"
Context and Importance
- This phrase defines the nature of the access denial. The dispute may turn on whether the accused "intercept" is a true, unconditional denial or a mediated transfer of control.
Intrinsic Evidence for Interpretation
- Evidence for a Broader Interpretation: The claim language focuses on the perspective of the "software program" making the request. From the guest OS's perspective, its own "most-privileged" status is ignored and its request is blocked (intercepted), which could be characterized as a denial "regardless of" its rights.
- Evidence for a Narrower Interpretation: The word "denying" could be construed to mean an absolute rejection by the hardware. An architecture where a request is merely rerouted to a hypervisor for processing might not be seen as a "denial," but rather as a redirection based on a different program's (the hypervisor's) superior access rights.
VI. Other Allegations
Indirect Infringement
- The complaint alleges Google induces infringement by "using, selling, and offering for sale the Accused Products," which allegedly encourages and facilitates the use of the patented methods (Compl. ¶42).
Willful Infringement
- Willfulness is alleged based on Google’s purported knowledge of the ’539 Patent. This knowledge is allegedly established by three pre-suit notice letters sent in 2021. The complaint notes these letters concerned other patents in the Plaintiff's portfolio but alleges they informed Google of its infringement related to the "use of AMD EPYC processors" (Compl. ¶¶41, 45).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural equivalence: can the hypervisor-guest relationship in AMD's virtualization technology, designed for OS isolation, be construed as the system-wide "protected mode of operation" described in the ’539 Patent, which is framed as a universal security state?
- A second key issue will be one of functional mapping: does the accused AMD-V hardware "intercept" mechanism, which transfers control to a hypervisor, perform the specific function of "denying the request regardless of access rights" as required by the claim, or does the hypervisor's role as a decision-maker introduce a form of mediation not contemplated by the patent's language?