Factor2 Multimedia Systems LLC v. BROADWAY Bancshares Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Factor 2 Multimedia Systems, LLC (Virginia)
  • Defendant: Broadway Bancshares, Inc. dba Broadway National Bank (Texas)
  • Plaintiff’s Counsel: DNL Zito
• Case Identification: 1:25-cv-00239, W.D. Tex., 02/19/2025
• Venue Allegations: Plaintiff alleges venue is proper because Defendant maintains a regular and established place of business within the district and has committed the alleged acts of infringement there.
• Core Dispute: Plaintiff alleges that Defendant’s digital banking platform infringes six patents related to systems and methods for user authentication using dynamic, single-use codes generated by a trusted or centralized entity.
• Technical Context: The technology concerns two-factor authentication designed to enhance security for online interactions, a foundational component of modern digital finance and e-commerce.
• Key Procedural History: The complaint notes that all six patents-in-suit are members of the same patent family. No other significant procedural events, such as prior litigation or administrative proceedings involving these patents, are mentioned in the complaint.

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 addresses the vulnerability of authentication systems that rely on static personal or financial information (e.g., Social Security Numbers), which can be stolen and used for fraud and identity theft (ʼ129 Patent, col. 2:1-9).
• The Patented Solution: The invention proposes a "two-factor" authentication method where a user, when interacting with a "business," provides not only a static key (something they know) but also a dynamic key or "SecureCode" (something they receive). The user requests and receives this temporary code in real-time from a separate "trusted-authenticator," such as their bank, with whom they have a pre-existing trusted relationship. The business then communicates with the trusted-authenticator to validate both keys before completing the transaction (ʼ129 Patent, Abstract; col. 7:1-15; Fig. 2a).
• Technical Importance: This architecture was designed to mitigate risks from compromised static credentials by introducing a dynamic, single-use element brokered by an entity with an established trust relationship, thereby enhancing security for online transactions (ʼ129 Patent, col. 6:45-54).

Key Claims at a Glance

• The complaint asserts at least claims 1-52 (Compl. ¶32) and explicitly recites independent claim 1 (Compl. ¶21).
• Claim 1 (Method) recites the essential elements:
  • Receiving, at a trusted-authenticator's computer, a request from an individual for a dynamic code during an authentication by an entity.
  • Calculating the dynamic code, which is valid for a predefined time and becomes invalid after being used.
  • Sending the dynamic code to the individual.
  • Receiving, at the trusted-authenticator's 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 dynamic code, and providing the result to the entity.

U.S. Patent No. 9,703,938 - "Direct Authentication System and Method Via Trusted Authenticators", Issued July 11, 2017

The Invention Explained

• Problem Addressed: The patent addresses the fundamental flaws in authentication processes that depend on keeping personal information secret, which is described as an "impossible task" in the face of widespread data availability (ʼ938 Patent, col. 3:1-4).
• The Patented Solution: As a continuation of the ʼ129 Patent, this patent further details a method where a trusted authentication system facilitates secure transactions. The system receives a request for a dynamic code, generates a time-limited and single-use code, provides it to the user, and then receives and processes an authentication request from a separate computer system that includes the user-provided code (ʼ938 Patent, Abstract; col. 13:1-39).
• Technical Importance: The invention provides a more detailed claim structure for the process flow, focusing on the distinct roles and communications between the user, the transacting computer system, and the trusted authentication system during an electronic transaction (ʼ938 Patent, col. 9:18-40).

Key Claims at a Glance

• The complaint asserts at least claims 1-26 (Compl. ¶36). Independent claims are 1 and 16.
• Claim 1 (Method) recites the essential elements:
  • Receiving, at a trusted authentication system, an electronic request for a dynamic code for a user during a transaction with a separate computer system.
  • Generating a dynamic code that is valid for a pre-determined time and becomes invalid after use.
  • Providing the dynamic code to the user.
  • Receiving an authentication request from the computer system, based on a digital identity that includes user information and the dynamic code.
  • Authenticating the user based on the digital identity and providing the result to the computer system.

U.S. Patent No. 9,727,864 - "Centralized Identification and Authentication System and Method", Issued July 19, 2017 (Multi-Patent Capsule)

• Technology Synopsis: This patent describes a system centered around a "Central-Entity" that manages user credentials and generates dynamic, time-dependent "SecureCodes." A user registers with the Central-Entity, and when transacting with a separate "External-Entity," requests a SecureCode from the Central-Entity and provides it to the External-Entity, which then contacts the Central-Entity for verification (ʼ864 Patent, Abstract; col. 2:14-31).
• Asserted Claims: At least claims 1-15 (Compl. ¶40).
• Accused Features: The authentication methods of the "Broadway System" (Compl. ¶12, ¶40).

U.S. Patent No. 9,870,453 - "Direct Authentication System and Method Via Trusted Authenticators", Issued December 27, 2017 (Multi-Patent Capsule)

• Technology Synopsis: Continuing from the ʼ129 patent family, this patent claims an authentication method where an online system receives user-authentication information including a "SecureCode." The method involves the online system sending a request to a separate authentication system to verify the SecureCode, which is configured to be invalid after a first use or a predetermined time (ʼ453 Patent, Abstract; col. 13:1-51).
• Asserted Claims: At least claims 1-26 (Compl. ¶44).
• Accused Features: The authentication methods of the "Broadway System" (Compl. ¶12, ¶44).

U.S. Patent No. 10,083,285 - "Direct Authentication System and Method Via Trusted Authenticators", Issued September 5, 2018 (Multi-Patent Capsule)

• Technology Synopsis: This patent claims a method where an online system receives a user-authentication code, which was generated by a separate authentication system and is valid for a limited time and/or single use. The core of the claimed method is the online system's role in receiving the code and its properties, and then confirming the user's identity based on that information (ʼ285 Patent, Abstract; col. 13:12-61).
• Asserted Claims: At least claims 1-30 (Compl. ¶48).
• Accused Features: The authentication methods of the "Broadway System" (Compl. ¶12, ¶48).

U.S. Patent No. 10,769,297 - "Centralized Identification and Authentication System and Method", Issued August 19, 2020 (Multi-Patent Capsule)

• Technology Synopsis: This patent claims an authentication system comprising computing devices configured to perform the centralized authentication method. The system receives a request for a "SecureCode," generates it, provides it to the user, and later receives a digital authentication request containing the SecureCode from a third party, which it then validates (ʼ297 Patent, Abstract). Claim 1 is explicitly recited in the complaint (Compl. ¶20).
• Asserted Claims: At least claims 1-29 (Compl. ¶52).
• Accused Features: The authentication methods of the "Broadway System" (Compl. ¶12, ¶52).

III. The Accused Instrumentality

• Product Identification: The accused instrumentality is the "Broadway System" (Compl. ¶3).
• Functionality and Market Context: The Broadway System is alleged to encompass the Broadway Bank mobile application for iOS and Android, its public website, and the associated back-end systems that provide access, distribute content, and authenticate users (Compl. ¶22). The complaint asserts this system is an "integral part of its bussiness [sic] operations" (Compl. ¶22). The core accused function is the "system and method for authentication" used by this platform (Compl. ¶12). No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint does not provide a detailed, element-by-element mapping of the accused Broadway System to the asserted patent claims. It references an "exemplary claim chart" as Exhibit G, which allegedly demonstrates how the Broadway System infringes claim 1 of the ’297 Patent (Compl. ¶26). However, this exhibit was not filed with the complaint. For all other asserted patents, infringement is alleged in a conclusory manner without specific factual mappings in the body of the complaint (Compl. ¶¶ 32, 36, 40, 44, 48). Due to the lack of specific allegations or a provided claim chart, a tabular analysis is not possible based on the complaint alone.

• Identified Points of Contention:
  • Factual Question: The primary point of contention will be factual. The complaint provides no specific details on how the Broadway System's authentication technology operates. Discovery will be required to determine if the accused system in fact performs the steps claimed, such as generating a single-use, time-limited dynamic code in response to a user request during a transaction.
  • Scope Question: The patents from the "trusted-authenticator" branch of the family (e.g., the ’129 and ’938 Patents) describe an architecture involving at least two distinct parties: a "business" or "entity" and a separate "trusted-authenticator." This raises the question of whether an integrated system, where a single entity (Broadway Bank) authenticates its own users for its own services, can be mapped onto this multi-entity claim structure. The court may need to decide if the bank can simultaneously be both the "entity" and the "trusted-authenticator" under the patent's language.

V. Key Claim Terms for Construction

• The Term: "trusted-authenticator"

  • Context and Importance: This term is foundational to the architecture claimed in the ’129 and ’938 Patents. Its construction will be critical in determining whether the claims require two separate, independent commercial entities for infringement, or if the functions can be performed by different systems within a single enterprise.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification defines the term as "an entity that already knows the individual, maintains personal information about that individual, and has established a trusted relationship with that person," with a "bank or other financial institution" being a "reasonable candidate" (ʼ129 Patent, col. 4:5-10). Parties may argue this definition does not explicitly forbid the "entity" and "trusted-authenticator" from being the same.
    • Evidence for a Narrower Interpretation: The patent figures and descriptions consistently depict the "business" (20) and the "trusted-authenticator" (30) as distinct components that communicate with each other over a network (ʼ129 Patent, Fig. 2a-2b). The specification describes the process as the "business" sending "authentication messages... to the trusted-authenticator," which suggests they are separate operational entities (ʼ129 Patent, col. 7:10-13).

• The Term: "dynamic code" (and "SecureCode")

  • Context and Importance: The properties of this code are a central limitation. The infringement analysis will depend on whether the authentication code used by the Broadway System has the specific characteristics claimed, namely being "valid for a predefined time and becomes invalid after being used" (ʼ129 Patent, cl. 1).
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes the dynamic key as an "alphanumeric code" that "will have a different value each time the individual 10 receives it" (ʼ129 Patent, col. 8:17-19). This could be interpreted to cover various forms of one-time passwords (OTPs).
    • Evidence for a Narrower Interpretation: Claim 1 of the ʼ129 Patent requires "calculating... the dynamic code for the individual in response to the request." A defendant may argue this requires a code to be generated on-demand at the moment of the request, potentially excluding systems that rely on pre-generated lists of codes or continuously rolling codes (like some TOTP algorithms) that are not calculated in direct response to a specific user action.

VI. Other Allegations

• Indirect Infringement: The complaint makes a general allegation that Defendant indirectly infringes "when [the Broadway System is] used according to Defendant's instructions for operation" (Compl. ¶24). However, it does not provide any specific facts regarding the content of these alleged instructions.
• Willful Infringement: The complaint does not contain an explicit count for willful infringement or allege facts suggesting pre-suit knowledge of the patents. However, the prayer for relief includes a request for "enhanced damages under 35 U.S.C. § 284," the statute governing willful infringement (Compl., Prayer for Relief ¶E).

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

• A core issue will be one of architectural mapping: Can the multi-entity framework recited in several key patents—requiring communication between a transacting "entity" and a separate "trusted-authenticator"—be construed to cover an integrated digital banking platform where the bank authenticates its own users for its own services?
• A key evidentiary question will be one of technical implementation: As the complaint lacks technical specifics, the case will depend on evidence establishing how the Broadway System's authentication process actually functions. The analysis will focus on whether it generates and validates a "dynamic code" possessing the specific properties required by the claims, such as being single-use, time-limited, and generated in response to a user's request.