Synchrofi LLC v. Gandi SAS

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: SynchroFi LLC (New Mexico)
  • Defendant: Gandi SAS (France)
  • Plaintiff’s Counsel: Rabicoff Law LLC
• Case Identification: 2:25-cv-01055, E.D. Tex., 10/21/2025
• Venue Allegations: Plaintiff asserts venue is proper because the Defendant is a foreign corporation and has allegedly committed acts of patent infringement in the district.
• Core Dispute: Plaintiff alleges that Defendant infringes a patent related to methods for single-use password authentication.
• Technical Context: The patent addresses secure user authentication for online services, a foundational component of e-commerce and digital security, by using a three-party system to issue and validate one-time passwords.
• Key Procedural History: The complaint does not mention any prior litigation, licensing history, or post-grant proceedings involving the patent-in-suit.

Case Timeline

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

U.S. Patent No. 7,613,919 - "Single-use password authentication"

• Patent Identification: U.S. Patent No. 7,613,919, "Single-use password authentication," issued November 3, 2009 (’919 Patent).

The Invention Explained

• Problem Addressed: The patent's background describes the security risks of traditional static passwords, such as susceptibility to eavesdropping and brute-force attacks, and the practical difficulties of using more complex methods like public key infrastructure (PKI) on mobile or public devices (’919 Patent, col. 1:21-2:22). It notes that while one-time passwords offer high security, they have traditionally been burdensome and required pre-existing trust relationships between all parties, limiting widespread adoption (’919 Patent, col. 2:38-48).
• The Patented Solution: The invention proposes a system involving three distinct entities: a "client" (the user), a "service provider" (the website or service the user wants to access), and an "authentication service" (a trusted third party) (’919 Patent, Fig. 1A). To authenticate, the client first contacts the authentication service using a secret "client moniker" to obtain a one-time password. The client then presents this one-time password to the service provider. The service provider forwards the one-time password to the authentication service for validation. If valid, the authentication service sends a unique "authentication service identifier" back to the service provider, which confirms the client's identity and grants access (’919 Patent, Abstract; col. 3:28-4:2).
• Technical Importance: This architecture aims to facilitate strong, one-time authentication between arbitrary parties without requiring a pre-existing trust relationship between the client and the service provider, or requiring the service provider to manage user passwords directly (’919 Patent, col. 3:15-22).

Key Claims at a Glance

• The complaint asserts infringement of "one or more claims" of the ’919 Patent (Compl. ¶11). Independent claim 1 is a representative method claim.
• Essential elements of Independent Claim 1 include:
  • At an authentication service, generating an authentication service identifier for a client.
  • Receiving a client moniker from the client.
  • Sending a one-time password to the client for use with a service provider.
  • Receiving that one-time password from the service provider.
  • If the received password matches the sent password, sending the client's authentication service identifier to the service provider to authenticate the client.
• The complaint reserves the right to assert other claims, which may include dependent claims or other independent claims covering the system from the perspective of the client or the service provider (Compl. ¶11).

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products in its main body. It refers to "Exemplary Defendant Products" identified in charts incorporated by reference from an exhibit that was not attached to the publicly filed complaint (Compl. ¶11, ¶16).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the functionality or market context of the accused instrumentalities. It alleges in general terms that the accused products "practice the technology claimed by the '919 Patent" (Compl. ¶16). No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint alleges that the "Exemplary Defendant Products incorporated in these charts satisfy all elements of the Exemplary '919 Patent Claims" (Compl. ¶16). However, it incorporates these allegations by reference to claim charts in "Exhibit 2," which was not provided with the complaint (Compl. ¶17). As such, a detailed element-by-element analysis based on the complaint's factual allegations is not possible. The narrative infringement theory is that Defendant makes, uses, sells, or imports products that practice the patented method of single-use password authentication (Compl. ¶11).

• Identified Points of Contention: Based on the claim language and the general nature of authentication systems, the infringement analysis may raise several technical and legal questions for the court:
  • Architectural Questions: Does the accused system utilize three distinct and separate entities corresponding to the claimed "client," "service provider," and "authentication service," or are the functions of the service provider and authentication service combined in a single entity? The claimed separation of roles appears to be a key feature of the invention (’919 Patent, Fig. 1A).
  • Scope Questions: How does the accused system's user identifier correspond to the claimed "client moniker"? The patent suggests this is a user's secret "preferred 'password' known only to themselves" used as a proxy to obtain the one-time password, which may differ from a standard, non-secret username (’919 Patent, col. 3:32-35).
  • Technical Questions: Does the accused system, after validating a one-time password, return a token to the service provider that functions as the claimed "authentication service identifier"? The nature and purpose of any session token or identifier used in the accused system will be compared against this claim element.

V. Key Claim Terms for Construction

• The Term: "client moniker"

• Context and Importance: This term is central to how the user initiates the authentication process. Its construction will determine whether the claim reads on systems using standard usernames or is limited to systems where the user provides a more specific, secret proxy password to the authentication service. Practitioners may focus on this term because the distinction between a public username and a private proxy password could be a dispositive issue for infringement.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent states the moniker is "analogous to a username" and "identifies the client to the authentication service" (’919 Patent, col. 8:6-7), which could support a construction covering any user identifier.
  • Evidence for a Narrower Interpretation: The specification also describes the moniker as "ideally the client's everyday preferred 'password' known only to themselves" and a "proxy password used to obtain a one-time password" (’919 Patent, col. 3:32-37). This language suggests the moniker is itself a secret, distinct from a typical, non-confidential username.

• The Term: "authentication service identifier"

• Context and Importance: This identifier is the final output of the claimed method, provided by the authentication service to the service provider to complete the authentication loop. The case may turn on whether a standard session cookie or other token in the accused system meets the specific description and function of this claimed identifier.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent describes the identifier in general terms, stating it "generally takes the form of an arbitrary number of characters" and that "Any suitable identifier may be used" (’919 Patent, col. 3:41-43). This could support a broad reading on various types of tokens.
  • Evidence for a Narrower Interpretation: The specification provides specific examples, such as a "globally unique identifier (GUID)" (’919 Patent, col. 8:23). Furthermore, its role is to be "matched to a previously received authentication service identifier... at the authenticating entity or service provider" (’919 Patent, col. 5:50-54), suggesting a function tied to a specific registration or stored value, which might be narrower than a temporary session token.

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement of infringement "at least since being served by this Complaint," based on Defendant allegedly distributing "product literature and website materials inducing end users... to use its products in the customary and intended manner that infringes" (’919 Patent, Compl. ¶14-15). The complaint states that these materials are referenced in the unattached Exhibit 2 (Compl. ¶14).
• Willful Infringement: The complaint does not use the term "willful." However, it alleges "Actual Knowledge of Infringement" arising from the service of the complaint and its attached (but not provided) claim charts (Compl. ¶13). This allegation forms a basis for potential enhanced damages for any post-filing infringement. The prayer for relief seeks damages for "continuing or future infringement" (Compl., Prayer for Relief ¶D).

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

This dispute will likely focus on the specific architecture of the accused systems compared to the three-party framework recited in the patent’s claims. The central questions for the court appear to be:

• A core issue will be one of architectural correspondence: Does the accused authentication system map onto the distinct three-entity structure (client, service provider, authentication service) claimed in the ’919 Patent, or are the functions of the "service provider" and "authentication service" integrated in a way that falls outside the claim scope?
• A second key issue will be one of definitional scope: Can the term "client moniker", described in the patent as a "proxy password," be construed to cover a standard username? Similarly, does the "authentication service identifier" limitation read on the type of session tokens or identifiers used in the accused system, or does it require a more specific form of registered identifier?