DCT
2:25-cv-00442
BrowserKey LLC v. Ally Financial Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: BrowserKey, LLC (Texas)
- Defendant: Ally Financial, Inc. (Delaware)
- Plaintiff’s Counsel: Fabricant LLP; Truelove Law Firm, PLLC
- Case Identification: 2:25-cv-00442, E.D. Tex., 04/28/2025
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas 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 web and mobile banking applications, which use device-specific and session-based authentication, infringe a patent related to methods for restricting access to a website by remote users.
- Technical Context: The lawsuit concerns the field of computer security, specifically methods for authenticating a user's device to a remote server to ensure that only authorized machines can access protected data, a foundational technology for secure online services like banking.
- Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.
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 Issued |
| 2019-01-01 | Approximate start of alleged infringement by Accused Products |
| 2025-04-28 | Complaint Filed |
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
- Asserted Claims: Independent Claims 1, 11, and 14
The Invention Explained
- Problem Addressed: The patent identifies weaknesses in then-common security methods. Usernames and passwords can be shared or stolen, and hardware "dongles" can be lost, stolen, or loaned to others, allowing unauthorized access from any computer. (’262 Patent, col. 1:33-56).
- The Patented Solution: The invention proposes a two-part software-based solution to tie access to a specific, authorized client machine. First, a client-side program generates a "machine-specific identifier" based on the unique characteristics of that computer. A password, derived from this identifier, is then used for authentication. Access is granted only if the client machine can successfully re-generate the same identifier to prove its identity. (’262 Patent, col. 2:25-41, col. 7:25-34). Second, for an ongoing session, the system can use a "session identifier" to allow continued access without re-authenticating for every request, while still ensuring the session is valid. (’262 Patent, col. 3:13-34).
- Technical Importance: The technology aimed to provide a higher level of security by binding authentication to a particular device, not just to credentials that a user possesses, thereby preventing access even if a password was compromised and used on an unauthorized machine. (’262 Patent, col. 1:60-67).
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 software program for generating a client machine-specific identifier;
- operating the program to generate the identifier;
- generating a password remote from the client machine that is derived from and uniquely corresponds to the identifier;
- issuing an access request from the client to the server;
- responding by having the client machine re-generate its machine-specific identifier;
- verifying on the client machine whether the re-generated identifier uniquely corresponds with the password; and
- recognizing the client machine as authorized if the verification is true.
- Independent Claim 11 recites a method with the essential elements of:
- creating a session identifier in 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 server data;
- obtaining the stored session identifier and storing it in a remote storage table if the client was verified;
- transmitting a subsequent access request from the client that includes the session identifier;
- comparing the transmitted session identifier with the one in the remote storage table to authorize the request.
- Independent Claim 14 recites a computer program product tangibly embodied in an information carrier that, when executed, performs a method of restricting access.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
The "Ally Financial Web and Mobile Applications," including the "Ally: Bank, Auto & Invest" app for iOS and Android, and all supporting servers, computer systems, and infrastructures (the "Accused Products"). (Compl. ¶9).
Functionality and Market Context
The Accused Products provide Ally Financial customers with online access to their accounts. The complaint focuses on the security and authentication features of these products, particularly those that support "biometric, token-based, and/or passwordless authentication." (Compl. ¶9). These features are alleged to practice a method of restricting access to data on Ally's servers by authorizing a specific client machine. (Compl. ¶16). The complaint references a screenshot from Ally's website listing "Biometric Verification (Optional)" as a feature, which it alleges is part of the infringing process. (Compl. ¶16, p. 6).
IV. Analysis of Infringement Allegations
U.S. Patent No. 7,249,262 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 Ally Financial Mobile Application is installed on a client machine (e.g., a phone) and generates a client machine-specific identifier, described as a device key, certificate, or public/private key pair. | ¶17 | col. 12:16-21 |
| b. operating the client-side software program on the client machine to generate the client machine-specific identifier; | Upon launch, the Ally application and servers verify that the client application is configured to calculate a machine-specific identifier (e.g., a signature, device key, certificate) based on material provided by the server. | ¶18 | col. 12:22-25 |
| 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...and uniquely corresponding thereto; | Ally's servers generate a "password" (e.g., a nonce, token, cryptographic key) derived from the client's machine-specific identifier and provide it to the client machine via HTTP protocol, where it is stored in a secure environment. | ¶19 | col. 12:26-33 |
| d. issuing a request by the client machine to the server computer for access to data maintained on the server computer; | When the Ally application is launched, it issues an HTTP request to Ally's servers for access to protected data, such as account information. | ¶20 | col. 12:34-37 |
| 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.; | When biometric authentication is enabled, the client machine verifies authorization by using biometrics (e.g., fingerprint, Face ID) to grant access to the stored password/key and uses it to verify that it matches the one transmitted by the server. | ¶21 | col. 12:38-44 |
| g. recognizing the client machine as being authorized...if the verification...is true, and refusing to recognize the client machine...if the verification...is false. | If the sign-in on the client machine is successful, access to data on Ally's servers is authorized; if it is not successful, access is denied. | ¶22 | col. 12:45-52 |
U.S. Patent No. 7,249,262 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... | Ally's servers create one or more session identifiers (e.g., a static or dynamic session ID, token, certificate) when a user agent on the client machine requests a protected URL. | ¶25 | col. 13:40-43 |
| d. verifying, on the client machine, that the client machine is authorized to access data maintained on the server computer; | The Ally application verifies a user is authorized to access data by locally authenticating the user's biometric information, or validating that its session ID shows a user is logged in. This is supported by a screenshot that describes Ally's use of Flash objects for "online authentication to help us recognize your computer." (Compl., p. 15). | ¶28 | col. 13:48-50 |
| 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 in step d.; | Once a user is logged in via biometric authentication, the Ally server system obtains the session identifier from the client and stores it in a table within secure memory associated with the server. | ¶29 | col. 13:51-54 |
| g. comparing the session identifier transmitted in step f. with the session identifier stored in the storage table...to determine whether the request...is authorized; | Ally servers compare the session identifier transmitted by the client app with the corresponding identifier stored in a storage table to determine if the request is authorized. The complaint notes that if session cookies are deleted, the client is no longer logged in. | ¶31 | col. 13:58-63 |
| h. permitting access...if the comparison...shows that the request for access is authorized, and denying access...if the comparison...shows that the request for access is not authorized. | If the client is signed in, access to data is authorized by Ally's servers. If the client is not signed in, access is denied. For example, access to a bank account is permitted if the comparison shows the user is logged in based on biometric authentication. | ¶32 | col. 13:64-68 |
Identified Points of Contention
- Scope Questions: The complaint alleges that modern authentication artifacts like a "device key, certificate, [or] public/private key pair" (Compl. ¶17) and session cookies (Compl. ¶31) meet the claim limitations. A central issue will be whether the terms "client machine-specific identifier" and "session identifier," as defined and used in the ’262 Patent, can be construed to encompass these modern, widely-used technologies.
- Technical Questions: Claim 1 requires "verifying on the client machine" whether a re-generated identifier corresponds to a password. The complaint describes a process where biometrics unlock a key that is then used in a transaction with the server (Compl. ¶21). A key question is whether this interaction constitutes the specific local verification step recited in the claim, or if it represents a different authentication mechanism (e.g., a server-led challenge-response) where the critical comparison occurs remotely or in a distributed manner.
V. Key Claim Terms for Construction
"client machine-specific identifier" (Claim 1)
- Context and Importance: This term is the foundation of the patent's device-binding security model. Its scope will determine whether the patent can read on modern authentication systems that use cryptographic keys and certificates. Practitioners may focus on this term because the patent's examples suggest an identifier derived from hardware serial numbers or characteristics, which may be different in nature from the cryptographic identifiers alleged to infringe.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language itself is general, stating the identifier is "substantially unique to the particular machine" without specifying the method of generation. (col. 12:19-21). This could support an interpretation covering any unique, device-bound token.
- Evidence for a Narrower Interpretation: The detailed description provides a specific example of how 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)." (col. 8:60-67). This could support a narrower construction limited to identifiers derived from such physical hardware attributes.
"verifying on the client machine" (Claim 1)
- Context and Importance: This term defines where the critical authentication comparison happens. The infringement allegation hinges on whether the accused product's process, which involves biometrics and communication with a server, constitutes verification "on the client machine" as claimed.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states that the comparison/verification process is "preferably performed at the client machine" but "can also be performed by the server computer." (col. 3:9-12). This language might be used to argue for flexibility in where the verification step occurs, potentially broadening the claim's reach.
- Evidence for a Narrower Interpretation: Claim 1 explicitly requires "verifying on the client machine." (col. 12:38, emphasis added). This explicit limitation, which distinguishes it from the alternative mentioned in the specification, may be argued to confine the scope of this specific claim to a process that is completed locally, without requiring a determinative response from the server.
VI. Other Allegations
Indirect Infringement
The complaint alleges induced infringement under 35 U.S.C. § 271(b), stating that Ally Financial provides instructions, documentation, marketing, and technical support that encourage and instruct customers to use the accused authentication features. (Compl. ¶40). It also alleges contributory infringement under § 271(c), asserting the accused components are material to the invention, not staple articles of commerce, and are known by Ally to be especially adapted for infringement. (Compl. ¶41).
Willful Infringement
The complaint alleges willfulness based on pre-suit knowledge. It asserts that Ally, as a bank, "regularly monitors" security technology and was either aware of the patent or 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
- Definitional Scope: A core issue will be one of claim construction: can the 2002-era term "client machine-specific identifier," described in the patent as being derived from hardware characteristics, be construed to cover the modern cryptographic keys, device tokens, and certificates used in Ally's current authentication systems?
- Locus of Verification: A key factual and legal question will be where the determinative act of authentication occurs. Does the accused biometric login process, which involves a client-server exchange, meet the express limitation of "verifying on the client machine" as required by Claim 1, or does the critical verification step effectively happen on the server, creating a mismatch with the claim's plain language?
- Functional Equivalence: For the session-based allegations in Claim 11, the case may turn on whether Ally's use of standard session cookies and related protocols is functionally the same as the patent’s more structured method, which recites a distinct, initial client-side verification step before the session identifier is accepted and stored by the server for later use.