DCT
2:25-cv-00450
BrowserKey LLC v. Regions Bank
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., 08/29/2025
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains regular and established places of business in the district, is registered to do business in Texas, and has committed the alleged acts of infringement there.
- Core Dispute: Plaintiff alleges that Defendant’s mobile and web banking applications infringe a patent related to methods for restricting access to server-based data by tying authentication to a specific, pre-authorized client device.
- Technical Context: The technology concerns device-specific authentication, a security method that moves beyond user-specific credentials (like passwords) to verify that an access request originates from a trusted machine.
- Key Procedural History: The filing is a First Amended Complaint against Ally Financial, Inc., designated as a "member case" in what appears to be a broader consolidated litigation (Lead Case No. 2:25-cv-00450). No other procedural history is detailed in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2002-05-06 | ’262 Patent Priority Date |
| 2007-07-24 | ’262 Patent Issue Date |
| 2019-01-01 | Approximate Date Accused Products Began Alleged Infringement |
| 2025-08-29 | 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 risks of traditional username/password authentication, which can be easily compromised if credentials are shared or stolen, allowing unauthorized access from any machine. It also notes the inconvenience and vulnerability of physical hardware tokens, or "dongles." (’262 Patent, col. 1:16-56).
- The Patented Solution: The invention discloses a software-based method to tie access to a specific client machine. A client-side program generates a "machine-specific identifier" based on the unique hardware characteristics of that device (e.g., hard drive or RAM characteristics) (’262 Patent, col. 8:63-67). A corresponding password, derived from this unique identifier, is provided to the user. To gain access, the client machine re-generates its identifier and the client-side software verifies that it corresponds to the user-entered password. This ensures that even if the password were stolen, it would be useless without the specifically-authorized device. (’262 Patent, Abstract; col. 2:59-67).
- Technical Importance: This approach offered a more robust security model by binding authentication to a physical device using only software, an alternative to easily shareable credentials or cumbersome hardware tokens. (’262 Patent, col. 2:1-13).
Key Claims at a Glance
- The complaint asserts infringement of 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 that is derived from and corresponds to the identifier.
- Issuing an access request from the client machine.
- 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 (or refusing) authorization based on the verification outcome.
- Independent Claim 11 (Method):
- 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 on the server.
- Storing the session identifier on the remote computer if the client is verified.
- Transmitting a request from the client that includes the stored session identifier.
- Comparing the transmitted session identifier with the remotely stored one.
- Permitting or denying access based on the comparison.
III. The Accused Instrumentality
Product Identification
- The "Ally Financial Web and Mobile Applications," specifically including the "Ally: Bank, Auto & Invest" mobile app for iOS and Android, along with all supporting servers and infrastructure in use since 2019 (Compl. ¶9).
Functionality and Market Context
- The accused products are online banking platforms that provide users with access to their financial accounts. The complaint alleges that the products' authentication mechanisms, particularly those using biometric identifiers like Apple's Touch ID and Face ID, infringe the ’262 Patent (Compl. ¶16). These features allegedly use device-specific cryptographic keys stored in secure hardware (e.g., a Secure Enclave or Trusted Execution Environment) to authenticate the device to Ally's servers before granting access to protected account data (Compl. ¶¶17, 19). The complaint provides a diagram of the FIDO UAF architecture, which it alleges the Ally app implements for local authentication of keys (Compl. p. 10). This diagram illustrates the interaction between a FIDO client on a user device and a relying party's server (Compl. p. 10, Fig. 1).
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 user installs the Ally Financial Mobile Application from a third-party service like the Apple App Store. | ¶17 | col. 12:17-23 |
| b. operating the client-side software program on the client machine to generate the client machine-specific identifier; | Upon launch, the Ally app generates a unique identifier, alleged to be a device key, certificate, or public/private key pair. | ¶18 | col. 12:24-27 |
| 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... | Ally's servers allegedly generate a "password" (e.g., a cookie, token, or cryptographic key) that corresponds to the device's identifier and provides it to a secure element (e.g., TEE) on the client device. The complaint points to communication logs showing a "TEE_ExportKey" to support this allegation (Compl. p. 9). | ¶19 | col. 12:28-34 |
| d. issuing a request by the client machine to the server computer for access to data... | The Ally app sends an HTTP request to Ally's servers for access to account data when the application is launched. | ¶20 | col. 12:35-38 |
| e. responding to the request... by having the client machine re-generate its machine-specific identifier; | Ally's servers allegedly transmit instructions that cause the client app to use biometrics (e.g., Touch/Face ID) to access the device key and generate a matching password or signed nonce. | ¶21 | col. 12:39-42 |
| f. verifying on the client machine whether the client machine-specific identifier re-generated in step e. uniquely corresponds with the password... | The client-side application allegedly uses fingerprint or face recognition to unlock the secure-element-protected password and verifies that it matches or corresponds cryptographically with information from the server. | ¶21 | col. 12:43-47 |
| g. recognizing the client machine as being authorized... if the verification performed by step f. is true... | If the client-side sign-in is successful, Ally's servers authorize access to account data; otherwise, access is denied. | ¶22 | col. 12:48-55 |
’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... | Ally's servers create session identifiers (e.g., tokens, session IDs) when a user successfully authenticates and requests a protected URL. | ¶29 | col. 13:40-43 |
| b. transmitting to the client machine the session identifier created in step a.; | The session identifier is transmitted from Ally's server to the client device via an HTTP response header containing a "Set-Cookie" field. | ¶30 | col. 13:44-46 |
| c. storing the session identifier transmitted in step b. within the client machine; | The Ally app or the device's browser stores the session identifier locally as a cookie. | ¶31 | col. 13:45-48 |
| d. verifying, on the client machine, that the client machine is authorized to access data maintained on the server computer; | The client app verifies authorization locally by confirming the user is logged in, for instance through biometric authentication. | ¶32 | col. 13:49-51 |
| e. obtaining the session identifier stored in step c., and storing such session identifier within a storage table remote from the client machine... | Ally's server obtains the session identifier from the client and stores it in a server-side table to manage the active session. | ¶35 | col. 13:52-56 |
| f. transmitting a request by the client machine for access to data... such request including the session identifier... | Subsequent requests from the client app to the server include the session identifier in the HTTP request's "Cookie" header. An example GET request is provided as evidence (Compl. p. 22). | ¶36 | col. 13:57-60 |
| g. comparing the session identifier transmitted in step f. with the session identifier stored in the storage table... | Ally's servers remotely compare the session identifier received in the request with the one stored in its session table. | ¶37 | col. 13:61-65 |
| h. permitting access... if the comparison made in step g. shows that the request for access is authorized, and denying access... if... not authorized. | Ally's servers grant access to account data if the session identifiers match and deny access if they do not (e.g., if the session has expired or cookies are deleted). | ¶38 | col. 13:66-14:3 |
- Identified Points of Contention:
- Scope Questions: A central dispute may arise over whether the patent’s term "client machine-specific identifier," described in the specification as based on hardware characteristics like RAM or hard drive parameters, can be construed to read on the modern cryptographic keys stored in a device’s secure enclave, as alleged in the complaint.
- Technical Questions: Claim 1 requires that the critical "verifying" step (element f) occurs "on the client machine." The infringement analysis will likely raise the question of whether the client-side biometric check to unlock a cryptographic key constitutes this verification, or if the legally operative verification is a subsequent cryptographic challenge-response that is ultimately validated by the server, potentially placing the act outside the claim's scope.
V. Key Claim Terms for Construction
The Term: "client machine-specific identifier"
- Context and Importance: This term is the foundation of the claimed invention. The outcome of the case may depend on whether this term is broad enough to cover modern device authentication technologies, such as public/private key pairs managed by a Trusted Execution Environment (TEE), which did not exist in the same form when the patent was filed. Practitioners may focus on this term because the accused technology is more advanced than the embodiments described in the patent.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language itself requires only that the identifier be "substantially unique to the particular machine" (Claim 1). This could be argued to encompass any technology that achieves this result, including cryptographic keys uniquely provisioned to a device.
- Evidence for a Narrower Interpretation: The specification provides specific examples, stating that a software package "analyzes hardware characteristics... including hard drive characteristics, RAM characteristics, input/output device parameters and other hardware specific details" (’262 Patent, col. 8:63-67). This language may be used to argue that the claim is limited to identifiers generated from such static hardware "fingerprints."
The Term: "verifying on the client machine" (Claim 1)
- Context and Importance: The location of this action is a dispositive claim limitation. If the determinative verification is found to occur on the server, infringement of this claim would be negated.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent describes a process where "the client-side software verifies that the re-generated machine-specific identifier properly corresponds with the unique password" (’262 Patent, col. 2:63-66). Plaintiff may argue that the client-side biometric check in the accused product, which unlocks a private key to sign a server challenge, is the modern equivalent of this local verification step.
- Evidence for a Narrower Interpretation: The patent describes a self-contained comparison on the client device. A defendant may argue that in the accused system, the client merely unlocks a key, and the true verification of authorization happens when the server validates the resulting cryptographic signature—an act that occurs on the server, not the client.
VI. Other Allegations
- Indirect Infringement: The complaint alleges that Ally induces infringement by instructing its users to perform the claimed login steps to access their accounts and conditions the benefits of the service on that performance (Compl. ¶24).
- Willful Infringement: The complaint alleges willfulness on the basis that Defendant knew or should have known of the patent due to its position as a bank that monitors security technology, or that it was willfully blind by adopting a policy of not reviewing patents of others (Compl. ¶11).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the term "client machine-specific identifier," rooted in the patent's disclosure of analyzing static hardware characteristics, be construed to cover the dynamic, cryptographically-secured key pairs managed by the secure hardware of modern smartphones?
- A key factual question will be one of locus of operation: does the accused system perform the dispositive "verification" of authenticity "on the client machine" as required by Claim 1, or is the ultimate arbiter of access a server-side validation of a cryptographic response, placing the key step outside the claim's literal scope?
- The case may also turn on an evidentiary question of linkage: what technical evidence can establish that the server-generated "password" (e.g., a token or cookie) is "derived from" the device's unique identifier, as the claim requires, rather than being two distinct but correlated security elements in a modern authentication workflow?