DCT
2:25-cv-00451
BrowserKey LLC v. First Citizens Bank & Trust Co
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: BrowserKey, LLC (Texas)
- Defendant: First Citizens Bank & Trust Company (North Carolina)
- Plaintiff’s Counsel: Fabricant LLP
- Case Identification: 2:25-cv-00451, E.D. Tex., 04/30/2025
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant has regular and established places of business in the district, including a physical bank branch located in Frisco, Texas.
- Core Dispute: Plaintiff alleges that Defendant’s mobile and web banking applications, which use features like biometric login, infringe a patent related to methods for securely restricting access to data on a server from a remote client machine.
- Technical Context: The technology concerns device-specific authentication methods designed to enhance security beyond traditional username/password systems, a critical function for sensitive applications like online banking.
- Key Procedural History: The complaint does not reference prior litigation or administrative proceedings involving the patent-in-suit. Plaintiff alleges that Defendant was willfully blind to its infringement, asserting that Defendant has a policy of not reviewing the patents of others.
Case Timeline
| Date | Event |
|---|---|
| 2002-05-06 | U.S. Patent No. 7,249,262 Priority Date |
| 2007-07-24 | U.S. Patent No. 7,249,262 Issue Date |
| c. 2019 | Alleged first infringement by Accused Products |
| 2025-04-30 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,249,262 - "Method For Restricting Access To A Web Site By Remote Users," issued July 24, 2007
The Invention Explained
- Problem Addressed: The patent’s background section identifies the security weaknesses of conventional authentication methods. It notes that user-name/password credentials can be easily stolen or shared, and that physical hardware tokens ("dongles") are inconvenient and can be lost, stolen, or loaned to unauthorized users (’262 Patent, col. 1:26-57).
- The Patented Solution: The invention proposes to tie access rights to a specific, authorized client machine rather than just a user's knowledge. This is achieved by installing client-side software that generates a "machine-specific identifier" based on the unique hardware characteristics of that machine. This identifier is then used to generate a corresponding password. To gain access, the client machine must re-generate its identifier and verify that it matches the password, thereby confirming that the request is originating from the authorized device (’262 Patent, Abstract; col. 2:25-45). The patent also describes a related method for managing authenticated sessions using session identifiers stored in a temporary table on a server (’262 Patent, col. 3:13-34).
- Technical Importance: This approach sought to provide stronger, possession-based security (the specific device) without the inconvenience of a separate physical token, binding authentication to the hardware of the client machine itself (’262 Patent, col. 2:1-4).
Key Claims at a Glance
- The complaint asserts independent claims 1, 11, and 14.
- Independent Claim 1 recites a method with the essential elements of:
- installing a client-side program on a client machine for generating a substantially unique machine-specific identifier.
- operating the program to generate the identifier.
- generating a password remote from the client, derived from that identifier.
- issuing a request for access from the client to a server.
- responding to the request by having the client machine re-generate its identifier.
- verifying on the client machine whether the re-generated identifier uniquely corresponds with the password.
- recognizing the client machine as authorized if the verification is true.
- Independent Claim 11 recites a different method focused on session management with the essential elements of:
- creating a session identifier on a remote computer.
- transmitting the session identifier to the client machine.
- storing the session identifier on the client machine.
- verifying on the client machine that it is authorized to access data.
- obtaining the stored session identifier and storing it in a remote storage table if the client is verified.
- transmitting a subsequent access request from the client that includes the stored session identifier.
- comparing the transmitted session identifier with the one in the remote storage table.
- permitting or denying access based on the outcome of the comparison.
III. The Accused Instrumentality
Product Identification
The accused instrumentalities are the "First Citizens Web and Mobile Applications," which include the "First Citizens Mobile Banking Application," "SVB Wealth Access," "First Citizens Wealth Access," and "First Citizens Commercial Advantage" for platforms such as iOS and Android, along with their supporting server infrastructure (Compl. ¶9).
Functionality and Market Context
The accused products provide customers with online and mobile access to their bank accounts (Compl. ¶8). The central accused functionality is the user authentication system, particularly the ability to "Log in with Face ID®, Touch ID® or secure passcode" to access secured data (Compl. ¶16; p. 7). The complaint includes a screenshot from the First Citizens Mobile Application that explicitly shows a prompt for authentication via "Face ID" to log in (Compl. p. 8). The complaint alleges that this biometric process authorizes the client machine to access restricted data, such as "protected URLs," on Defendant's servers (Compl. ¶16).
IV. Analysis of Infringement Allegations
’262 Patent Infringement Allegations (Claim 1)
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a. installing a client-side software program on the client machine for generating a client machine-specific identifier... | The First Citizens Mobile Application is installed on a user's phone and allegedly generates a unique identifier such as a "device key, certificate, [or] public/private key pair." | ¶17 | col. 12:15-20 |
| b. operating the client-side software program on the client machine to generate the client machine-specific identifier; | Upon launch, the First Citizens servers allegedly verify that the client application is configured to calculate a machine-specific identifier. | ¶18 | col. 12:21-23 |
| c. generating a password remote from the client machine and providing the password to a user... the password being derived from the client machine-specific identifier... | Defendant's servers allegedly generate a password (e.g., a token or cryptographic key) derived from the identifier and transmit it to the client application. | ¶19 | col. 12:24-29 |
| d. issuing a request by the client machine to the server computer for access to data... | The mobile application issues an HTTP request to access a "protected URL" associated with First Citizens when launched. | ¶20 | col. 12:30-32 |
| e. responding to the request for access... by having the client machine re-generate its machine-specific identifier; | Defendant's servers allegedly transmit instructions for the client to re-generate the password or a related identifier. | ¶21 | col. 12:33-35 |
| f. verifying on the client machine whether the client machine-specific identifier re-generated... uniquely corresponds with the password... | Using biometrics (e.g., Face ID), the client machine allegedly grants access to a secure-element protected password and verifies it matches a value from the server. A screenshot shows the Face ID login prompt. | ¶21; p. 8 | col. 12:36-39 |
| g. recognizing the client machine as being authorized... if the verification performed by step f. is true... | If the sign-in is successful on the client machine, access to data on Defendant's servers is authorized. | ¶22 | col. 12:40-44 |
’262 Patent Infringement Allegations (Claim 11)
| Claim Element (from Independent Claim 11) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a. creating a session identifier in a computer remote from the client machine for a current browsing session... | Defendant's servers allegedly create a session identifier (e.g., a token or dynamic session ID) upon successful access by a client device. | ¶25 | col. 13:40-42 |
| b. transmitting to the client machine the session identifier created in step a.; | The server allegedly transmits the session identifier to the client machine via HTTP response headers or bodies. | ¶26 | col. 13:43-44 |
| c. storing the session identifier transmitted in step b. within the client machine; | The client's browser or mobile application allegedly stores the session identifier in secure memory associated with the application. | ¶27 | col. 13:45-47 |
| d. verifying, on the client machine, that the client machine is authorized to access data... | The mobile application allegedly verifies authorization by locally authenticating a user's biometrics. The complaint provides a marketing image showing "Log in with Face ID®, Touch ID®". | ¶28; p. 13 | col. 13:48-50 |
| e. obtaining the session identifier... and storing such session identifier within a storage table remote from the client machine... | Defendant's server system allegedly obtains the session identifier from the mobile app and stores it in a server-side table within secure memory. | ¶29 | col. 13:51-54 |
| f. transmitting a request by the client machine for access to data... including the session identifier stored in step c.; | Subsequent HTTP requests from the mobile app allegedly include the session identifier to maintain the logged-in state. | ¶30 | col. 13:55-58 |
| g. comparing the session identifier transmitted... with the session identifier stored in the storage table... | Defendant's servers allegedly compare the identifier received in a request with the one stored in the remote table to determine if the session is valid. | ¶31 | col. 13:59-63 |
| h. permitting access... if the comparison... shows that the request for access is authorized... | If the comparison is successful (i.e., the user is logged in), access to account data is permitted; otherwise, it is denied. | ¶32 | col. 13:64-67 |
Identified Points of Contention
- Technical Questions: A primary question is whether the accused system, which leverages a modern mobile operating system's biometric and secure storage APIs (e.g., Apple's Face ID and Secure Enclave), performs the same steps as the claimed invention. For Claim 1, a key dispute may arise over whether the verification step actually occurs "on the client machine" as required, or if it is a distributed process that relies on a server-side check for final authorization.
- Scope Questions: The infringement analysis for Claim 1 will likely focus on whether a modern device attestation key or token, managed by the operating system, constitutes a "client machine-specific identifier" that is "generated" by the "client-side software program" (the bank's app) in the manner contemplated by the patent, which provides examples like "hard drive characteristics" and "RAM characteristics" (’262 Patent, col. 7:63-67).
V. Key Claim Terms for Construction
The Term: "client machine-specific identifier" (Claim 1)
- Context and Importance: This term is the foundation of the security method in Claim 1. Its construction will determine whether the cryptographic keys and tokens used in modern mobile authentication systems fall within the scope of the claim.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language requires only that the identifier be "substantially unique to the particular machine upon which such client-side software program is initially installed" (’262 Patent, col. 12:18-20). This could support a reading that covers any identifier tied to the specific hardware.
- Evidence for a Narrower Interpretation: The specification discloses that the identifier is generated by analyzing "hardware characteristics of a particular local computer, or client machine (including hard drive characteristics, RAM characteristics, input/output device parameters and other hardware specific details)" (’262 Patent, col. 7:63-67). Parties may argue this disclosure limits the term to identifiers derived from such general-purpose PC components, as opposed to specialized hardware like a secure enclave.
The Term: "verifying on the client machine" (Claim 1)
- Context and Importance: The location of this verification step is a specific limitation. If the legally operative verification is determined to occur on the server, infringement may be avoided. Practitioners may focus on this term because modern client-server authentication is often a coordinated process, and pinpointing the location of the final "verification" can be a dispositive issue.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent's detailed description notes that the comparison is "preferably by the client-side software itself" (’262 Patent, col. 2:61-63), which could suggest that other arrangements, perhaps involving the server, were contemplated as possibilities, even if not explicitly recited in this specific claim.
- Evidence for a Narrower Interpretation: The plain language of claim 1, step (f), recites "verifying on the client machine," which suggests the entire comparison and determination occurs locally. The patent's flowchart, FIG. 2B, depicts the decision block "Does password correspond to machine-specific ID?" (52) as occurring on the client-side of the diagram, separate from the server-side processes (’262 Patent, Fig. 2B).
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement, stating Defendant provides instructions and makes the Accused Products available, intending for customers to use them in an infringing manner (Compl. ¶40). It also alleges contributory infringement, asserting that the accused components are material to the invention, not staple articles of commerce, and are especially adapted for infringing use (Compl. ¶41).
- Willful Infringement: Willfulness is alleged based on Defendant having "knowingly and deliberately infringed" the patent (Compl. ¶42). The claim is further supported by allegations of willful blindness, where Plaintiff asserts that Defendant, as a bank, monitors security technology but maintains a practice of not reviewing patents, and thereby deliberately avoided knowledge of its infringement (Compl. ¶11).
VII. Analyst’s Conclusion: Key Questions for the Case
A core issue will be one of technical translation: can the authentication process described in the 2002-era patent, which centers on a client program generating an identifier from PC hardware traits, be read to cover a modern mobile app that uses an operating system's APIs to access a dedicated secure element and biometric sensors for authentication? The factual record of how the accused system actually operates will be critical.
The case will likely turn on a question of claim scope and location: will the term "client machine-specific identifier" be construed broadly enough to cover modern device keys, and will the "verifying" step of Claim 1 be found to occur "on the client machine" as required, or is the server's role in the final authorization decision sufficient to move the locus of verification off the client, thereby avoiding infringement?