DCT
8:17-cv-01289
Msignia Inc v. Inauth Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: mSIGNIA, Inc. (California)
- Defendant: InAuth, Inc. (Delaware)
- Plaintiff’s Counsel: Haynes and Boone, LLP
- Case Identification: 8:17-cv-01289, C.D. Cal., 07/26/2017
- Venue Allegations: Plaintiff alleges venue is proper because Defendant has a regular and established place of business in the district, specifically a West Coast Office in Santa Monica focused on engineering and product development, and has committed acts of infringement in the district.
- Core Dispute: Plaintiff alleges that Defendant’s InAuth Security Platform and related products infringe a patent related to user and device authentication systems that use dynamically changing device data.
- Technical Context: The technology relates to digital security, specifically authenticating a device or user by creating a "fingerprint" from a wide array of changing device attributes, such as software, settings, and hardware identifiers.
- Key Procedural History: The complaint alleges a notable pre-litigation history, stating that Plaintiff's founders, Miller and Tuvell, developed their technology ideas in 2010-2011 and discussed them with Michael Patterson, who was then a potential sales hire. The complaint further alleges that Mr. Patterson subsequently founded Defendant InAuth and that an InAuth investment presentation "reflected many of the technical ideas and concepts that Mr. Miller and Mr. Tuvell had developed."
Case Timeline
| Date | Event |
|---|---|
| 2011-02-03 | Priority Date for U.S. Patent No. 9,559,852 |
| 2017-01-31 | U.S. Patent No. 9,559,852 issues |
| 2017-07-26 | Complaint filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,559,852 - "Cryptographic Security Functions Based on Anticipated Changes in Dynamic Minutiae," issued January 31, 2017
The Invention Explained
- Problem Addressed: Traditional device authentication methods struggled with mobile devices. Using a small set of static identifiers (like serial numbers) creates a "fingerprint" that is easy to spoof. Using a large set of dynamic data (like installed apps, settings, etc.) is more secure, but because this data changes frequently during normal use, it can cause the device's "fingerprint" to change, leading to valid users being locked out ("false negatives") (’852 Patent, col. 2:42-68).
- The Patented Solution: The invention proposes a system that authenticates a device by creating a cryptographic key from a wide range of its dynamic data attributes, termed "minutiae." Critically, the system does not just rely on the current state of these minutiae; it also stores and uses "information regarding anticipated changes" to this data. This allows the system to distinguish between normal, expected changes (e.g., a software update) and anomalous changes that might signal fraud, thereby providing continuous and reliable authentication without the "friction" of frequent re-authentication (’852 Patent, Abstract; col. 3:15-34).
- Technical Importance: This approach seeks to create a persistent and robust device identity that adapts to the fluid nature of modern mobile computing environments, moving beyond static identifiers.
Key Claims at a Glance
- The complaint asserts independent claim 1 (Compl. ¶29).
- Claim 1 Essential Elements:
- An identity recognition system comprising a non-transitory memory and one or more hardware processors.
- The memory stores information for an identity, which includes (a) "data values associated with that identity" and (b) "information regarding anticipated changes to one or more of the stored data values."
- The processor performs operations including:
- Generating a challenge that prompts a computer to provide a response based on its data values.
- Receiving the response from the computer.
- Determining if the response is "allowable" by "using the stored information regarding anticipated changes."
- Recognizing the computer as authentic if the response is allowable.
- The complaint reserves the right to assert other claims (Compl. ¶29).
III. The Accused Instrumentality
Product Identification
The "InAuth Security Platform" and related products including InMobile, InBrowser, InRisk, InAuthenticate, InExchange, InReach, and InPermID (Compl. ¶4, ¶18).
Functionality and Market Context
The complaint alleges that the InAuth Security Platform is a security product sold to businesses for authenticating users and devices (Compl. ¶4). It is marketed as a system that "leverages up to 2,000 device attributes" to "uniquely and consistently identify and authenticate mobile devices across time, users, and apps" (Compl. ¶27). The stated goal is to "provide[] frictionless experiences for known good devices" by using this device data for authentication (Compl. ¶27). The system is alleged to operate on a client-server model, where device attributes are collected from a mobile device and sent to a server for authentication (Compl. ¶29.b).
IV. Analysis of Infringement Allegations
No probative visual evidence provided in complaint.
'852 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| An identity recognition system comprising: a non-transitory memory storing information associated with one or more identities... | The Infringing Products allegedly use a client-server system for identity authentication where a server-side non-transitory memory stores information for numerous devices (Compl. ¶29.b). | ¶29.a, ¶29.b | col. 18:31-34 |
| wherein the information stored for an identity includes (a) data values associated with that identity; and (b) information regarding anticipated changes to one or more of the stored data values associated with that identity | The Infringing Products allegedly collect and store dynamic data values (e.g., from accelerometer, contacts, GPS, apps). The complaint alleges, "on information and belief," that InAuth also stores data regarding "anticipated changes," and may have referred to this as a "CR build" (Compl. ¶29.c). | ¶29.c | col. 3:25-34 |
| one or more hardware processors in communication with the memory and configured to execute instructions to cause the identity recognition system to... perform... operations | The complaint alleges on information and belief that the Infringing Products use servers, which "necessarily include one or more hardware processors," to authenticate mobile devices (Compl. ¶29.d). | ¶29.d | col. 3:56-61 |
| generating a challenge to the computer, wherein the challenge prompts the computer to provide a response based on one or more data values from the computer... | The complaint alleges the InAuth Security Platform collects device attributes and "prompt[s] the device to provide a response to the server with updated versions of the collected device attributes" (Compl. ¶29.e). | ¶29.e | col. 15:46-54 |
| receiving, from the computer, the response to the challenge | The platform is alleged to receive a response from the prompted device containing updated attributes (Compl. ¶29.f). | ¶29.f | col. 16:38-42 |
| determining whether the response is allowable, wherein such determining comprises using the stored information regarding anticipated changes... and recognizing that the presentation of identity information... is authentic... | The complaint alleges on information and belief that InAuth's authentication process involves comparing received data values "to anticipated changes to corresponding stored data values" and that InAuth may have referred to this data as part of a "CR build" (Compl. ¶29.g). | ¶29.g | col. 17:1-15 |
Identified Points of Contention
- Scope Questions: The central dispute will likely involve the scope of the claim phrase "information regarding anticipated changes." The complaint's allegations for this element are made "upon information and belief" and reference a speculative "CR build" (Compl. ¶29.c, ¶29.g). This raises the question of whether the accused system simply uses a fault-tolerant algorithm that allows for a certain amount of data drift, or if it truly stores and uses predictive data about future device states as the patent seems to describe.
- Technical Questions: A key evidentiary question will be what proof Plaintiff can obtain to substantiate its "information and belief" allegations. Discovery will likely focus on the architecture of the InAuth Security Platform to determine if it maintains a database or data structure corresponding to the claimed "information regarding anticipated changes," or if its functionality is achieved through other means.
V. Key Claim Terms for Construction
- The Term: "information regarding anticipated changes to one or more of the stored data values"
- Context and Importance: This term is the central inventive concept distinguishing the patent from prior art that either used static data or failed to account for dynamic data changes. The case's outcome may depend on whether the accused system's method for handling data changes falls within the construed scope of this term. Practitioners may focus on this term because the infringement allegations for this element are based on "information and belief," suggesting it is a primary point of dispute (Compl. ¶29.c).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: A party could argue the term is broad enough to cover any system that accounts for the dynamic nature of minutiae. The patent's emphasis on achieving "fault tolerance" and avoiding "false negatives" caused by natural data changes could support an interpretation that includes systems with algorithms that are simply tolerant of a certain degree of deviation from a baseline, without explicit prediction (’852 Patent, col. 7:26-34).
- Evidence for a Narrower Interpretation: A party could argue the term requires a more active, predictive mechanism. The specification explicitly describes an "Anticipated Minutia DB" that stores "all the possibilities" for minutia based on cataloging industry updates (’852 Patent, Fig. 2A, element 98; col. 13:35-43). This suggests the system is intended to store pre-calculated, discrete future states, supporting a narrower construction that requires more than just a generalized tolerance for data drift.
VI. Other Allegations
Willful Infringement
The complaint does not use the word "willful" in its infringement count, but it seeks treble damages and a finding that the case is exceptional in its prayer for relief (Compl. Prayer ¶1.d). The factual basis for this appears to be the allegation of pre-suit knowledge, where Plaintiff’s founders allegedly disclosed their technology concepts to Defendant's founder before the formation of InAuth (Compl. ¶20-21).
VII. Analyst’s Conclusion: Key Questions for the Case
Definitional Scope: A core issue will be the construction of the claim term "information regarding anticipated changes." The case may turn on whether this term requires a system to store explicit predictions of future device states, as suggested by the patent's "Anticipated Minutia DB," or if it can be read more broadly to cover any system with a fault-tolerant algorithm that accommodates routine data changes.
Evidentiary Sufficiency: A key factual question will be whether Plaintiff can prove that the InAuth Security Platform performs the functions required by the claims, particularly the use of "information regarding anticipated changes." The complaint's reliance on "information and belief" and a speculative "CR build" for this element highlights that the actual architecture and operation of the accused system will be a central focus of discovery and proof at trial (Compl. ¶29.c, ¶29.g).