DCT
2:24-cv-00800
BrowserKey, LLC v. Wells Fargo & Co.
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: BrowserKey, LLC (Texas)
- Defendant: Wells Fargo Bank, N.A. (Delaware)
- Plaintiff’s Counsel: Fabricant LLP; Truelove Law Firm, PLLC
- Case Identification: 2:24-cv-00800, E.D. Tex., 01/21/2025
- Venue Allegations: Plaintiff alleges venue is proper because Defendant is registered to do business in Texas, has committed acts of infringement in the district, and maintains regular and established places of business in the Eastern District of Texas.
- Core Dispute: Plaintiff alleges that Defendant’s web and mobile banking applications, which use session-based and biometric authentication, infringe a patent related to methods for securely restricting access to data on a server.
- Technical Context: The technology concerns client-server authentication, a foundational element of internet security for applications like online banking, where verifying a user's identity and the integrity of their device is critical.
- Key Procedural History: No prior litigation, Inter Partes Review (IPR) proceedings, or licensing history is mentioned in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2002-05-06 | '262 Patent Priority Date |
| 2007-07-24 | '262 Patent Issue Date |
| 2018 (at least) | Accused Products Allegedly Began Infringing |
| 2025-01-21 | 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 describes the security risks of traditional username/password systems, which can be easily shared or stolen, and the inconvenience of hardware-based solutions like "dongles," which can be lost or require physical access to a user's computer (’262 Patent, col. 1:30-56).
- The Patented Solution: The invention proposes a software-based authentication method that ties access to a specific, pre-authorized client machine. It involves installing a client-side program that generates a unique "machine-specific identifier" based on the client's hardware characteristics. This identifier is used to generate a corresponding password. To gain access, the client machine re-generates the identifier to verify it matches the password, confirming the authorized machine is being used. The system also describes using a "session identifier" to maintain an authenticated state during a browsing session without repeated verification (’262 Patent, Abstract; col. 2:25-45).
- Technical Importance: This approach sought to create a more secure authentication method than simple passwords by binding the session to a particular device, a concept that predates modern "passwordless" and device-bound biometric authentication schemes.
Key Claims at a Glance
- The complaint asserts independent claims 11 and 14 (Compl. ¶¶17, 27).
- Independent Claim 11 (Method): Essential elements include:
- Creating a session identifier in a computer remote from the client machine.
- Transmitting the session identifier to the client machine.
- Storing the session identifier within the client machine.
- Verifying, on the client machine, that the client machine is authorized to access data.
- Obtaining the stored session identifier and storing it in a remote storage table if the client machine was verified.
- Transmitting a data access request from the client, including the session identifier.
- Comparing the transmitted session identifier with the one stored in the remote table to authorize the request.
- Permitting or denying access based on the comparison.
- Independent Claim 14 (Computer Program Product): Essential elements include instructions for a method comprising:
- Receiving a request from a client machine for access to data.
- Generating a password remote from the client machine, where the password is derived from a client machine-specific identifier.
- Transmitting instructions to the client machine to re-generate the password and verify that the client machine-specific identifier uniquely corresponds with the generated password.
- Allowing or denying access based on whether the verification is true.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
The "Accused Products" are identified as "all versions and variants of the Wells Fargo Web and Mobile Applications," including the "Wells Fargo Mobile (a.k.a. Wells Fargo App) and Wells Fargo Vantage applications for iOS and Android, including all supporting servers, computer systems, and infrastructures, since at least 2018" (Compl. ¶12).
Functionality and Market Context
The complaint focuses on the authentication functionalities of the Accused Products, particularly those that support "biometric, token-based, and/or passwordless authentication" (Compl. ¶12). It alleges that when a user logs into the mobile app, Wells Fargo's servers create and transmit session identifiers (e.g., tokens, certificates) to the client device (Compl. ¶¶19-20). It further alleges that the app uses on-device features like Apple's Touch ID and Face ID to locally verify a user is authorized before accessing account data (Compl. ¶¶18, 22). The complaint provides a screenshot of the Wells Fargo app's Face ID login prompt to illustrate this local verification process (Compl. p. 11).
IV. Analysis of Infringement Allegations
'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... | Wells Fargo server computers allegedly create one or more session identifiers (e.g., static or dynamic session ID, token, certificate) when a user agent on a client machine initiates a request. | ¶19 | col. 13:40-43 |
| b. transmitting to the client machine the session identifier... | The Wells Fargo servers allegedly transmit the session identifier(s) to the client machine via the internet, using HTTP response headers or bodies. | ¶20 | col. 13:44-45 |
| c. storing the session identifier transmitted in step b. within the client machine; | The Wells Fargo Mobile App allegedly stores the session identifier on the client device in secure memory associated with the application, per instructions from the server. | ¶21 | col. 13:46-48 |
| d. verifying, on the client machine, that the client machine is authorized to access data... | The Wells Fargo Mobile App on iOS allegedly verifies authorization by using Apple's Touch ID or Face ID to authenticate the user locally on the device. The complaint includes a screenshot of the Face ID prompt (Compl. p. 11). | ¶22 | col. 13:49-51 |
| e. obtaining the session identifier...and storing such session identifier within a storage table remote from the client machine... | Once the user is authenticated via biometrics, the Wells Fargo server system allegedly obtains the session identifier from the mobile app client and stores it in a remote table associated with the server. A screenshot of a "Sign-on history" is provided as demonstrating the use of a storage table (Compl. p. 12). | ¶23 | col. 13:52-55 |
| f. transmitting a request by the client machine for access to data...such request including the session identifier... | Upon successful sign-in, the app allegedly transmits HTTP requests for account data, and these requests include the session identifier to overcome the stateless nature of the protocol. | ¶24 | col. 13:56-59 |
| g. comparing the session identifier transmitted in step f. with the session identifier stored in the storage table... | Wells Fargo servers allegedly compare the session identifier transmitted by the mobile app with the corresponding identifier stored in the remote storage table to determine if the request is authorized. | ¶25 | col. 13:60-64 |
| h. permitting access...if the comparison...shows that the request for access is authorized, and denying access...if not authorized. | Wells Fargo servers allegedly permit access to account data if the comparison is successful and deny access if it is not (e.g., if session cookies are rejected or the user's log-in fails). | ¶26 | col. 13:65-14:4 |
'262 Patent Infringement Allegations (Claim 14)
| Claim Element (from Independent Claim 14) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a. receiving a request from a client machine for access to data stored on a server; | Wells Fargo servers allegedly receive HTTP requests for a protected URL from a client machine running the mobile app when the application is launched. A screenshot showing network requests to multiple hosts is provided (Compl. p. 16). | ¶29 | col. 14:18-20 |
| b. generating a password remote from the client machine...the password being derived from...a client machine-specific identifier... | Wells Fargo servers allegedly generate a "password" (defined as a nonce, key, token, or other cryptographic material) derived from a client machine-specific identifier (e.g., a device key protected by the device's secure element). | ¶30 | col. 14:21-27 |
| c. transmitting to the client machine instructions to re-generate the password and to verify, on the client machine, whether the client machine-specific identifier uniquely corresponds with the password... | Wells Fargo servers allegedly transmit instructions for the app to use a seed value and algorithm to re-generate a matching password/key, and to verify on the client that it corresponds to the one from the server, for example by using biometric authentication to unlock a secure-element-protected key. | ¶31 | col. 14:28-34 |
| d. allowing access to the data if the verification...is true, and denying access...if the verification...is false. | Access to account data on Wells Fargo servers is allegedly authorized if the on-device sign-in is successful and denied if it is not. | ¶32 | col. 14:35-38 |
Identified Points of Contention
- Scope Questions: A central issue may be whether the term "password," as used in the patent, can be construed to read on the modern cryptographic materials (e.g., tokens, nonces, public keys) that the complaint alleges are used in the accused system (Compl. ¶30). Similarly, the scope of "client machine-specific identifier" will be contested, particularly whether it reads on device keys stored in a secure enclave.
- Technical Questions: The complaint alleges that on-device biometric verification (e.g., Face ID) satisfies the limitation of "verifying, on the client machine, that the client machine is authorized" (Compl. ¶22). A potential point of dispute is whether authenticating a user is legally and technically equivalent to verifying the machine itself, as the patent specification appears to emphasize (’262 Patent, col. 2:33-36).
V. Key Claim Terms for Construction
The Term: "verifying, on the client machine, that the client machine is authorized" (Claim 11)
- Context and Importance: This term is critical because the plaintiff's theory relies on equating modern biometric user authentication with the claimed step of verifying the machine. The outcome of the infringement analysis for Claim 11 may hinge on whether this equation is accepted.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent's goal is to restrict access to authorized entities, and verifying the authorized user on the device could be argued as a way to achieve that goal, even if the user is a proxy for the machine's authorization status.
- Evidence for a Narrower Interpretation: The patent repeatedly emphasizes generating an identifier based on "particular characteristics of the particular computer" and its "hardware characteristics" (’262 Patent, col. 2:33-36, col. 10:63-66). This could support a narrower construction requiring verification of the machine's unique software/hardware signature, not just the identity of the person operating it.
The Term: "password" (Claim 14)
- Context and Importance: The complaint broadly defines "password" to include modern cryptographic objects like nonces, keys, and tokens (Compl. ¶30). Whether this interpretation holds will determine if the accused system's security architecture falls within the scope of Claim 14.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent uses the term in the context of a secret that corresponds to a machine identifier and is used for authentication, a functional role that could arguably be fulfilled by modern security tokens or keys.
- Evidence for a Narrower Interpretation: The specification describes a password being "provided to the user" and then entered by the user into the client-side software, which suggests a more traditional, user-managed secret (’262 Patent, col. 2:40-42, col. 10:51-53).
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement of infringement by Wells Fargo's customers, stating that Wells Fargo provides "instructions, documentation, and other information" (e.g., technical support, manuals, advertisements) that encourage end-users to use the Accused Products in an infringing manner (Compl. ¶34). It also alleges contributory infringement, claiming the accused components are material to the invention, not staple articles of commerce, and are especially adapted for infringing use (Compl. ¶35).
- Willful Infringement: The complaint alleges that Wells Fargo performed its infringing acts "with knowledge of the '262 Patent and with the intent, or willful blindness" that its acts would constitute infringement (Compl. ¶¶34, 35).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can patent terms from the early 2000s, such as "password" and "machine-specific identifier", be construed broadly enough to encompass the technologically distinct concepts of modern security tokens, cryptographic keys, and device identifiers stored in secure enclaves?
- A second key issue centers on the locus of verification: does the act of verifying a user’s biometric identity on a client device, as alleged in the complaint, satisfy the claim requirement of verifying that the client machine is authorized, or is there a fundamental distinction between user and machine authentication that places the accused system outside the claim's scope?
- An important evidentiary question will be one of technical mapping: what proof will be offered to show that the complex, multi-step interactions between the Wells Fargo app, its servers, and the device's operating system (e.g., iOS) perform the specific sequence of creating, transmitting, storing, and comparing session identifiers as recited in Claim 11?