Privakey Inc v. Cisco Systems Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Privakey, Inc. (Delaware)
  • Defendant: Cisco Systems, Inc. (Delaware)
  • Plaintiff’s Counsel: Brown Rudnick LLP; Scheef & Stone LLP
• Case Identification: 2:25-cv-00984, E.D. Tex., 10/06/2026
• Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains regular and established places of business in Richardson and Allen, Texas; employs hundreds of people in the district; solicits business in the district; and has authorized sellers and representatives offering the accused products in the district.
• Core Dispute: Plaintiff alleges that Defendant’s Cisco Duo multi-factor authentication platform infringes three patents related to device-based, internet-centric authentication systems.
• Technical Context: The technology concerns methods for securely authenticating users to online services, moving beyond traditional passwords by using cryptographic keys managed by a user's device.
• Key Procedural History: The complaint alleges that Defendant had pre-suit knowledge of the patent family because the U.S. Patent and Trademark Office cited the '400 Patent's published application as prior art against Defendant’s own patent applications during prosecution. The complaint also alleges pre-suit discussions regarding a potential partnership between Plaintiff and Duo Security, Inc., which was later acquired by Defendant.

Case Timeline

Date	Event
2014-11-07	Earliest Priority Date for '400, '715, and '234 Patents
2015-01-01	Privakey CEO and Duo Security manager conduct in-person meeting
2017-01-01	Privakey and Duo Security employees interact at RSA Conference
2017-11-07	U.S. Patent No. 9,813,400 '400 Patent Issues
2018-01-01	Privakey CEO visits Duo Security booth at RSA Conference
2019-07-09	U.S. Patent No. 10,348,715 '715 Patent Issues
2021-01-26	U.S. Patent No. 10,904,234 ('234 Patent) Issues
2021-05-25	USPTO cites '400 Published Patent Application in rejection of Defendant's patent application
2022-10-28	Date of docket entry in Orckit Corp. v. Cisco Systems, Inc. cited to establish jurisdiction
2024-06-18	Defendant receives notice of '400 Published Patent Application during prosecution of another patent application
2026-10-06	Amended Complaint Filed

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

U.S. Patent No. 9,813,400 - "Computer-Implemented Systems and Methods of Device Based, Internet-Centric, Authentication"

• Patent Identification: U.S. Patent No. 9,813,400, issued November 7, 2017. Compl. ¶16

The Invention Explained

• Problem Addressed: The patent addresses the security vulnerabilities and user inconvenience of traditional authentication methods Compl. ¶28 Passwords can be stolen and reused, while multi-factor solutions like hardware tokens are costly, complex to manage across different services, and suffer from "lack of user convenience" Compl. ¶¶29-30 '400 Patent, col. 1:63-2:3
• The Patented Solution: The invention proposes an authentication architecture centered on a single identity provider (IDP) and a device-side application Compl. ¶32 This application creates and stores a private key on the user's device, while a corresponding public key is stored by the IDP Compl. ¶32 '400 Patent, col. 3:21-26 To authenticate, the user initiates access to a service, the IDP sends a challenge, and the device-side application uses the private key (unlocked by a user credential) to generate a response that the IDP validates with its public key before granting access Compl. ¶33 '400 Patent, col. 3:43-61
• Technical Importance: The technology aimed to provide a cost-effective, secure, and user-friendly method for authenticating users across multiple internet services without the weaknesses of passwords or the complexity of traditional multi-factor authentication Compl. ¶31

Key Claims at a Glance

• The complaint asserts at least independent Claim 1 and Claim 14 Compl. ¶59
• Independent Claim 1 of the '400 Patent recites a method with the following essential elements:
  • A service provider server sends an internet service identifier to an identity provider (IDP).
  • The IDP generates a web page displaying the service provider's identifier and internet address.
  • The IDP requires a device-side application to display a page for entering a user credential, which can decrypt a stored private key.
  • The IDP receives an approved authentication challenge message from the device-side application.
  • The IDP validates the message using a stored public key corresponding to the private key.
  • Upon validation, the IDP authorizes access by redirecting the user's browser to the service's call-back internet address. Compl. ¶33
• The complaint does not explicitly reserve the right to assert dependent claims but does reference them for context Compl. ¶39

U.S. Patent No. 10,348,715 - "Computer-Implemented Systems and Methods of Device Based, Internet-Centric, Authentication"

• Patent Identification: U.S. Patent No. 10,348,715, issued July 9, 2019. Compl. ¶18

The Invention Explained

• Problem Addressed: The patent identifies the need for "cost-effective, secure, computer-implemented systems and methods" to overcome the technical challenges and vulnerabilities of internet-based authentication, such as the complexity and limited adoption of existing multi-factor authentication systems '715 Patent, col. 2:1-3 '715 Patent, col. 2:47-51
• The Patented Solution: The '715 Patent describes a similar architecture to the '400 Patent, but details an "out-of-band" interaction Compl. ¶35 In this flow, a web browser on a user's device initiates the process by transmitting a user identifier to the IDP. The IDP then sends an API call to the device-side application, which validates the user's input by decrypting the locally stored private key. If successful, the application sends a signed challenge message to the IDP for validation before access is granted via browser redirection '715 Patent, claim 11 This architecture maintains the separation of the private key on the user's device from the server-side components '715 Patent, col. 3:6-9
• Technical Importance: This approach provided a specific, secure workflow for multi-factor authentication initiated from a standard web browser, improving security without requiring the user to manage multiple complex credentials for different services Compl. ¶36

Key Claims at a Glance

• The complaint asserts at least independent Claim 1 and Claim 11 Compl. ¶98
• Independent Claim 11 of the '715 Patent recites a method with the following essential elements:
  • In an out-of-band interaction (other than with the identity provider application), a web browser transmits a user identifier to an IDP's computer server.
  • In response to a first API call from the IDP server, the identity provider application validates a received user input by attempting to decrypt a stored private key.
  • If the input is validated, the application transmits an approved authentication challenge message via an API call to the IDP server.
  • In response to a second API call from the IDP server indicating successful validation, the identity provider application authorizes access by redirecting the browser. Compl. ¶35
• The complaint references dependent claims to further describe how authentication information is protected and exchanged Compl. ¶39

U.S. Patent No. 10,904,234 - "Systems and Methods of Device Based Customer Authentication and Authorization"

• Patent Identification: U.S. Patent No. 10,904,234, issued January 26, 2021 Compl. ¶20

Technology Synopsis

The '234 patent describes authentication software that is embedded within a remote service's own application on a user's mobile device Compl. ¶37 This embedded code receives challenges from an authorization service, validates a user credential (such as a PIN or biometric) using a private key stored on the device, and transmits a message back to the authorization service to enable initiation of the remote service Compl. ¶¶37-38

Asserted Claims

At least Claim 10 and Claim 11 Compl. ¶134

Accused Features

The complaint alleges that the "Duo Mobile Application" is program code that resides on a user's device and is embedded within the application to perform the claimed functions, such as generating cryptographic key pairs, storing the private key, and verifying authentication challenges Compl. ¶138

III. The Accused Instrumentality

Product Identification

The accused instrumentality is the "Cisco Duo" platform ("Duo Platform"), which includes a suite of products and services such as the "Duo Mobile App," "Duo Single Sign-On," "Duo Directory," "Verified Duo Push," and "Duo Biometrics" Compl. ¶¶45-46

Functionality and Market Context

• Cisco Duo is a cloud-based security platform that provides multi-factor authentication (MFA), single sign-on (SSO), and device trust policies for accessing applications and networks Compl. ¶45 The complaint alleges that the Duo Platform, via the Duo Mobile App, generates an authentication token comprised of a public and private cryptographic key pair Compl. ¶67 The public key is stored on Duo's servers, while the private key is stored on the user's device Compl. ¶70 The complaint includes a screenshot from Duo's help documentation stating, "During Duo Mobile account activation, an asymmetric key pair is generated... The private key is stored securely on the mobile device while the public key is maintained in Duo’s cloud service." Compl. Ex. 16, p. 26
• Authentication is allegedly performed when a user provides a credential, such as a PIN or a biometric factor (e.g., Face ID), to unlock the private key and sign an authentication challenge Compl. ¶73 A diagram in the complaint illustrates this authentication flow, showing a "credential manager" generating a signature over a challenge using a private key Compl. Ex. 20, p. 29 Duo's servers then allegedly receive this signed challenge via an API call and validate it using the stored public key to authorize access Compl. ¶74

IV. Analysis of Infringement Allegations

'400 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
...receiving, via a respective application programming interface (API) call from a respective computer server of each of the plurality of Internet service providers, a respective identifier for a respective requested one of the respective one or more Internet services...	The Duo Platform, using protocols like SAML and OIDC, receives authentication requests via API calls that identify the service a user wants to access. Compl. Ex. 15, p. 26	¶71	col. 3:27-38
...automatically generating, and transmitting to the respective web browser, a respective web page that displays the respective visually perceptible identifier of the respective Internet service provider and a respective Internet address of the respective web page belonging to the respective Internet service provider...	The Duo Platform generates a Duo-based webpage that includes the logo and URL of the service the user is attempting to log into. Compl. Ex. 18, p. 28	¶72	col. 3:39-47
...requiring the respective identity provider application...to display a respective page to input the respective user credential of the respective Internet user, wherein each input user credential is usable to decrypt the respective stored private key portion of the respective authentication token...	The Duo Mobile App provides functionality for inputting user credentials like PINs and biometrics (e.g., Face ID), which are used to unlock the private key to sign an authentication challenge. Compl. Ex. 19, p. 29	¶73	col. 3:48-55
...receiving, via a respective API call from the respective identity provider application...a respective approved authentication challenge message...	After the Duo Mobile App signs the challenge request with the unlocked private key, the signed request is sent back via an API call to the Duo SSO platform.	¶74	col. 3:56-59
...validating...the received approved authentication challenge messages using the respective stored public key portion of the respective authentication token...	The Duo Platform's servers validate the signed challenge from the Duo Mobile App using the stored public key. Compl. Ex. 20, p. 29	¶74	col. 3:59-61
...authorizing access by the respective Internet user to the respective requested one Internet service by re-directing the respective web browser to a respective one of the respective one or more call-back Internet addresses...	If the signature matches, the Duo Platform authorizes access and directs the user to the redirect URI associated with the service. Compl. Ex. 22, p. 30	¶74	col. 3:62-67

'715 Patent Infringement Allegations

Claim Element (from Independent Claim 11)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
...in an out-of-band interaction with other than the single identity provider application, a web browser...transmitting an electronic signal indicative of an Internet user identifier to the computer server of the single identity provider...	When a webpage contains a link to sign in, protocols like SAML and OIDC facilitate transmission of API calls to fulfill the request, which begins an authentication process outside the Duo Mobile App. Compl. Ex. 17, p. 27	¶108	col. 5:25-34
...in response to receiving an API call from the computer server of the single identity provider, the single identity provider application...validating a received Internet user input by attempting to decrypt the stored private key portion of the created authentication token...	The Duo Mobile App receives a prompt (e.g., a push notification) and accepts user credentials like biometrics to unlock the private key and sign the authentication challenge. Compl. Ex. 19, p. 29	¶109	col. 5:50-54
...if the received input is validated, transmitting an approved authentication challenge message via an API call to the computer server of the single identity provider...	After the Duo Mobile App signs the challenge with the unlocked private key, the signed request is sent back via an API call to the Duo SSO platform. Compl. Ex. 20, p. 29	¶110	col. 5:55-59
...in response to receiving another API call from the computer server...indicating successful validation of the transmitted authentication challenge message, the single identity provider application authorizing access...by re-directing the web browser...	If the signature is validated by Duo's servers, the Duo Platform authorizes access and directs the user to the redirect URI. Compl. Ex. 22, p. 45	¶110	col. 5:60-64

Identified Points of Contention

• Scope Questions: A central question may be whether the "Duo Mobile App," which functions as a client to the Duo service, meets the claim limitation of an "identity provider application residing on the computing device." A defendant might argue that the "identity provider" is Cisco's server-side platform, not the mobile app itself, suggesting a potential mismatch with the claim language.
• Technical Questions: The analysis will likely scrutinize the precise sequence of API calls and data transmissions within the Duo platform. A question for the court will be whether the alleged "out-of-band interaction" in the '715 patent, initiated from a web browser and fulfilled by the Duo Mobile App, technically operates in the manner required by the claim's specific, ordered steps.

V. Key Claim Terms for Construction

• The Term: "identity provider application...residing on the computing device" (from '400 Patent, Claim 1; '715 Patent, Claim 11)

• Context and Importance: This term is the core component on the user's device that manages the private key. The complaint equates this with the "Duo Mobile App" Compl. ¶67 Practitioners may focus on this term because the case may turn on whether a client application for a server-based identity service (like Duo) qualifies as the "identity provider application" itself, as recited in the claims.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent specification describes a "dID App" residing on a device that performs functions central to identity verification, such as creating authentication tokens and validating user credentials to decrypt a private key '715 Patent, col. 5:51-54 This could support an interpretation where any application performing these core identity functions on the device qualifies.
  • Evidence for a Narrower Interpretation: The patent's figures and description often distinguish between the "single identity provider (IDP) core" (server-side) and the "dID App" (device-side), treating them as separate components of the overall system '715 Patent, FIG. 1 '715 Patent, FIG. 2 This could support an argument that the "identity provider" is the server entity, and the "application" is merely its client, not the "identity provider application" itself.

• The Term: "out-of-band interaction" (from '715 Patent, Claim 11)

• Context and Importance: This term defines the manner in which the authentication process is initiated. The claim requires the interaction to be "with other than the single identity provider application," which is critical for distinguishing the invention from a flow that begins entirely within the authenticator app.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The specification illustrates workflows that begin in a "Web Browser," which then leads to interactions with the "dID App" and the "IDP Core" '715 Patent, FIG. 7 This suggests any process that starts outside the dedicated device application could be considered "out-of-band."
  • Evidence for a Narrower Interpretation: The term is not explicitly defined, leaving its scope open to debate. A defendant may argue that the communication between the browser and the device application is still part of a single, integrated "in-band" authentication session orchestrated by the IDP, and therefore does not meet the claim's requirement for a truly separate, "out-of-band" trigger.

VI. Other Allegations

Indirect Infringement

The complaint alleges inducement to infringe by asserting that Defendant provides instructions, user guides, marketing materials, and technical documentation that direct and encourage customers to use the accused Duo products in a manner that practices the patented methods Compl. ¶¶87-88 Compl. ¶¶123-124 Contributory infringement is alleged on the basis that Defendant provides software components (e.g., the Duo Mobile App) that are a material part of the invention, are not staple articles of commerce, and are especially adapted for infringement Compl. ¶¶91-92 Compl. ¶¶127-128

Willful Infringement

The complaint alleges willfulness based on both pre-suit and post-suit knowledge. Pre-suit knowledge is alleged based on meetings between Privakey and Duo Security (prior to its acquisition by Cisco) and, significantly, on multiple instances where the USPTO cited the '400 Patent's publication as prior art against Defendant's own patent applications Compl. ¶¶47-52 The complaint alleges that this history made Defendant aware of the Privakey patent family and its relevance. Post-suit knowledge is based on the service of the original complaint in this action Compl. ¶55

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

• A core issue will be one of definitional scope: can the term "identity provider application," which the patent describes as creating and managing authentication tokens on a user's device, be construed to cover the accused "Duo Mobile App," which functions as a client to the server-based Duo identity platform? The resolution of this question may determine whether a fundamental element of the asserted claims reads on the accused system.
• A second key issue will be one of operational correspondence: does the accused Cisco Duo authentication workflow, involving push notifications and interactions between a web browser and a mobile app, perform the exact sequence of steps—including the "out-of-band interaction" and specific API calls—recited in the asserted method claims, or is there a technical mismatch in their respective operations?
• A third central question will relate to willfulness and damages: given the allegations that Defendant was repeatedly confronted with Plaintiff's patent family during its own patent prosecution activities, a key question for the court will be what constitutes knowledge for the purposes of willfulness and whether Defendant's continued conduct was objectively reckless.