Kmizra LLC v. Google LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: K.Mizra LLC (Delaware)
  • Defendant: Google LLC (Delaware)
  • Plaintiff’s Counsel: Sheridan Ross P.C.; Miller Fair Henry PLLC; Scheef & Stone, LLP
• Case Identification: 1:25-cv-00236, W.D. Tex., 02/03/2026
• Venue Allegations: Venue is based on Google's substantial presence in the Western District of Texas, including a large office in Austin, the employment of hundreds of individuals, its registration to do business in Texas, and its marketing and sales of the accused products within the district.
• Core Dispute: Plaintiff alleges that Defendant’s Google Chrome Enterprise Premium, a zero-trust security product, infringes two patents related to methods for verifying the security status of devices before granting them access to a protected network.
• Technical Context: The technology addresses the security risk of potentially infected devices connecting to corporate networks, a foundational concept in modern "zero-trust" network architecture which assumes no device is trusted by default.
• Key Procedural History: The complaint notes that the patents-in-suit previously survived an Inter Partes Review (IPR) proceeding where the Patent Trial and Appeal Board (PTAB) found the challenger had not shown the claims were unpatentable. Subsequent IPR petitions filed by Google were also denied. The patents were also previously asserted against Cisco Systems, Inc. in the same court and before the same judge, a case that resolved after the court issued claim construction rulings. The complaint also alleges that one of the named inventors, Dr. James Roskind, was a high-ranking Google employee from 2008 to 2016, a period that spans the prosecution and issuance of the '705 patent.

Case Timeline

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

U.S. Patent No. 8,234,705 - "Contagion Isolation and Inoculation"

• Patent Identification: U.S. Patent No. 8,234,705, “Contagion Isolation and Inoculation,” issued July 31, 2012 Compl. ¶18

The Invention Explained

• Problem Addressed: The patent describes the threat posed by mobile computers, like laptops, which connect to both untrusted public networks and protected enterprise networks Compl. ¶26 By roaming onto unknown networks, these devices can become infected with viruses or worms and then introduce that "contagion" to the secure network upon reconnection ’705 Patent, col. 1:14-31
• The Patented Solution: The invention proposes a method to verify a host computer's security status before granting full network access. If the host is deemed insecure (e.g., infected or missing patches), it is "quarantined" ’705 Patent, col. 3:9-14 In this quarantined state, the host is given limited access only to specific "remediation" servers to download patches or updates, while its attempts to communicate with other parts of the protected network are blocked or redirected to a "quarantine server" that notifies the user of the situation ’705 Patent, abstract ’705 Patent, Fig. 10A
• Technical Importance: This approach represents a shift from a purely perimeter-based security model to one that verifies the posture of individual endpoints, a concept foundational to modern zero-trust security frameworks Compl. ¶27

Key Claims at a Glance

• The complaint asserts independent Claim 19 Compl. ¶28
• The essential elements of Claim 19 include:
  • Detecting an insecure condition on a host attempting to connect to a protected network.
  • This detection includes contacting a "trusted computing base associated with a trusted platform module within the first host" and receiving a "valid digitally signed attestation of cleanliness."
  • The attestation must certify that the host is not infested and has a required software patch or patch level.
  • If the response lacks a valid attestation, the host is quarantined by preventing it from sending data to the protected network.
  • Quarantining includes serving a "quarantine notification page" for web requests and, for a DNS query, providing the IP address of a quarantine server.
  • The host is permitted to communicate with a "remediation host" to fix the insecure condition.
• The complaint reserves the right to assert additional claims Compl. ¶28

U.S. Patent No. 9,516,048 - "Contagion Isolation and Inoculation Via Quarantine"

• Patent Identification: U.S. Patent No. 9,516,048, “Contagion Isolation and Inoculation Via Quarantine,” issued December 6, 2016 Compl. ¶19

The Invention Explained

• Problem Addressed: The patent addresses the problem of unwanted and malicious network communications (e.g., spam, phishing) that burden networks and expose users to risk, noting that filtering only at the destination host is insufficient ’048 Patent, col. 1:22-27 There is a need for a way to intercept such communications to better protect the network and hosts ’048 Patent, col. 1:46-52
• The Patented Solution: Sharing a nearly identical specification with the ’705 Patent, the ’048 Patent also describes a system for quarantining insecure hosts Compl. ¶20 A key feature detailed in the asserted claim of the ’048 Patent is the specific mechanism for notifying the user, which involves "re-routing by responding to the service request sent by the first host with a redirect that causes a browser on the first host to be directed to a quarantine server" ’048 Patent, col. 23:1-5
• Technical Importance: This patent provides a specific implementation for the quarantine notification process, focusing on the use of a server-side redirect to guide the user of an insecure device to a remediation page Compl. ¶83

Key Claims at a Glance

• The complaint asserts independent Claim 17 Compl. ¶28
• The complaint notes that limitations [A] through [D] and [F] of Claim 17 are identical or highly similar to those in Claim 19 of the ’705 Patent Compl. ¶80 The key differing elements are:
  • [E1] Determining if a service request is associated with a remediation request, and if not, serving a quarantine notification page.
  • [E2] Specifying that serving the quarantine page includes re-routing the host's browser via a "redirect" to a quarantine server.
• The complaint reserves the right to assert additional claims Compl. ¶28

III. The Accused Instrumentality

Product Identification

• Product Identification: Google Chrome Enterprise Premium, which the complaint states was formerly known as Google's "BeyondCorp Enterprise" product Compl. ¶¶41-42

Functionality and Market Context

• Functionality and Market Context: The complaint describes the accused product as Google Cloud's "zero-trust solution" for securing access to web applications Compl. ¶61 Its core function is to perform "endpoint posture assessments" to ensure that devices, whether company-owned or personal, meet security and compliance policies before they are allowed to connect to a protected network Compl. ¶62 The system allegedly uses certificate-based authentication, mutual TLS (mTLS), and hardware-based security features like Trusted Platform Modules (TPMs) to verify device posture Compl. ¶¶63-64 If a device is found to be non-compliant (e.g., having an outdated OS), the system can block access and provide "remediation messages" to guide the user in fixing the issue (Compl. ¶¶27, 66-67). The complaint includes a diagram from Google's documentation showing a "Trusted Device" architecture that utilizes a "TPM/OS keystores" element to secure connections to Google Cloud services Compl. ¶63, p. 22

IV. Analysis of Infringement Allegations

'705 Patent Infringement Allegations

• Identified Points of Contention:
  • Scope Question: A central question may be whether the accused product's use of X.509 device certificates within an mTLS handshake constitutes the "valid digitally signed attestation of cleanliness" from a "trusted computing base" as required by the claim. The defense may argue that a standard certificate is for authentication, not the specific "attestation of cleanliness" (i.e., certifying a non-infested state and patch level) described in the patent.
  • Technical Question: The complaint alleges that the accused product meets limitation [E2] by providing "IP address(es), with resources (i.e. quarantine servers)" Compl. ¶68 A key factual question for the court will be whether the product actually uses this specific DNS-based redirection mechanism, as opposed to other methods like an HTTP redirect, which is notably the mechanism claimed in the related '048 Patent.

'048 Patent Infringement Allegations

The complaint alleges that limitations [A]-[D] and [F] of Claim 17 are met for the same reasons as the corresponding limitations of Claim 19 of the '705 Patent Compl. ¶82 The analysis below focuses on the differing limitations.

• Identified Points of Contention:
  • Technical Question: Limitation [E2] explicitly requires re-routing via a "redirect." The complaint provides screenshots of a final "access-denied" page as proof Compl. ¶¶88, 89 Compl. Ex. 16, p. 37 However, the provided network log screenshot for this page shows an HTTP status code of "200 OK," not a redirect code (e.g., 301 or 302). This raises the evidentiary question of whether the system performs the claimed "redirect" or if the user is directed to the denial page through other means, creating a potential mismatch with the claim language.

V. Key Claim Terms for Construction

• The Term: "trusted computing base"

  • Context and Importance: This term is foundational to the claimed security mechanism. The infringement allegation hinges on mapping Google's use of "secure cryptographic storage such as TPMs and OS keystores" Compl. ¶63 onto this term. Practitioners may focus on this term because its construction will determine if a modern, distributed, cloud-based security architecture falls within the scope of a term rooted in the host-centric "Trusted Computing Group" (TCG) paradigm of the mid-2000s.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification provides examples rather than a restrictive definition, mentioning "the Paladium security initiative" and "TCG specifications" as illustrations of a trusted computing base, but does not explicitly limit the term to them ('705 Patent, col. 13:5-10). This may support an argument that the term covers any hardware/software combination that provides a root of trust for security attestations.
    • Evidence for a Narrower Interpretation: The claim language specifies "a trusted computing base associated with a trusted platform module within the first host" ('705 Patent, col. 22:20-22). This language may support an argument that the base must be located entirely on the client device, potentially excluding essential server-side components of Google's accused system.

• The Term: "valid digitally signed attestation of cleanliness"

  • Context and Importance: The "attestation" is the specific data that proves a device's secure state. The complaint alleges that Google's use of device certificates and mTLS satisfies this limitation Compl. ¶64 The definition of this term is critical because it will determine whether an authentication certificate can also serve as the specific assertion of security posture required by the claims.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The claims do not specify the format of the attestation, only its content: that the TCB "has ascertained that the first host is not infested" and has a certain "patch... level" ('705 Patent, col. 22:27-32). A plaintiff might argue that the combination of a valid device certificate and other contextual signals evaluated by the system collectively functions as the claimed attestation.
    • Evidence for a Narrower Interpretation: The specification discusses "assertions about the cleanliness (e.g. infestation status) and/or state of their computers" made by "trusted code bases" ('705 Patent, col. 13:11-14). A defendant may argue this requires a specific, dynamic statement about security state, rather than a relatively static device certificate primarily used for identity.

VI. Other Allegations

• Indirect Infringement: The complaint alleges that Google induces infringement by "promoting, advertising, and instructing" customers on how to use the infringing features of the Accused Instrumentalities Compl. ¶70; Compl. ¶92
• Willful Infringement: The complaint alleges both pre-suit and post-suit willfulness. Pre-suit knowledge is primarily based on the employment of co-inventor Dr. James Roskind at Google from 2008 to 2016, a period during which the '705 patent was prosecuted and issued. The complaint alleges that, per company policy, Dr. Roskind would have disclosed his inventions to Google Compl. ¶¶44-46; Compl. ¶71 Post-suit knowledge is based on the filing of the original complaint on February 18, 2025 Compl. ¶43; Compl. ¶93

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

• Definitional Scope: A core issue will be one of definitional scope and technological evolution: can the claims, rooted in the host-centric "trusted computing" concepts of the mid-2000s, be construed to cover Google's modern, cloud-native "zero trust" architecture? This will turn on the construction of key terms like "trusted computing base" and "attestation of cleanliness" and whether a device certificate used for authentication can meet the claims' specific requirements.
• Evidentiary Sufficiency: A key evidentiary question will be one of operational proof: does the complaint's evidence, which consists largely of high-level marketing and technical documents, sufficiently demonstrate the specific technical mechanisms recited in the claims? For instance, the '048 Patent requires a "redirect," but the complaint's own evidence shows a final destination page with a "200 OK" status, raising a factual question about whether the claimed re-routing method is actually used.
• Imputed Knowledge: A central question for willfulness will be whether an inventor's knowledge of his own pending patent application, while employed at a large corporation, can be legally imputed to the company to establish pre-suit knowledge and willful infringement of a product developed years later, potentially by entirely different teams.