DCT
2:25-cv-00443
BrowserKey LLC v. Capital One Services LLC
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: BrowserKey, LLC (Texas)
- Defendant: Capital One Services, LLC (Delaware)
- Plaintiff’s Counsel: Fabricant LLP; Truelove Law Firm, PLLC
- Case Identification: 2:25-cv-00443, E.D. Tex., 04/28/2025
- Venue Allegations: Plaintiff alleges venue is proper because Defendant is registered to do business in Texas, has committed alleged acts of infringement in the district, and maintains regular and established places of business in the district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile applications, which use biometric and passwordless authentication, infringe a patent related to methods for restricting access to a server by binding authentication to a specific client machine.
- Technical Context: The technology relates to client-server security, specifically methods for device-specific authentication to prevent unauthorized access from unapproved machines, a key security concern in online banking and remote access systems.
- Key Procedural History: The complaint does not mention any prior litigation, inter partes review (IPR) proceedings, or specific licensing history concerning the patent-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 2002-05-06 | ’262 Patent Priority Date |
| 2007-07-24 | ’262 Patent Issue Date |
| 2019-01-01 | Alleged Infringement Start Date (approx.) |
| 2025-04-28 | 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 addresses the security risks of traditional authentication methods like usernames and passwords, which can be easily shared or stolen, and the inconvenience of hardware-based solutions like "dongles," which can be lost or loaned to others ( Compl. Ex. A, ’262 Patent, col. 1:29-56). The goal was to create a security system that ties access rights to a specific, pre-authorized client machine.
- The Patented Solution: The invention proposes a method where a client-side software program generates a "machine-specific identifier" based on the unique hardware or software characteristics of that particular computer (’262 Patent, col. 2:32-36). This identifier is then used to generate a unique password. To gain access, the client machine must re-generate the identifier and verify that it corresponds to the password, thus proving it is the authorized machine (’262 Patent, col. 2:60-65). For subsequent access within the same session, a "session identifier" is used to avoid repeating the full authentication process for every request (’262 Patent, col. 3:12-44).
- Technical Importance: This approach provided a software-only method to bind a user's access to a particular device, increasing security beyond what a simple password could offer without requiring physical hardware tokens (’262 Patent, col. 2:7-12).
Key Claims at a Glance
- The complaint asserts independent claims 1, 11, and 14.
- Independent Claim 1 (Method):
- installing a client-side software program for generating a client machine-specific identifier
- operating the program to generate the identifier
- generating a password remote from the client machine, derived from the identifier
- issuing a request for access from the client to the server
- responding 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 as authorized if verification is true, and refusing if false
- Independent Claim 11 (Method):
- creating a session identifier on a remote computer for a client's browsing session
- 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
- obtaining and storing the session identifier in a remote storage table if the client was verified
- transmitting a request from the client including the session identifier
- comparing the transmitted session identifier with the stored identifier
- permitting or denying access based on the comparison
- Independent Claim 14 (Computer Program Product):
- A computer program product on an information carrier with instructions to perform a method comprising:
- receiving a request from a client for access to data
- generating a password remote from the client, derived from a client machine-specific identifier
- transmitting instructions to the client to re-generate the password and verify correspondence
- allowing or denying access based on the verification
III. The Accused Instrumentality
Product Identification
- The accused products are "all versions and variants of Capital One Mobile Applications since 2019, which have supported any biometric, token-based, and/or passwordless authentication" (Compl. ¶9). Specific examples include the Capital One Mobile App, CreditWise, Capital One Intellix mobile, and Capital One T&Easy for iOS, iPadOS, and Android (Compl. ¶9).
Functionality and Market Context
- The complaint alleges that the Accused Products implement security features that restrict access to user account data maintained on Capital One's servers (Compl. ¶16). A key accused feature is the ability for a user to sign in using biometric identifiers like Apple's Touch ID and Face ID (Compl. ¶16). The complaint includes a screenshot from the Capital One app prompting the user to "Sign in easily with your fingerprint," which illustrates the user-facing aspect of this functionality (Compl. p. 6). This biometric process is alleged to authorize the client machine to access restricted data on Capital One's servers (Compl. ¶16). Another screenshot from Capital One's website states these features include "a biometric sign-in setting that uses facial recognition or fingerprint recognition to verify your identity" (Compl. p. 12).
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 Capital One Mobile app is installed on a client device (e.g., a smartphone) and generates a unique identifier such as a device key or certificate. | ¶17 | col. 11:15-21 |
| c. generating a password remote from the client machine and providing the password to a user of the client machine, the password being derived from the client machine-specific identifier... | Capital One servers allegedly generate a "password (e.g., a nonce, token, cryptographic key...)" derived from the client-generated identifier and transmit it to the client app. | ¶19 | col. 12:25-33 |
| f. verifying on the client machine whether the client machine-specific identifier re-generated in step e. uniquely corresponds with the password generated in step c. | The complaint alleges this verification occurs when a user authenticates with biometrics (fingerprint, face), which grants access to a "secure element-protected password" and verifies it against a token transmitted by the server. | ¶21 | col. 12:56-65 |
| g. recognizing the client machine as being authorized... if the verification... is true, and refusing... if... false. | If the sign-in on the client machine is successful, access to data on Capital One's servers is authorized; otherwise, it is denied. | ¶22 | col. 12:56-g |
’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... | Capital One servers are alleged to create session identifiers (e.g., static or dynamic session ID, token) when a user session begins. | ¶25 | col. 9:40-45 |
| d. verifying, on the client machine, that the client machine is authorized to access data maintained on the server computer | The Capital One Mobile App allegedly verifies authorization by "locally authenticating an operator's biometric information." | ¶28 | col. 12:56-g |
| e. obtaining the session identifier stored in step c., and storing such session identifier within a storage table remote from the client machine if such client machine was verified... | After a user logs in with biometric authentication, the Capital One server system obtains the session identifier from the client and stores it in a remote table. | ¶29 | col. 10:29-44 |
| g. comparing the session identifier transmitted in step f. with the session identifier stored in the storage table... | Capital One servers are alleged to compare the session identifier transmitted with a request from the mobile app against the identifier stored in the remote table. | ¶31 | col. 10:45-54 |
- Identified Points of Contention:
- Scope Question: A primary issue may be whether a server-generated, non-user-facing "nonce, token, [or] cryptographic key" (Compl. ¶19) constitutes a "password" as the term is used in Claim 1. The interpretation will depend on whether the term requires user knowledge or interaction, or if it can encompass any secret data used for authentication.
- Technical Question: The complaint alleges that local biometric authentication (e.g., Face ID) performs the step of "verifying on the client machine" (Compl. ¶21, ¶28). A key technical question for the court will be whether the biometric check functions to "verify" the server-provided token/password as required by Claim 1, or if it simply unlocks a separate, locally-stored credential that is then used in a different authentication step. The specific interaction between the biometric hardware, the OS, the Capital One app, and the server's authentication flow will be central to this inquiry.
- Scope Question: For Claim 11, a question arises regarding the sequence of operations. The claim requires client-side verification before the server stores the session ID in a remote table. The parties may dispute whether the accused product's login flow, which involves communication between the client and server, adheres to this specific claimed order of operations.
V. Key Claim Terms for Construction
The Term: "password" (Claim 1, 14)
- Context and Importance: This term is central because the complaint's infringement theory equates modern authentication tokens and cryptographic keys with the patent's term "password." Capital One may argue for a narrower definition limited to a user-known secret, which its token-based system may not meet. Practitioners may focus on this term because its construction could determine whether the patent's scope covers modern, passwordless authentication systems.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent does not explicitly define "password." It describes the password as being "uniquely corresponding" to the machine identifier and used for verification, a functional description that could plausibly cover any secret data, including a token (’262 Patent, col. 12:25-33).
- Evidence for a Narrower Interpretation: The detailed description repeatedly refers to a "user" entering the password into the client-side software, which suggests a human-memorable or human-entered string (’262 Patent, col. 8:62-65, "A user is then prompted by the client machine key DLL to enter a password...").
The Term: "verifying on the client machine" (Claim 1, 11)
- Context and Importance: This limitation dictates where a critical step of the authentication process must occur. The complaint’s theory relies on local biometric authentication satisfying this element. The dispute will be whether this local action constitutes the entirety of the claimed "verifying" step, or if the actual verification decision is made on the server, with the client merely providing an input.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states, "A comparison is then made, preferably by the client-side software itself, to compare the re-generated machine-specific identifier to the unique password saved by the user" (’262 Patent, col. 2:61-64). This suggests the core comparison is intended to be client-side. The claim language itself simply requires the act of "verifying" to happen "on the client machine."
- Evidence for a Narrower Interpretation: The patent also notes that "the comparison/verification process can also be performed by the server computer" (’262 Patent, col. 3:9-12). While this refers to an alternative, a defendant could argue it shows the drafters knew how to specify server-side verification and that "on the client machine" must therefore mean the entire logical decision happens locally, without essential server involvement in the verification step itself.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement of infringement by Capital One's customers and end-users (Compl. ¶40). The basis for this allegation includes Capital One providing "instructions, documentation, and other information to customers and end-users suggesting that they use the Accused Products in an infringing manner, including technical support, marketing, product manuals, advertisements, and online documentation" (Compl. ¶40).
- Willful Infringement: The complaint alleges willful infringement, asserting that Capital One has had knowledge of the patent since its issuance because, as a bank, it "regularly monitors ways to secure their mobile and web application" (Compl. ¶11). It further alleges that Capital One was willfully blind by adopting a "policy or practice of not reviewing the patents of others" (Compl. ¶11).
VII. Analyst’s Conclusion: Key Questions for the Case
This case will likely depend on the resolution of two central questions:
A core issue will be one of definitional scope: Can the term "password", as used in the 2002-priority patent, be construed broadly enough to read on the server-generated cryptographic tokens and keys used in the accused modern, "passwordless" mobile banking applications?
A key question of technical operation will be: Does the act of a user authenticating via on-device biometrics (e.g., Face ID) perform the specific function of "verifying on the client machine" that the device identifier "uniquely corresponds with the password" generated by the server, as required by Claim 1, or is the local biometric check a distinct step that merely unlocks a credential for a separate, server-controlled verification process?