DCT
2:25-cv-01196
Stealthpath IP Inc v. Zscaler Inc
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: StealthPath IP Inc. (Delaware)
- Defendant: Zscaler, Inc. (Delaware)
- Plaintiff’s Counsel: Latham and Watkins LLP; Miller Fair Henry PLLC
- Case Identification: [StealthPath IP Inc.](https://ai-lab.exparte.com/party/stealthpath-ip-inc) v. [Zscaler, Inc.](https://ai-lab.exparte.com/party/zscaler-inc), 2:25-cv-01196, E.D. Tex., 12/08/2025
- Venue Allegations: Plaintiff alleges venue is proper because Defendant maintains a regular and established place of business in the district—an office in Plano, Texas—and has committed acts of patent infringement through the actions of employees at that office.
- Core Dispute: Plaintiff alleges that Defendant’s "zero trust" cybersecurity products, including the Zscaler Zero Trust Exchange platform and its various modules, infringe three U.S. patents related to securing network communications.
- Technical Context: The dispute is in the field of "zero trust" cybersecurity, a security model that assumes no user or device is trusted by default and requires verification for every access request, which is of increasing market significance for securing distributed corporate networks.
- Key Procedural History: The complaint notes that U.S. Patent No. 11,729,143 is a continuation of the application that issued as U.S. Patent No. 10,965,646. The complaint also asserts that Plaintiff has complied with statutory patent marking obligations by providing notice through its webpage.
Case Timeline
| Date | Event |
|---|---|
| 2017-10-06 | Earliest Priority Date for the ’803, ’646, and ’143 Patents |
| 2019-08-06 | U.S. Patent No. 10,374,803 Issues |
| 2021-03-30 | U.S. Patent No. 10,965,646 Issues |
| 2023-08-15 | U.S. Patent No. 11,729,143 Issues |
| 2025-12-08 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 10,374,803 - "Methods for Internet Communication Security"
The Invention Explained
- Problem Addressed: The patent identifies a "need to address security threats that can arise during hypervisor-mediated communications," where "malware may target applications in virtual machines either directly or through the hypervisor." (’803 Patent, col. 1:31-36; Compl. ¶17).
- The Patented Solution: The invention proposes a security system that operates within the hypervisor—the software layer that creates and runs virtual machines. This system intercepts incoming network packets, decrypts a portion of the packet using a "single-use cryptographic key," authorizes the packet by comparing its parameters to expected values, and only then passes the authorized packet to the virtual device. (’803 Patent, Abstract; ’803 Patent, col. 1:45-52). This creates a checkpoint to prevent malicious traffic from reaching virtualized components.
- Technical Importance: This approach aimed to improve security in virtualized computing environments by preventing malware from exploiting vulnerabilities in the hypervisor to attack the virtual machines it manages. (Compl. ¶18; ’803 Patent, col. 22:49-61).
Key Claims at a Glance
- The complaint asserts infringement of at least Claim 1. (Compl. ¶33).
- Independent Claim 1 requires:
- A product for authorizing network communications in a hypervisor comprising a non-transitory computer-readable storage medium with program code.
- The program code is executable in a hypervisor to perform operations comprising:
- intercepting a first network packet in the hypervisor, the packet comprising a first higher-than-OSI layer three portion;
- decrypting, with a single-use cryptographic key, at least a portion of the higher-than-OSI layer three portion to obtain one or more first packet parameters;
- authorizing the first network packet in the hypervisor, comprising: comparing the one or more first packet parameters with one or more first expected values; and
- passing the authorized first network packet to a virtual device. (Compl. ¶32).
U.S. Patent No. 10,965,646 - "Methods For Internet Communication Security"
The Invention Explained
- Problem Addressed: The patent background describes vulnerabilities arising from "weak-links in the network security," such as legacy devices that cannot support advanced security measures, creating a need for "interfaces to immunize, or to at least limit the attendant risks of, communications between protected and unsecure networks." (’646 Patent, col. 1:30-50; Compl. ¶20).
- The Patented Solution: The invention describes a product that secures communications between networked devices by acting as an intermediary. It receives a network packet, establishes a secure pathway with the target user-application by exchanging and comparing application identifiers, confirms the packet's payload conforms to a pre-assigned data model for that application, and then passes the validated payload over the secure pathway. (’646 Patent, Abstract; Compl. ¶22).
- Technical Importance: This technology provides a method for "bridging network communications between device networks sharing protected, trusted... communications with the large body of relatively unsecure legacy devices and networks," thereby securing heterogeneous environments. (Compl. ¶21; ’646 Patent, col. 1:51-56).
Key Claims at a Glance
- The complaint asserts infringement of at least Claim 1. (Compl. ¶55).
- Independent Claim 1 requires:
- A product for securing communications of a plurality of networked computing devices comprising a non-transitory computer-readable storage medium with program code.
- The program code is executable by a processor to perform operations comprising:
- receiving a first port-to-port network packet from a first computing device;
- establishing a secure communication pathway with a user-application at a second computing device, comprising: sending an application identifier, receiving a second application identifier in response, and comparing the second application identifier with a pre-established value;
- confirming a payload of the first port-to-port network packet conforms to a data model pre-assigned to the pre-established value for the user-application; and
- passing the payload to the second computing device via the secure communication pathway. (Compl. ¶54).
U.S. Patent No. 11,729,143 - "Methods For Internet Communication Security"
Technology Synopsis
The patent describes a security product that "consumes" a network packet to obtain its payload and destination port number. It then confirms the payload conforms to a data model pre-assigned to that specific port number. After confirmation, it forms a new packet containing a second payload and identification codes, and sends this new packet to security software on the destination device. (Compl. ¶24; ’143 Patent, col. 2:28-44).
Asserted Claims
The complaint asserts infringement of at least Claim 1. (Compl. ¶79).
Accused Features
The complaint alleges that Zscaler's products "consum[e] a first network packet to obtain a first payload and a destination port number," such as by receiving inbound web traffic based on specific ports. It further alleges the products confirm the payload conforms to a "data model pre-assigned to the destination port number" via customizable associations between port numbers and traffic types, before forming and sending a second packet. (Compl. ¶81-85).
III. The Accused Instrumentality
Product Identification
The complaint identifies the "Zscaler Zero Trust Exchange" platform and its associated modules as the Accused Products. These modules include Zscaler Zero Trust SASE, Zscaler Zero Trust SD-WAN, Zscaler Internet Access, Zscaler Private Access, Zscaler Zero Trust Firewall, Zscaler Client Connector, Zscaler Branch Connector, Zscaler Clientless Access, and Zscaler App Connector. (Compl. ¶26).
Functionality and Market Context
The Accused Products constitute a cloud-delivered security platform based on a "zero trust" architecture. The platform functions as a centralized exchange or "intelligent switchboard" that brokers connections between users/devices and applications without placing them on the same network. (Compl. ¶56). A core feature is its ability to inspect all traffic, including encrypted SSL/TLS traffic, to enforce security policies and prevent lateral threat movement. (Compl. ¶35, ¶38, ¶41). Traffic is directed to this central exchange by components such as the "Client Connector" software agent on user devices or the "Branch Connector" virtual machine, which can operate in a hypervisor environment to manage traffic from branch offices. (Compl. ¶36, ¶39). The complaint provides a diagram illustrating this architecture, where all communications are brokered through the central Zero Trust Exchange. (Compl. p. 12).
IV. Analysis of Infringement Allegations
U.S. Patent No. 10,374,803 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A product for authorizing network communications in a hypervisor...the computer-readable program code executable in a hypervisor... | The Zscaler Branch Connector and App Connector are identified as virtual machines that can be deployed and run in hypervisor environments such as "VMware vCenter or vSphere Hypervisor" to manage communications. | ¶39 | col. 1:47-52 |
| intercepting a first network packet in the hypervisor, the first network packet comprising a first higher-than-OSI layer three portion; | Zscaler's Secure Internet and SaaS Access (ZIA) feature is alleged to identify and control network applications using Deep Packet Inspection (DPI) based on Layer 7 of the OSI model. | ¶40 | col. 1:58-60 |
| decrypting, with a single-use cryptographic key, at least a portion of the first higher-than-OSI layer three portion to obtain one or more first packet parameters; | The Zscaler platform is alleged to perform "complete SSL inspection at scale," which involves decrypting SSL/TLS encrypted traffic between a user's browser and a destination server. | ¶41 | col. 2:2-5 |
| authorizing the first network packet in the hypervisor, comprising: comparing the one or more first packet parameters with one or more first expected values; and | The Accused Products are alleged to apply firewall filtering policy rules that compare packet parameters (e.g., Applications, Services, Source/Destination IP) against configured criteria ("expected values") to determine a traffic action. | ¶42 | col. 2:5-9 |
| passing the authorized first network packet to a virtual device. | Once a packet matches a rule, the Zscaler service takes an action, which may be to "Allow" the packet to pass through the firewall to its destination, which the complaint alleges can be a virtual device. | ¶43 | col. 2:9-11 |
Identified Points of Contention
- Scope Questions: A primary question may be one of locational scope. The claim requires operations such as "authorizing" to occur "in a hypervisor." The complaint alleges Zscaler's Branch Connector runs in a hypervisor (Compl. ¶39), but describes the core authorization and inspection functions as being performed by the cloud-based "Zscaler Zero Trust Exchange." (Compl. ¶35). This raises the question of whether traffic management by a VM in a hypervisor that sends traffic to an external cloud service for authorization meets the claim limitation.
- Technical Questions: The complaint alleges decryption with a "single-use cryptographic key" (Compl. ¶41), a specific limitation from the patent (’803 Patent, col. 2:2). The provided evidence describes Zscaler's SSL inspection process generally but does not specify that the keys used are "single-use." The basis for this specific allegation may be a key point of dispute.
U.S. Patent No. 10,965,646 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving a first port-to-port network packet from a first computing device; | The Accused Products are alleged to receive inbound web traffic, such as an HTTPS request from a user's browser, which is based on specific ports (e.g., 80/443). | ¶58-59 | col. 2:28-30 |
| establishing a secure communication pathway with a user-application at a second computing device...comprising: sending an application identifier...receiving, in response...a second application identifier...and comparing the second application identifier with a pre-established value...; | This is alleged to be met by Zscaler's SSL inspection process, which establishes an SSL tunnel. The complaint maps "sending an application identifier" to the service sending a server certificate to the user's browser, and "receiving...a second application identifier" to the service receiving a client key in response, which is then validated ("comparing"). | ¶60, ¶63-64 | col. 2:45-56 |
| confirming a payload of the first port-to-port network packet conforms to a data model pre-assigned to the pre-established value for the user-application; and | The Zscaler Client Connector is alleged to use an "Allowlist Processes" feature, which contains a list of approved file paths for applications, to confirm that a packet payload conforms to this pre-assigned list. | ¶65 | col. 2:30-37 |
| passing the payload to the second computing device via the secure communication pathway. | The system allegedly passes the payload through the Zero Trust Exchange to the destination after applying security policies like Data Loss Prevention (DLP), as shown in a diagram illustrating DLP scanning. | ¶66 | col. 2:41-44 |
Identified Points of Contention
- Scope Questions: An issue of definitional scope arises regarding the term "application identifier." The complaint maps this term to standard components of an SSL/TLS handshake, such as a server certificate. (Compl. ¶60). The question is whether this standard, public cryptographic object meets the patent's requirement for an "application identifier" exchanged to establish a secure path, or if the patent contemplates a more specific or proprietary identifier.
- Technical Questions: There may be a question of functional mismatch regarding the "confirming a payload" step. The complaint maps this to Zscaler's "Allowlist Processes." (Compl. ¶65, p. 28). This feature appears to be a security measure for the Client Connector agent itself, listing executables that are allowed to run. It is an open question whether this feature inspects the payload of network traffic to confirm conformance with a data model for the user-application, as the claim requires.
V. Key Claim Terms for Construction
"in a hypervisor" (’803 Patent, Claim 1)
- Context and Importance: This term is central to the infringement theory for the ’803 Patent. Its construction will determine whether Zscaler's cloud-centric architecture can be found to infringe a patent that, on its face, appears to describe security logic resident within the hypervisor layer itself. Practitioners may focus on this term because the physical location of the "authorizing" step is a critical factual predicate for infringement.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states that "the adapted network security software may be cooperatively configured with network security software that is running in a virtual machine." (’803 Patent, col. 4:10-14). This language could suggest that performing the claimed functions via software in a VM that runs on the hypervisor is sufficient to be "in a hypervisor."
- Evidence for a Narrower Interpretation: The patent’s Brief Summary describes "a network security layer resident in the hypervisor that authenticates and authorizes incoming communications." (’803 Patent, col. 1:49-50). The claim preamble recites "[a] product for authorizing network communications in a hypervisor." This language suggests the authorization function itself, not just a traffic-forwarding component, is located within the hypervisor environment.
"application identifier" (’646 Patent, Claim 1)
- Context and Importance: The complaint's infringement theory for the '646 patent hinges on mapping this term to standard elements of an SSL handshake, such as a server certificate. (Compl. ¶60). The viability of this theory depends on whether the term is construed broadly enough to cover such standard cryptographic objects, or is limited to a more specific, potentially proprietary, identifier.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The term "application identifier" is not explicitly defined in the patent, and its plain meaning could be broad enough to encompass any data that serves to identify an application, which a server certificate does. The patent abstract refers generally to exchanging "application identifiers, and data type identifiers," which could support a non-limiting reading. (’646 Patent, Abstract).
- Evidence for a Narrower Interpretation: The claims of the patent family also use the term "nonpublic... identification code." (Compl. ¶23). While Claim 1 of the ’646 Patent uses the broader "application identifier," a defendant may argue that the specification's focus on nonpublic codes suggests the invention is directed to a proprietary identification scheme, not the exchange of public certificates inherent to public key infrastructure.
VI. Other Allegations
Indirect Infringement
The complaint alleges induced infringement under 35 U.S.C. § 271(b), asserting that Defendant provides instructions and support, such as webinars on "zero trust," that actively encourage customers to use the Accused Products in an infringing manner. (Compl. ¶46, ¶70, ¶88). It also alleges contributory infringement under § 271(c), stating that the Accused Products are especially made for infringement and are not staple articles of commerce suitable for substantial non-infringing use. (Compl. ¶47, ¶71, ¶89).
Willful Infringement
Willfulness allegations are based on Defendant’s alleged knowledge of the asserted patents and infringement "at least as of the date on which it was served with this complaint." (Compl. ¶28). This forms a basis for post-suit willfulness, which is alleged for all three asserted patents. (Compl. ¶49, ¶73, ¶91).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural scope: can the ’803 patent’s claim limitations requiring authorization "in a hypervisor" be met by a security architecture where a virtual machine in a hypervisor forwards traffic to a separate, cloud-based platform where the authorization policies are actually executed? The outcome may depend on whether the role of the hypervisor-based component is deemed sufficient to bring the entire authorization process "in" the hypervisor.
- A key evidentiary question will be one of functional mapping: does the standard exchange of cryptographic objects like server certificates during an SSL handshake perform the specific, multi-step process of exchanging and comparing an "application identifier" as required by Claim 1 of the ’646 patent, or is there a fundamental mismatch between the claimed proprietary-sounding process and the public-key infrastructure protocol alleged to infringe?
- A central technical question will be one of operational accuracy: does the accused "Allowlist Processes" feature, which on its face appears to control the execution of the Zscaler agent itself, actually perform the claimed function of confirming that the payload of a network packet conforms to a pre-assigned data model for a user application, as alleged for the ’646 patent?