Factor2 Multimedia Systems LLC v. CFG Bank

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Factor2 Multimedia Systems, LLC (Virginia)
  • Defendant: CFG Bank (Maryland)
  • Plaintiff’s Counsel: DNL Zito
• Case Identification: 1:25-cv-01428, D. Md., 05/03/2025
• Venue Allegations: Venue is alleged to be proper in the District of Maryland because Defendant CFG Bank maintains a regular and established place of business in the district and has allegedly committed acts of infringement there.
• Core Dispute: Plaintiff alleges that Defendant’s online banking platform, which utilizes two-factor authentication, infringes six patents related to systems and methods for user authentication via dynamically generated secure codes.
• Technical Context: The patents address methods of enhancing online security by replacing or supplementing static, knowledge-based credentials (like passwords) with dynamic, single-use codes issued by a trusted or centralized entity.
• Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patents-in-suit.

Case Timeline

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

U.S. Patent No. 8,281,129 - “Direct Authentication System And Method Via Trusted Authenticators”

• Issued: October 2, 2012.

The Invention Explained

• Problem Addressed: The patent’s background section describes the growing problem of online fraud and identity theft, which stems from the reliance on easily compromised personal information (like SSNs) for authentication (’129 Patent, col. 1:13-2:46). Traditional authentication methods are flawed because they assume sensitive information can be kept secret, which is often not the case (’129 Patent, col. 2:1-5).
• The Patented Solution: The invention proposes a two-factor authentication system where an individual transacting with an entity (e.g., a merchant) is authenticated via a "trusted-authenticator" (e.g., the individual's bank). The individual requests a "dynamic key" from their trusted-authenticator, provides it along with a "static key" (like a username) to the entity, and the entity then contacts the trusted-authenticator to verify both keys (’129 Patent, col. 7:4-21; Fig. 2a). This process leverages existing trusted relationships to secure transactions with new or untrusted entities.
• Technical Importance: This approach sought to create a decentralized security framework that could be layered on top of existing financial relationships, avoiding the need for a single, new government-managed identity system (’129 Patent, col. 4:25-52).

Key Claims at a Glance

• The complaint asserts claims 1-52, with a focus on independent method claim 1 (Compl. ¶¶20, 30).
• Claim 1 of the ’129 Patent includes the following essential elements:
  • A computer-implemented method to authenticate an individual in communication with an entity.
  • Receiving electronically a request for a dynamic code for the individual, where the request is received from the individual by a "trusted-authenticators computer."
  • Calculating, by the trusted-authenticators computer, the dynamic code, which is valid for a predefined time and becomes invalid after use.
  • Sending the dynamic code electronically to the individual.
  • Receiving, by the trusted-authenticators computer, an authentication request from the entity based on user information and the dynamic code.
  • Authenticating the individual's identity based on the user information and the dynamic code, and providing the result to the entity.

U.S. Patent No. 10,769,297 - “Centralized Identification and Authentication System and Method”

• Issued: August 19, 2020.

The Invention Explained

• Problem Addressed: The patent addresses the security risks in e-commerce where users must release confidential personal and financial information to multiple businesses, creating numerous points of potential failure (’297 Patent, col. 1:40-54). The patent notes a need for a system that provides a secure "digital identity" to prevent this widespread data distribution.
• The Patented Solution: The invention describes a centralized system where a "Central-Entity" (e.g., a bank or credit card issuer) manages a user's identity. When a user wants to transact with an "External-Entity" (e.g., a merchant), the user requests a "SecureCode" from the Central-Entity. This code is dynamic, time-dependent, and non-predictable. The user provides this SecureCode, along with a username, to the External-Entity, which then forwards the information to the Central-Entity for validation before completing the transaction (’297 Patent, col. 3:1-40; Fig. 2).
• Technical Importance: This centralized model aims to enhance security by ensuring that sensitive user data remains with a single trusted entity, while transactions with various external parties are verified using temporary, disposable codes (’297 Patent, col. 3:1-10).

Key Claims at a Glance

• The complaint asserts claims 1-29, with a detailed infringement analysis of independent system claim 1 (Compl. ¶¶19, 25, 50).
• Claim 1 of the ’297 Patent includes the following essential elements:
  • An authentication system for enhancing security between a user's computing device and an "online computer system."
  • Electronically receiving a request for a "SecureCode."
  • Generating the SecureCode.
  • Electronically providing the SecureCode to the user.
  • The SecureCode is invalid after a predetermined time, after one use, and is only valid for authenticating that specific user.
  • Electronically receiving a "digital authentication request" from the online computer system, which includes a "digital identity" of the user comprising the SecureCode.
  • Authenticating the user by evaluating the validity of the SecureCode in the request.
• The complaint notes that this claim is an example and is not representative of all claims in the ’297 Patent (Compl. ¶19).

U.S. Patent No. 9,703,938 - “Direct Authentication System and Method Via Trusted Authenticators”

• Issued: July 11, 2017.
• Technology Synopsis: This patent, a continuation of the application leading to the ’129 Patent, describes a similar two-factor authentication method. The system relies on a "trusted authenticator" to issue a time-limited, single-use dynamic code to a user for verification by a third-party entity (’938 Patent, Abstract).
• Asserted Claims: Claims 1-26 (Compl. ¶34). The complaint does not identify a specific independent claim.
• Accused Features: The accused features are CFG Bank's general software, hardware, and authentication processes (Compl. ¶3).

U.S. Patent No. 9,727,864 - “Centralized Identification and Authentication System and Method”

• Issued: July 19, 2017.
• Technology Synopsis: This patent, the parent of the ’297 Patent, describes a centralized authentication system. A "Central-Entity" creates a "digital identity" for a user, comprising a username and a dynamic, non-predictable "SecureCode," which the user provides to an "External-Entity" for verification (’864 Patent, Abstract).
• Asserted Claims: Claims 1-15 (Compl. ¶38). The complaint does not identify a specific independent claim.
• Accused Features: The accused features are CFG Bank's general software, hardware, and authentication processes (Compl. ¶3).

U.S. Patent No. 9,870,453 - “Direct Authentication System and Method Via Trusted Authenticators”

• Issued: December 27, 2017.
• Technology Synopsis: This patent is part of the same family as the ’129 and ’938 patents and describes a similar two-factor authentication method using a "trusted authenticator" to issue and verify dynamic codes for transactions (’453 Patent, Abstract).
• Asserted Claims: Claims 1-26 (Compl. ¶42). The complaint does not identify a specific independent claim.
• Accused Features: The accused features are CFG Bank's general software, hardware, and authentication processes (Compl. ¶3).

U.S. Patent No. 10,083,285 - “Direct Authentication System and Method Via Trusted Authenticators”

• Issued: September 5, 2018.
• Technology Synopsis: Another patent in the ’129 family, this patent also describes a two-factor authentication method. The system leverages a "trusted authenticator" to provide a dynamic key to an individual for use in authenticating their identity with a separate business entity (’285 Patent, Abstract).
• Asserted Claims: Claims 1-30 (Compl. ¶46). The complaint does not identify a specific independent claim.
• Accused Features: The accused features are CFG Bank's general software, hardware, and authentication processes (Compl. ¶3).

III. The Accused Instrumentality

• Product Identification: The "CFG Bank System and Apparatus," which includes the CFG Bank website and the associated "back end systems and backbone" that provide access, distribute content, and authenticate users (Compl. ¶21).
• Functionality and Market Context:
  • The complaint alleges that the accused instrumentality provides online banking services that require user authentication (Compl. ¶25, p. 8). To enhance security, the system employs a two-factor (or multi-factor) authentication process. When a user attempts to log in, they are given the option to receive a "SecureCode," referred to by CFG Bank as a "one-time code," via SMS text or other electronic methods (Compl. ¶25, p. 8). The user must then enter this code to complete the login process. The complaint includes a screenshot showing the user interface for selecting the delivery method for this code (Compl., p. 8). The system allegedly generates a code that is valid for only a short period of time and for a single use (Compl. ¶25, p. 10). A promotional screenshot describes this as "One-time, perishable passcode generation" (Compl., p. 10). The complaint alleges that this entire system for generating and verifying temporary codes infringes the patents-in-suit (Compl. ¶24).

IV. Analysis of Infringement Allegations

’129 Patent Infringement Allegations

’297 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions:
  • Do the patents' terms "trusted-authenticator" (’129 Patent) and "Central-Entity" (’297 Patent) read on a single, integrated system like CFG Bank's, where the entity authenticating the user is the same entity issuing the dynamic code? The patent figures often depict three distinct parties (user, business, authenticator), which may raise the question of whether a two-party interaction falls within the claims' scope.
  • Does the term "digital identity" as used in the ’297 Patent, which comprises a "SecureCode," cover the combination of a username and a "one-time code" as alleged?
• Technical Questions:
  • What is the specific architecture of the CFG Bank back-end system? The complaint alleges infringement by both a "built in or separate system" (Compl. ¶3), suggesting uncertainty about whether the code generation and verification functions are performed by the same or different components, a distinction that could be relevant to claim construction and infringement.

V. Key Claim Terms for Construction

• The Term: "trusted-authenticators computer" (’129 Patent, Claim 1)

• Context and Importance: This term is central to the architecture of the claimed method. The dispute may turn on whether CFG Bank, in its role as the entity with which the user is interacting, can also be the "trusted-authenticator" as that term is used in the patent, or if the claim requires a separate, third-party entity. Practitioners may focus on this term because the patent's specification repeatedly describes a three-party system (individual, business, and trusted-authenticator) to solve the problem of authenticating a user to an entity with which the user does not have a pre-existing trusted relationship.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The claim language does not explicitly forbid the "entity" and the "trusted-authenticator" from being the same. Claim 1 requires the "entity" to receive the code from the individual and send a request to the "trusted-authenticator's computer," which could arguably describe internal communications within a single organization's system.
  • Evidence for a Narrower Interpretation: The specification describes a trusted-authenticator as "an entity that already knows the individual... A reasonable candidate for such a trusted-authenticator would be a bank or other financial institution with whom the individual has already established a relationship" (’129 Patent, col. 4:5-10). The problem solved by the patent is authenticating a user to an entity where no such relationship exists, suggesting the trusted-authenticator is necessarily a separate party from the entity requiring authentication.

• The Term: "SecureCode" (’297 Patent, Claim 1)

• Context and Importance: The definition and properties of the "SecureCode" are recited throughout Claim 1. The infringement analysis depends on mapping CFG Bank's "one-time code" to this term and all its associated limitations (e.g., single-use, time-limited, valid only for the user).

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The specification defines "SecureCode" broadly as "any dynamic, non-predictable and time dependent alphanumeric code, secret code, PIN or other code" (’297 Patent, col. 2:48-52). This broad definition could support the Plaintiff's position that CFG's "one-time code" meets the definition.
  • Evidence for a Narrower Interpretation: The claim requires the SecureCode to be invalid after "one use... for authentication." A defendant could argue that if a user enters the code incorrectly, that attempt does not consume its "one use" for authentication, potentially creating a distinction between an "attempt" and a "use for authentication" that could narrow the claim's scope.

VI. Other Allegations

• Indirect Infringement: The complaint does not contain specific counts for indirect infringement (induced or contributory).
• Willful Infringement: The complaint does not contain a specific count for willful infringement. However, the Prayer for Relief requests a judgment declaring the case "exceptional" and awarding "enhanced damages" (Compl., Prayer for Relief ¶¶C, E), which are remedies contingent upon a finding of willful or egregious conduct. The factual basis for such a finding is not detailed in the complaint.

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

• A core issue will be one of architectural scope: Can the claims, which often describe a three-party system (user, transacting entity, authenticator), be construed to cover the two-party scenario alleged, where the transacting entity (CFG Bank) also acts as its own authenticator? The answer will likely depend on how the court construes terms like "trusted-authenticator" and "Central-Entity" in the context of the problems the patents purport to solve.
• A second key question will be one of claim limitation mapping: Does the accused CFG Bank system meet every specific limitation recited in the claims, particularly the multiple invalidity conditions for the "SecureCode" in the ’297 Patent (invalid after time passes, invalid after one use, valid only for that user)? The case may require a detailed technical analysis of how the accused system generates, validates, and expires its "one-time codes."