DCT
6:22-cv-00487
Confirmetrics LLC v. Threatmark Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Confirmetrics, LLC (Texas)
- Defendant: ThreatMark, Inc. (Delaware)
- Plaintiff’s Counsel: Connor Lee & Shumaker PLLC
- Case Identification: 6:22-cv-00487, E.D. Tex., 12/16/2022
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains an established place of business in the district and markets, sells, and delivers accused products within the district.
- Core Dispute: Plaintiff alleges that Defendant’s fraud detection and device identification software infringes patents related to uniquely identifying a mobile electronic device using its configuration settings as a digital fingerprint.
- Technical Context: The technology at issue involves methods for authenticating mobile devices to enhance security for online interactions, such as digital banking, by analyzing a device's unique settings rather than relying on traditional, less secure identifiers.
- Key Procedural History: The three patents-in-suit belong to the same family and claim priority to a single 2010 provisional application. U.S. Patent No. 9,603,016 is a continuation of the application that led to U.S. Patent No. 8,838,967, and U.S. Patent No. 9,801,048 is a continuation of the application that led to the ’016 patent. No other significant procedural history is mentioned in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2010-04-15 | Priority Date for ’967, ’016, and ’048 Patents |
| 2014-09-16 | U.S. Patent No. 8,838,967 Issued |
| 2017-03-21 | U.S. Patent No. 9,603,016 Issued |
| 2017-10-24 | U.S. Patent No. 9,801,048 Issued |
| 2022-12-16 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,838,967 - "UNIQUELY IDENTIFYING A MOBILE ELECTRONIC DEVICE," issued September 16, 2014
The Invention Explained
- Problem Addressed: The patent asserts that prior methods for identifying mobile devices, such as using an IMEI or SIM card number, were inadequate for application-level security because such identifiers were often inaccessible to software, easily forged, or persisted even after a device changed ownership, failing to link the device to a specific user (’967 Patent, col. 1:63-2:23).
- The Patented Solution: The invention proposes a method to create a unique fingerprint for a mobile device by collecting a "multitude of configuration settings," such as installed applications, contact lists, and user interface customizations (’967 Patent, col. 3:37-48). This data is collected, optionally processed, and transmitted to a third-party server, which compares it against a previously stored baseline using a similarity calculation to determine if the device is the same one seen before (’967 Patent, col. 3:49-64).
- Technical Importance: The described method offers a way to authenticate a device for secure online services, like banking, that could operate passively and be more robust than previous techniques (’967 Patent, col. 4:6-14).
Key Claims at a Glance
- The complaint asserts independent claims 1 and 15 (Compl. ¶97).
- Independent Claim 1 recites a method of identification comprising the steps of: (a) collecting a first set of configuration settings from a first device; (b) optionally processing this data; (c) transmitting the result to a third party; (d-f) repeating this collection, processing, and transmission for a second set of settings from a second device; (g) having the third party calculate the similarity between the two transmitted results; and (h) determining the devices are likely the same if the similarity exceeds a threshold (Compl. ¶33).
- The complaint notes that it also asserts dependent claims 2-4, 7-9, 16, and 19-21 (Compl. ¶97).
U.S. Patent No. 9,603,016 - "UNIQUELY IDENTIFYING A MOBILE ELECTRONIC DEVICE," issued March 21, 2017
The Invention Explained
- Problem Addressed: As a continuation, the ’016 Patent addresses the same core problem as the ’967 Patent: conventional authentication methods were "not designed with mobile devices in mind," and information used for identification was either "inaccessible or easily forged" (’016 Patent, col. 1:56-57, col. 2:29-31).
- The Patented Solution: The ’016 Patent claims the invention from the perspective of a central server. The method involves the server "receiving baseline configuration information" from a mobile device, later "receiving subsequent configuration information" from a second device, "determining a similarity" between the two sets of information, and "identifying the second mobile device as the first mobile device" if the similarity surpasses a set threshold (’016 Patent, Abstract; col. 5:4-18).
- Technical Importance: This server-side method provides the core logic for a centralized system to reliably recognize and authenticate returning mobile devices in a secure ecosystem (’016 Patent, col. 4:11-14).
Key Claims at a Glance
The complaint asserts independent claims 1, 12, and 20 (Compl. ¶119).
Independent Claim 1 recites a device identification method comprising: (a) receiving baseline configuration information from a first mobile device; (b) receiving subsequent configuration information from a second mobile device; (c) determining a similarity between the baseline and subsequent information; and (d) identifying the second device as the first if the similarity exceeds a threshold (Compl. ¶39).
The complaint also asserts dependent claims 2-5, 8, 13, 14, and 17 (Compl. ¶119).
Multi-Patent Capsule
- Patent Identification: U.S. Patent No. 9,801,048, "UNIQUELY IDENTIFYING A MOBILE ELECTRONIC DEVICE," issued October 24, 2017 (Compl. ¶15-16).
- Technology Synopsis: This continuation patent refines the invention by claiming a method that uses both a device's "configuration settings" and "at least one electronically accessible property" (e.g., SIM card number, IP address) to generate the device fingerprint (’048 Patent, Claim 1). This combination of user-defined settings and device-specific hardware/network properties is intended to create an even more robust and unique identifier for comparison against a baseline.
- Asserted Claims: The complaint asserts independent claims 1, 12, and 20, along with various dependent claims (Compl. ¶137).
- Accused Features: The complaint alleges that ThreatMark's system infringes by collecting and receiving information indicative of both mobile device configuration settings and other electronically accessible properties, such as OS type, browser plugins, and geolocation data, to identify user devices (Compl. ¶59-60, 140).
III. The Accused Instrumentality
Product Identification
- The accused products are the "ThreatMark Anti-Fraud Suite" ("AFS"), which includes the ThreatMark software platform, an SDK for mobile applications, device client software, and associated methods (Compl. ¶51).
Functionality and Market Context
- The AFS is a security and fraud detection platform that provides "device intelligence and data gathering" for online and device-borne transactions (Compl. ¶54). The complaint alleges the system creates "high resolution device fingerprints utilizing unique data points" to identify returning users (Compl. ¶55-56). An infographic in the complaint shows that data collection is multi-layered, including device fingerprinting, geolocation checks, browser/OS checks, and behavioral analysis (Compl. ¶52, p. 14). A separate diagram shows the collection of data points like "Device Fingerprint," "Geolocation," "Operating System," and "Network" to build a "Trusted User Identity" (Compl. ¶60, p. 17). The complaint alleges the platform is used to validate over 25 million users and over 1 billion annual transactions (Compl. ¶61).
IV. Analysis of Infringement Allegations
’967 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a. collecting a first plurality of configuration settings of a first mobile electronic device, | The accused SDK, when embedded in an app, collects "configuration settings of the mobile device," including installed applications, OS modifications, and other attributes not publicly known. | ¶59, ¶63 | col. 3:37-48 |
| c. transmitting the result of part b to a third party, | The embedded ThreatMark AFS code collects the configuration settings and "sends that information to a server for analysis." This server is identified as the "third party." | ¶66 | col. 3:52-54 |
| d. collecting a second plurality of configuration settings of a second mobile electronic device... | ThreatMark's system is alleged to identify "returning users" by using device fingerprinting, which necessitates the collection of a second set of data upon a subsequent visit. | ¶56, ¶70 | col. 3:55-58 |
| g. said third party calculating how similar the data received in part c is to the data received in part f, | ThreatMark's analytics server allegedly "calculates a confidence score to measure a similarity between the attributes of an instant device to those of the devices in its database." | ¶79 | col. 3:59-64 |
| h. if... said third party determines said data received... is more than a threshold similar... then determining that said first... device is likely the same as said second... device. | The complaint alleges ThreatMark uses thresholds to determine if a device is authentic. Where a device "fails to meet set similarity thresholds," the system can require additional authentication (2FA). A provided screenshot of the "AFS Panel" shows a "Verification status" for each session, indicating a determination has been made. | ¶81, p. 25 | col. 5:5-8 |
’016 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a. receiving baseline configuration information indicative of a first plurality of mobile device configuration settings... | ThreatMark's servers are alleged to receive configuration information from users' mobile devices, which constitutes the baseline data upon a first interaction. | ¶66, ¶70, ¶77 | col. 3:1-4 |
| b. receiving subsequent configuration information indicative of a second plurality of mobile device configuration settings... | The servers are alleged to receive subsequent configuration data when "returning users" and their devices access the service again. | ¶70, ¶78 | col. 3:15-21 |
| c. determining a similarity between the subsequent configuration information and the baseline configuration information; | The system allegedly "uses machine learning to determine similarities between the attributes of an instant device and other devices in its database," and "calculates a confidence score to measure a similarity." | ¶71, ¶79 | col. 4:5-10 |
| d. responsive to detecting the similarity exceeding a threshold similarity, identifying the second mobile device as the first mobile device. | Based on the calculated score, the system "indicates whether each authentication step is performed by a legitimate user or an attacker." A diagram shows that a "Risk Score" determines the outcome (e.g., "ACCESS GRANTED" or "DENIED"), which constitutes the act of identification. | ¶80, p. 27 | col. 6:12-18 |
Identified Points of Contention
- Scope Questions: A central question may be the scope of the term "configuration settings". The patents provide examples such as contact lists, wallpaper, and ringtones (’967 Patent, col. 3:37-48), while the complaint accuses the collection of more technical data like "GeoIP check," "Browser and OS security check," and "clickstream profiling" (Compl. ¶52). The dispute may focus on whether these accused data points, which relate more to a device's technical state than to user personalization, fall within the patent's definition of "configuration settings."
- Technical Questions: The infringement theory for the '967 Patent relies on steps being performed by the "mobile electronic device" and a "third party." The complaint alleges an SDK on the device and a ThreatMark server perform these roles (Compl. ¶59, 66). This may raise questions of divided infringement and whether ThreatMark "directs or controls" its customers' use of the SDK to the extent required to establish liability for the entire claimed method (Compl. ¶103). The claims of the ’016 Patent, which are framed from the server's perspective, may map more directly to the accused system's architecture.
V. Key Claim Terms for Construction
The Term: "configuration settings"
- Context and Importance: This term is the foundation of the patented invention. The breadth of its definition will be critical to determining infringement, as it defines the type of data that must be collected and compared. Practitioners may focus on this term because the accused product collects a wide range of technical data points, and the outcome of the case may depend on whether these points are considered "configuration settings."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the term as including "parameters an operator of that device has freedom to set" and explicitly lists "which applications are installed" as an example (’967 Patent, col. 3:37-46). This language could support an interpretation that includes any software-based, non-hardware setting on the device.
- Evidence for a Narrower Interpretation: The patent repeatedly uses examples related to user personalization, such as "wallpaper image," "alarm clock settings," "ring tone," and "contact list information" (’967 Patent, col. 3:39-45). This could support an argument that the term is limited to user-customized data and does not extend to the more technical, security-focused data points allegedly collected by the accused product (e.g., OS security status).
The Term: "similarity"
- Context and Importance: The claims require "determining a similarity" or "calculating how similar" two data sets are. The accused product allegedly uses machine learning to generate a "confidence score" (Compl. ¶71, 79). Whether this complex scoring method constitutes the claimed "similarity" determination will be a key issue.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent does not mandate a specific calculation method. It suggests that in a "preferred embodiment, this similarity calculation may be the edit distance," which implies that other methods of determining similarity are also contemplated (’967 Patent, col. 3:59-62).
- Evidence for a Narrower Interpretation: A party could argue that the patent's focus on "edit distance" implies a direct, deterministic comparison between two sets of configuration data. This might be contrasted with the accused product's alleged use of a probabilistic "confidence score" derived from a machine learning model, which could be argued to be a fundamentally different technical operation.
VI. Other Allegations
- Indirect Infringement: The complaint alleges both induced infringement (§ 271(b)) and contributory infringement (§ 271(c)) for all three patents. The allegations are based on Defendant providing its SDK and software to customers and instructing or encouraging them to integrate and use the accused system in a manner that allegedly practices the patented methods (Compl. ¶109-110, 127-128, 145-146). The complaint further alleges that the accused products are especially made for this use and are not staple articles of commerce (Compl. ¶110).
- Willful Infringement: The complaint does not explicitly plead "willful infringement" but alleges that Defendant has been "on notice" of the asserted patents and their infringement "at least as early as this complaint" (Compl. ¶100). This appears to lay the groundwork for a claim of post-filing willfulness.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: Can the term "configuration settings", which the patents illustrate with examples of user personalization like "wallpaper" and "contact lists," be construed broadly enough to encompass the more technical and security-oriented data points allegedly collected by the accused system, such as browser security status, OS modifications, and clickstream profiles?
- A second central question will be one of technical mapping: Does the accused product's use of a machine-learning-based "confidence score" to assess fraud risk perform the function of "determining a similarity" between two data sets as required by the claims, or does this modern, probabilistic approach represent a different technology than the direct data comparison envisioned by the patents?
- Finally, for the claims of the '967 patent, a key evidentiary question may concern divided infringement: Does Plaintiff have sufficient evidence to demonstrate that Defendant "directs or controls" the actions of its customers who embed the accused SDK into their applications, such that Defendant is liable for all steps of the claimed method, including those performed on the end-user's device?