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
• Case Identification: Privakey, Inc. v. Cisco Systems, Inc., 2:25-cv-00984, E.D. Tex., 10/01/2025
• Venue Allegations: Plaintiff alleges venue is proper because Defendant has regular and established places of business in the Eastern District of Texas, including facilities in Richardson and Allen, employs hundreds of people in the district, and utilizes a work-from-home policy that constitutes an aggregate network of business locations within the district. The complaint also notes that Defendant has not contested personal jurisdiction in this district in a prior case.
• Core Dispute: Plaintiff alleges that Defendant's Cisco Duo multi-factor authentication and single sign-on product line infringes three U.S. patents related to device-based, internet-centric authentication methods.
• Technical Context: The technology at issue is in the field of digital identity and access management, specifically focusing on methods to securely authenticate users to multiple online services using a personal computing device as a trusted anchor.
• Key Procedural History: The three patents-in-suit constitute a patent family, with U.S. Patent No. 10,348,715 being a continuation of the application that led to U.S. Patent No. 9,813,400, and U.S. Patent No. 10,904,234 being a continuation-in-part of the application that led to the '715 patent. No other significant procedural history is mentioned.

Case Timeline

Date	Event
2014-11-07	Earliest Priority Date for '400, '715, and '234 Patents
2017-11-07	U.S. Patent No. 9,813,400 Issued
2019-07-09	U.S. Patent No. 10,348,715 Issued
2021-01-26	U.S. Patent No. 10,904,234 Issued
2025-10-01	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, "Computer-Implemented Systems and Methods of Device Based, Internet-Centric, Authentication," issued November 7, 2017 Compl. ¶17

The Invention Explained

• Problem Addressed: The patent's background describes conventional username-and-password authentication as vulnerable to security breaches, while existing multi-factor solutions are often costly, complex, and inconvenient for users, which has limited their adoption '400 Patent, col. 1:24-2:6
• The Patented Solution: The patent proposes a system centered around a single identity provider (IDP) and an application residing on a user's device (e.g., a smartphone). This application creates and manages a cryptographic authentication token (a public-private key pair) specific to the user, the device, and the application itself. When a user tries to access a service, a complex sequence involving the web browser and the on-device application is initiated, culminating in the application using its stored, encrypted private key to sign a challenge, thereby authenticating the user to the IDP, which then grants access to the requested service '400 Patent, abstract '400 Patent, FIG. 7
• Technical Importance: This method sought to provide a unified and more secure authentication framework that could work across numerous independent internet services without requiring users to manage separate credentials for each one '400 Patent, col. 7:4-14

Key Claims at a Glance

• The complaint asserts at least independent claim 14 Ex. D, p. 3
• Essential elements of Claim 14 include:
  • A non-transitory computer-readable storage device storing code for a method performed by an "identity provider application... residing on the computing device."
  • The application creates an authentication token (public/private key pair) specific to the user's ID, a user credential, a device ID, and the application itself.
  • The application encrypts the private key portion with the user credential, stores it locally, and transmits the public key portion to an IDP server.
  • A web browser displays a link to an internet service, and upon selection, initiates a multi-step process involving transmitting identifiers and displaying web pages from the IDP server.
  • The on-device processor automatically initiates the IDP application, which validates the user credential by decrypting the private key and then generates and transmits an approved authentication challenge message.
  • The web browser is redirected to a call-back address of the internet service provider to grant access.
• The complaint reserves the right to assert additional claims Compl. ¶32

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, "Computer-Implemented Systems and Methods of Device Based, Internet-Centric, Authentication," issued July 9, 2019 Compl. ¶18

The Invention Explained

• Problem Addressed: The patent identifies the same problems as its parent, the '400 patent: the insecurity of password-only systems and the complexity of traditional multi-factor authentication '715 Patent, col. 1:24-2:6
• The Patented Solution: The '715 patent refines the authentication process by explicitly claiming an "out-of-band interaction." In this flow, a user initiates a login in a web browser, which sends a user identifier to the IDP's server. The IDP server then communicates with the on-device IDP application (the "out-of-band" step), which handles the user input and cryptographic validation before authorizing the original browser session to proceed '715 Patent, abstract '715 Patent, FIG. 7
• Technical Importance: This out-of-band approach is designed to increase security by separating the channel used for service access (the browser) from the channel used for authentication approval (the on-device application), a technique aimed at thwarting certain phishing attacks '715 Patent, col. 7:4-14

Key Claims at a Glance

• The complaint asserts at least independent claim 11 Ex. E, p. 3
• Essential elements of Claim 11 include:
  • A non-transitory computer-readable storage device with code for a method performed by an "identity provider application... residing on the computing device."
  • The application creates an authentication token (public/private key), stores the private key locally, and transmits the public key to an IDP server.
  • An "out-of-band interaction" where a web browser transmits a user identifier to the IDP server in response to a user selecting a link for an internet service.
  • In response to an API call from the IDP server, the on-device application displays a page for user input, validates the input by attempting to decrypt the stored private key, and transmits an approved authentication message if successful.
  • In response to a subsequent API call indicating success, the application authorizes access by re-directing the web browser to a call-back address.
• The complaint reserves the right to assert additional claims Compl. ¶36

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, "Systems and Methods of Device Based Customer Authentication and Authorization," issued January 26, 2021 Compl. ¶19
• Technology Synopsis: The '234 patent describes a system where an "authorization service computer readable program code" resides on a mobile device and is embedded within a remote service's application. This code creates a public/private key token, receives challenge information from an authorization server, and uses the token to validate a user's credential to authorize initiation of the remote service '234 Patent, abstract
• Asserted Claims: The complaint asserts at least independent claim 10 Ex. F, p. 3
• Accused Features: The complaint alleges that the Cisco Duo Mobile App, which can be integrated into third-party applications via an SDK, functions as the claimed "authorization service computer readable program code," and that its interaction with the Duo backend to perform MFA infringes the '234 patent Compl. ¶25 Ex. F, p. 10

III. The Accused Instrumentality

Product Identification

The complaint identifies the accused instrumentalities as "Cisco's Duo Product," which encompasses a range of products and services including the "Duo Mobile App," "Duo Advantage," "Duo Premier," and associated components such as the "Duo mobile SDK" and "Duo Push Authorizations" Compl. ¶3 Compl. ¶26

Functionality and Market Context

The complaint characterizes the Cisco Duo product as a "cloud-based secure access platform that combines multi-factor authentication, single sign-on, device trust, and adaptive policies to enforce zero-trust access to apps and networks" Compl. ¶25 The infringement exhibits include marketing materials and screenshots portraying Duo as a user-friendly solution for multi-factor authentication (MFA) that works on user smartphones to secure access to various applications Ex. D, pp. 6-10 The complaint presents a screenshot from the Google Play store showing the Duo Mobile app, which "generates passcodes for login and can receive push notifications for easy, one-tap authentication" Ex. D, p. 7

IV. Analysis of Infringement Allegations

'400 Patent Infringement Allegations

Claim Element (from Independent Claim 14)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
an identity provider application of a single identity provider residing on the computing device:	The Cisco Duo Mobile App is alleged to be an identity provider application that resides on a mobile computing device (Ex. D, p. 11).	¶32	col. 5:29-33
creating an authentication token comprising a public key portion and a private key portion, wherein the created authentication token is specific to... an electronic mail address... a user credential... a device identifier... and the single identity provider application;	The Duo system allegedly generates an asymmetric key pair during account activation, which acts as the user's credential for Duo Push requests. This token is allegedly tied to the user's identity (email/username), a user credential (device PIN/biometric), and a device identifier (Ex. D, pp. 16-29).	¶32	col. 4:4-14
encrypting the private key portion of the created authentication token using the user credential of the Internet user;	The private key is allegedly encrypted at rest and protected by the device's native security features (e.g., iOS Secure Enclave or Android Keystore), which require the user's credential (PIN, passcode, biometric) for access (Ex. D, p. 32).	¶32	col. 5:5-10
storing the encrypted private key portion of the created authentication token in a memory of the computing device; and	The private key is allegedly stored securely on the mobile device, while the public key is maintained in Duo's cloud service (Ex. D, p. 33).	¶32	col. 5:11-13
transmitting, via an application programming interface (API) call to a computer server of the single identity provider, the public key portion of the created authentication token;	The public key is allegedly transmitted to and stored on Duo's servers during the registration of a security key or biometric (Ex. D, p. 34).	¶32	col. 5:14-19
a web browser... displaying... web pages... wherein each link... is configured to be selected to request access...	The Duo Central portal is alleged to be a cloud-hosted portal where users can visit a web page to access applications. The complaint provides a screenshot of a user logging into the University at Buffalo website, which is an Internet service provider (Ex. D, pp. 34-36).	¶32	col. 5:20-28
the web browser... displaying content of a respective second web page belonging to the single identity service provider...	The complaint alleges that after a user logs in, they are redirected to a Duo authentication page at a duosecurity.com domain to complete MFA, which is alleged to be the second web page (Ex. D, pp. 48-68).	¶32	col. 5:51-65
the processor of the computing device automatically initiating the single identity provider application...	The complaint alleges that a login request is sent to the user's phone in the form of a push notification, which automatically initiates the Duo Mobile app (Ex. D, p. 69).	¶32	col. 6:15-20
the single identity provider application: validating a respective user credential... by decrypting the stored encrypted private key portion...	The Duo app allegedly validates the user's credential (e.g., Face ID, Touch ID, or passcode) to access the private key stored in the device's secure element (e.g., Secure Enclave) for authentication (Ex. D, pp. 75-83).	¶32	col. 6:22-26
generating a respective approved authentication challenge message by digitally signing a predefined pseudorandom string with the decrypted private key portion...	Duo Push is alleged to use cryptography to communicate with the right device, which involves generating an approved challenge message by signing a string with the private key (Ex. D, p. 84).	¶32	col. 6:27-34
the web browser re-directing to a respective call-back Internet address of... another respective web page belonging to the respective Internet service provider...	After a successful Duo authentication, the user's browser is allegedly redirected from the duosecurity.com page back to the original internet service provider's webpage (e.g., University at Buffalo) (Ex. D, pp. 92-97).	¶32	col. 6:40-49

• Identified Points of Contention:
  • Scope Question: A central point of dispute may be whether the "Duo Mobile App" constitutes the "single identity provider application residing on the computing device" as required by the claim. A party might argue that significant parts of the claimed application's logic are performed by Duo's backend cloud servers, not an application fully "residing" on the device.
  • Technical Question: The infringement case may turn on whether the accused Duo login flow performs the exact, multi-step sequence of web browser redirections, API calls, and page displays outlined in claim 14, particularly elements [e] and [h]. The complaint provides a visual diagram from a Duo blog post showing the registration of a security key, which illustrates the public key being sent to and saved by the Duo remote server, supporting the allegation for element [c.iii] (Ex. D, p. 34).

'715 Patent Infringement Allegations

Claim Element (from Independent Claim 11)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
an identity provider application of a single identity provider residing on the computing device:	The Duo Mobile app is alleged to operate as an identity provider application residing on a mobile computing device (Ex. E, p. 11).	¶36	col. 3:9-12
creating an authentication token comprising a public key portion and a private key portion, wherein the created authentication token is specific to the single identity provider application;	Duo Push authentication is alleged to use cryptographic signing with an asymmetric key pair (public and private key) that is generated during account activation (Ex. E, p. 16).	¶36	col. 3:13-18
storing the private key portion of the created authentication token in a memory of the computing device; and	The private key is allegedly stored on the user's mobile device in a tamper-proof secure element, such as the iOS Secure Enclave (Ex. E, p. 17).	¶36	col. 3:29-31
transmitting, via an application programming interface (API) call to a computer server of the single identity provider, only the public key portion...	The public key is allegedly transmitted to and stored on Duo's servers, as depicted in a diagram illustrating the registration of a security key (Ex. E, p. 19).	¶36	col. 3:32-37
in an out-of-band interaction... a web browser of the computing device receiving a selection of a link... and... transmitting an electronic signal indicative of an Internet user identifier to the computer server of the single identity provider;	A user selecting a service in a web browser is alleged to trigger an out-of-band authentication via a push notification to the mobile network. The complaint alleges the user's mobile device sends an authentication request (the "electronic signal") to the Duo server (Ex. E, pp. 20-21).	¶36	col. 3:38-48
in response to receiving an API call from the computer server... the single identity provider application: displaying a page to receive an Internet user input;	The Duo Mobile app allegedly receives an API call (the push notification) and displays a page prompting the user to "Approve" or "Deny" the login request (Ex. E, p. 31).	¶36	col. 3:49-53
validating a received Internet user input by attempting to decrypt the stored private key portion...; and	The Duo Mobile app allegedly validates the user's input (e.g., approving a push notification) by using the stored private key, which is protected by the device's credential (e.g., Face ID/Touch ID) (Ex. E, pp. 36-38).	¶36	col. 3:54-57
if the received input is validated, transmitting an approved authentication challenge message...; and	Upon validation, the Duo app on the mobile device allegedly transmits an approved authentication challenge message back to the Duo server (Ex. E, p. 46).	¶36	col. 3:58-62
in response to receiving another API call... authorizing access by the Internet user to the selected one of the plurality of Internet services by re-directing the web browser...	The complaint alleges that after the user approves the Duo Push request, the web browser is redirected to the selected internet service's webpage (Ex. E, pp. 55-56).	¶36	col. 3:63-4:3

• Identified Points of Contention:
  • Scope Question: The dispute may center on the meaning of "out-of-band interaction." The complaint alleges this is satisfied by the interaction between a web browser and a separate push notification to a mobile app. A party may argue that if both the browser and the app use the same data network (e.g., Wi-Fi), the interaction is not truly "out-of-band" as contemplated by the patent.
  • Technical Question: A key factual question is whether the user's mobile device, in an out-of-band interaction, transmits an "electronic signal indicative of an Internet user identifier" to the IDP server as required by element [e]. The complaint includes a flow diagram showing a user's mobile device sending an authentication request to a Duo server, which may be presented as evidence of this step (Ex. E, p. 21).

V. Key Claim Terms for Construction

U.S. Patent 9,813,400

• The Term: "single identity provider application residing on the computing device" (from Claim 14)
• Context and Importance: The location and nature of the "application" are central to the infringement analysis. The case may turn on whether the Duo Mobile app, which acts as a client for a larger cloud service, meets this limitation, or if the claim requires a more autonomous, self-contained application to be performing the core logic on the user's device.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification suggests the "dID App" can be a "mobile application designed to run on mobile operating systems" '400 Patent, col. 7:61-63, which a court could find supports the view that a client app on a smartphone falls within the term's scope.
  • Evidence for a Narrower Interpretation: The patent attributes a long and complex series of steps to this "application" (Claim 14, elements [b]-[g]). A party could argue that the accused Duo Mobile app offloads much of this processing to backend servers, meaning the complete "application" does not "reside" on the device as required. The patent's own flow diagrams show significant interaction with an "IDP Core" server, suggesting a distributed architecture '400 Patent, FIG. 7

U.S. Patent 10,348,715

• The Term: "out-of-band interaction" (from Claim 11)
• Context and Importance: This term is a critical limitation distinguishing the '715 patent from its parent. Its construction will determine whether a standard MFA push notification workflow, where a browser and a mobile app on the same device communicate over the internet, infringes.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim defines the interaction as one "with other than the single identity provider application" '715 Patent, col. 3:38-40 Plaintiff may argue this means any channel separate from the on-device application itself, such as a web browser, qualifies.
  • Evidence for a Narrower Interpretation: The patent's background discusses vulnerabilities in "short messaging service (SMS)" as a distinct channel, which may suggest that "out-of-band" was intended to mean a separate communication network (e.g., cellular network vs. internet) rather than merely a separate application on the same device using the same network connection '715 Patent, col. 2:13-16

VI. Other Allegations

• Indirect Infringement: The complaint alleges that Cisco actively induced infringement by its customers Compl. ¶¶27-28 This allegation is supported by the inclusion of screenshots from Cisco's public-facing documentation and user guides, which allegedly instruct customers on how to use the accused Duo products in an infringing manner Ex. D, pp. 36-44
• Willful Infringement: The complaint alleges willful infringement based on knowledge "since at least the date of this Complaint" Compl. ¶¶27-28 This asserts post-suit knowledge as the basis for willfulness, as no facts alleging pre-suit knowledge of the patents are included.

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

• A core issue will be one of definitional scope: does the term "single identity provider application residing on the computing device" from the '400 patent require the majority of the authentication logic to be performed on the user's device, or can it be construed to read on a client application, like Duo Mobile, that works in concert with a larger cloud-based service?
• A second key issue will be the construction of "out-of-band interaction" in the '715 patent. The court will need to determine if a web browser login that is approved via a push notification to a mobile app on the same device-potentially using the same internet connection-satisfies this limitation as described in the patent's specification.
• A central evidentiary question will be one of operational mapping: does the accused Cisco Duo system, in practice, execute the specific, multi-step sequence of browser redirections, content displays, and API calls as minutely detailed in the asserted claims, or is there a fundamental mismatch in the technical sequence of operations?