DCT
1:25-cv-00236
KMizra LLC v. Google LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: K.Mizra LLC (Delaware/Florida)
- Defendant: Google LLC (Delaware/California)
- Plaintiff’s Counsel: Scheef & Stone, LLP; Sheridan Ross P.C.; Miller Fair Henry PLLC
- Case Identification: 1:25-cv-00236, W.D. Tex., 02/18/2025
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Google maintains a substantial office in Austin, employs hundreds of people in the district, is registered to do business in Texas, and has committed acts of infringement in the district.
- Core Dispute: Plaintiff alleges that Defendant’s Google Chrome Enterprise Premium product infringes two patents related to "zero-trust" network security methods for isolating potentially infected computers.
- Technical Context: The technology addresses the enterprise security risk of devices connecting to protected networks after being exposed to untrusted environments, a foundational concept in modern zero-trust security architecture.
- Key Procedural History: The complaint notes that the asserted patents have a significant history. Both patents survived Inter Partes Review (IPR) challenges at the Patent Trial and Appeal Board (PTAB), with the '705 Patent IPR being dismissed with prejudice after a Federal Circuit appeal and remand. The patents were also previously asserted in the same court against Cisco Systems, in a case before the same judge that involved claim construction rulings and resolved shortly before trial.
Case Timeline
| Date | Event |
|---|---|
| 2004-09-27 | Priority Date for '705 and '048 Patents |
| 2012-07-31 | U.S. Patent No. 8,234,705 Issues |
| 2016-12-06 | U.S. Patent No. 9,516,048 Issues |
| 2024-09-01 | Prior litigation (K.Mizra v. Cisco) resolves (approx. date) |
| 2025-02-18 | Complaint Filed |
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 addresses the security threat posed by mobile computers, such as laptops, that connect to untrusted public networks (e.g., the Internet), become infected with viruses or other malware, and subsequently reconnect to a protected enterprise network, potentially spreading the contagion. (’705 Patent, col. 1:14-31; Compl. ¶26).
- The Patented Solution: The invention proposes an automated system that detects if a "host" computer is in an insecure state when it attempts to connect to a protected network. If an insecure condition is found, the system quarantines the host, providing it only with limited network access sufficient to remedy the problem (e.g., to download a software patch from a "remediation host"). This verification process involves communicating with a "trusted computing base" on the host to get an attestation of its "cleanliness." (’705 Patent, Abstract; col. 12:1-13). The overall process is depicted in the patent's Figure 10A, which shows steps for detecting a vulnerability, quarantining it, and providing remediation access. (Compl. ¶31).
- Technical Importance: The technology provides a method for automating the detection, isolation, and remediation of potentially compromised devices before they gain full access to a network, a critical function for maintaining enterprise security. (Compl. ¶34).
Key Claims at a Glance
- The complaint asserts independent claim 19. (Compl. ¶47).
- The essential elements of claim 19 are:
- A computer program product for protecting a network.
- Detecting an insecure condition on a "first host" attempting to connect.
- This detection includes contacting a "trusted computing base" on the host and receiving a "valid digitally signed attestation of cleanliness."
- The attestation confirms the host is not infested and has a required software patch or patch level.
- If the attestation is not valid, the system quarantines the host by preventing it from sending data to the protected network.
- Quarantining includes serving a "quarantine notification page" and, in response to a DNS query, providing the IP address of a "quarantine server."
- Permitting the quarantined host to communicate with a "remediation host."
- 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: Sharing a specification with the '705 Patent, the '048 Patent addresses the same fundamental problem of infected devices threatening protected networks. The background section specifically notes that unwanted network communications like spam and phishing burden networks and expose users to risk. (’048 Patent, col. 1:22-27; Compl. ¶30).
- The Patented Solution: The solution is nearly identical to that of the '705 Patent, centering on detecting an insecure host, verifying its state via a trusted computing base, and quarantining it if necessary. The abstract of the ’048 Patent similarly describes detecting an insecure condition and, if found, quarantining the host by re-routing a service request to a quarantine server. (’048 Patent, Abstract).
- Technical Importance: Like the '705 Patent, this invention provides an automated technical solution to a specific problem in computer network security, improving upon prior art access control methods. (Compl. ¶27).
Key Claims at a Glance
- The complaint asserts independent claim 17. (Compl. ¶63).
- The essential elements of claim 17 are largely identical to claim 19 of the '705 Patent, covering detection of an insecure condition via a trusted computing base, receiving a signed attestation, quarantining the host if the attestation is invalid, and permitting communication with a remediation host. (Compl. ¶65).
- A key distinction lies in the quarantine mechanism. Claim 17 requires:
- Serving a quarantine notification page by "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."
- The complaint reserves the right to assert additional claims. (Compl. ¶28).
III. The Accused Instrumentality
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
- The complaint describes the accused product as Google's "zero-trust solution that enables an organization's workforce to access web applications securely from anywhere." (Compl. ¶48). Functionally, it performs "endpoint posture assessments" to ensure devices comply with security policies before being granted access to protected resources. (Compl. ¶49). To do this, it leverages "certificate-based access control," which uses device certificates stored in hardware-based security modules like Trusted Platform Modules (TPMs) to verify a device's identity and state. (Compl. ¶50). The system can be configured to automatically block access from devices that are deemed non-compliant or compromised. (Compl. ¶¶53-54). A diagram from Google's documentation, referenced in the complaint, illustrates a "Trusted Device" architecture that includes "TPM / OS keystores." (Compl. p. 19).
IV. Analysis of Infringement Allegations
’705 Patent Infringement Allegations
| Claim Element (from Independent Claim 19) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| [A] detecting an insecure condition on a first host that has connected or is attempting to connect to a protected network | The accused product delivers "endpoint posture assessments and ensure[s] that endpoints meet security and compliance policies before they are allowed to access a protected network." | ¶49 | col. 21:21-24 |
| [B1] contacting a trusted computing base associated with a trusted platform module within the first host | The product uses certificate-based access with "strong key protection" that leverages "secure cryptographic storage such as TPMs and OS keystores." | ¶50 | col. 21:26-28 |
| [B2] receiving a response, and determining whether the response includes a valid digitally signed attestation of cleanliness | The product uses a mutual TLS handshake where the server validates a device's identity by decrypting a message using the public key from the device's certificate, which is stored on the trusted device. A diagram in the complaint shows this client-server certificate verification process. | ¶51, p. 21 | col. 21:29-32 |
| [C] wherein the valid digitally signed attestation of cleanliness includes at least one of an attestation that the trusted computing base has ascertained that the first host is not infested, and an attestation... [of] a patch or a patch level | The product's "Verified Access" API uses digital certificates stored in hardware TPMs to "cryptographically validate the identity" and "verify that any connected devices conform to the company's security policies." | ¶52 | col. 21:33-41 |
| [D] when it is determined that the response does not include a valid digitally signed attestation of cleanliness, quarantining the first host | The product's "Context-Aware Access" feature allows administrators to "block such devices from accessing Workspace data with a few clicks" if, for example, they have an outdated operating system. | ¶53 | col. 22:1-5 |
| [E1] ...serving a quarantine notification page to the first host when the service request comprises a web server request | When a user is blocked, the product can display "remediation messages" which provide "guidance on how to address the reason they are blocked." | ¶54 | col. 22:24-28 |
| [E2] ...providing in response an IP address of a quarantine server... if a host name that is the subject of the DNS query is not associated with a remediation host | The product provides a quarantine notification page with "links, or IP address(es), with resources (i.e. quarantine servers) configured to resolve the quarantine." | ¶55 | col. 22:29-39 |
| [F] permitting the first host to communicate with the remediation host | The product allows a quarantined device to access remediation resources, such as links provided in remediation messages, to help make the device compliant. | ¶56 | col. 22:40-42 |
’048 Patent Infringement Allegations
| Claim Element (from Independent Claim 17) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| [A] through [D] | The allegations for these elements are identical to those for the '705 Patent, as described in Section IV above. The complaint incorporates these allegations by reference. | ¶¶66-67 | col. 22:35-51 |
| [E1] receiving a service request... determining whether the... request... is associated with a remediation request... serving a quarantine notification page | The accused product determines if a device is non-compliant and, if so, blocks access and displays a quarantine notification with remediation information. It can determine if a subsequent request is for remediation. The complaint includes a screenshot of a "You don't have access" notification page. | ¶¶69-71, p. 31 | col. 23:1-10 |
| [E2] wherein serving the quarantine notification page to the first host includes 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 | The complaint alleges that when a user is blocked, the system re-routes the user to a notification page, such as one stating "You don't have access," which constitutes a redirect to a quarantine server. | ¶¶72, 74 | col. 23:11-17 |
| [F] permitting the first host to communicate with the remediation host configured to provide data usable to remedy the insecure condition | As with the '705 Patent, the product allows a quarantined device to access remediation resources to become compliant. | ¶75 | col. 23:18-21 |
Identified Points of Contention
- Scope Questions: A primary question may be whether Google's modern, certificate-based "zero-trust" architecture falls within the scope of the claims, which were drafted based on 2004-era technology. For example, does verifying a device's state via an X.509 certificate constitute "receiving a ... digitally signed attestation of cleanliness" in the specific manner envisioned by the patents?
- Technical Questions: A key technical question for the '048 Patent is whether the accused product's mechanism for blocking a user and displaying an "access denied" page constitutes "re-routing by responding... with a redirect" as the term is technically understood. The complaint provides screenshots of network developer tools that show a "200 OK" status code, which raises the question of whether a true redirect (e.g., a 3xx status code) occurs as required by the claim. (Compl. p. 32).
V. Key Claim Terms for Construction
The Term: "trusted computing base"
- Context and Importance: This term is foundational to the claimed invention's security model. The outcome of the infringement analysis may depend on whether Google's architecture, which uses components like TPMs, OS keystores, and certificate proxies, qualifies as a "trusted computing base." Practitioners may focus on this term because its definition will determine if a modern zero-trust system maps onto the patent's earlier-conceived framework.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claims require the base to be capable of providing a "valid digitally signed attestation of cleanliness." ('705 Patent, cl. 19). Plaintiff may argue this is a functional definition that encompasses any combination of hardware and software, like Google's, that performs this function.
- Evidence for a Narrower Interpretation: The specification references specific contemporary examples, such as the "Paladium security initiative under development by Microsoft" and "TCG specifications." ('705 Patent, col. 13:50-59). Defendant may argue the term should be limited to these specific types of architectures known at the time of invention.
The Term: "quarantining the first host"
- Context and Importance: The definition of this term is critical because the accused product primarily performs application-level access control. The dispute will question whether blocking access to a specific application (e.g., Google Workspace) is equivalent to "quarantining the first host."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim itself provides a definition: "including by preventing the first host from sending data to one or more other hosts associated with the protected network." ('705 Patent, cl. 19). Plaintiff may argue that blocking an application from communicating with network resources meets this definition.
- Evidence for a Narrower Interpretation: The specification frequently discusses quarantining in a broader, system-wide context, such as redirecting all "outbound traffic" from the system (see '705 Patent, Fig. 14). Defendant may argue this implies a more comprehensive, host-level isolation rather than targeted, application-specific blocking.
VI. Other Allegations
- Indirect Infringement: The complaint does not contain a separate count for indirect infringement. However, it alleges that Google infringes "in combination with actions of customers" and provides extensive citations to Google's public documentation, which allegedly instructs users on how to configure and use the accused features. (Compl. ¶¶16, 50-55). These allegations could form the basis for a claim of induced infringement.
- Willful Infringement: The complaint does not allege pre-suit knowledge of the patents. It does, however, request enhanced damages in its prayer for relief. (Compl. ¶VII.C). Any claim for willfulness would likely be based on post-suit conduct, beginning with Google's receipt of the complaint.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of technological mapping: Can the patent's 2004-era concepts, particularly the "trusted computing base" and its "attestation of cleanliness," be construed to read on Google's modern, certificate-based zero-trust architecture, which focuses on device identity and policy compliance?
- A key evidentiary question will be one of functional mechanism: For the '048 Patent specifically, does the accused product's system for blocking access and displaying a notification page operate via a "redirect" in the specific technical sense required by claim 17, or does it use a different implementation that may fall outside the claim's literal scope?
- A central strategic question will be the impact of prior proceedings: How will the patents' successful navigation of IPR challenges, combined with the existence of prior claim construction rulings by the same judge in the related Cisco litigation, influence the parties' strategies and the court's management of the present case?