Management Science Associates Inc v. Datavant Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Management Science Associates, Inc. (Pennsylvania)
  • Defendant: Datavant, Inc. (Delaware) and Universal Patient Key, Inc. (Delaware)
  • Plaintiff’s Counsel: Smith, Katzenstein & Jenkins LLP
• Case Identification: Management Science Associates, Inc. v. Datavant, Inc., et al., 1:20-cv-00502, D. Del., 04/13/2020
• Venue Allegations: Venue is alleged to be proper in the District of Delaware because both Defendants are Delaware corporations and thus reside in the district.
• Core Dispute: Plaintiff alleges that Defendants’ data de-identification products and services infringe a patent related to methods for generating unique tokens to anonymize and link data records from multiple clients.
• Technical Context: The technology addresses the secure de-identification of sensitive personal data, such as patient health information, enabling data aggregation and analysis while maintaining individual privacy as required by regulations like HIPAA.
• Key Procedural History: The complaint alleges that Plaintiff notified Defendants of the patent-in-suit via an email to Datavant's CEO on April 26, 2019, establishing a date for alleged actual knowledge. The complaint also notes that Defendants had filed their own patent applications in the de-identification technology space in 2016, after the priority date of the asserted patent.

Case Timeline

Date	Event
2013-06-03	'814 Patent Priority Date
2016-01-01	Defendants filed patent applications for de-identification technology (approximate date)
2017-04-04	'814 Patent Issue Date
2018-04-30	Datavant announced acquisition of Universal Patient Key, Inc.
2019-04-26	Plaintiff allegedly notified Datavant's CEO of the '814 Patent
2020-04-13	Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 9,614,814 - “System and Method for Cascading Token generation and Data De-identification” (issued April 4, 2017)

The Invention Explained

• Problem Addressed: The patent describes a need for improved data de-identification methods. It notes that traditional techniques, such as concatenating multiple data fields (e.g., name, birthdate) into a single string and then encrypting it, can be vulnerable to statistical analysis or other reverse-engineering attacks that could re-identify individuals, particularly as computing power increases (’814 Patent, col. 1:26-36).
• The Patented Solution: The invention discloses a "cascading" or "polyphasic" method for creating a de-identification token. Instead of hashing a single combined string, the system sequentially hashes individual data elements, where the output of one hash operation becomes an input for the next. (’814 Patent, col. 5:1-8). This creates a nested, layered token intended to be more secure. The overall system architecture, as shown in Figure 1, involves a distributed model where a "data supplier" (103) generates tokens and sends them to a remote "data processing entity" (108) for matching and linking, ensuring raw data remains separated from the central matching database (’814 Patent, Fig. 1; col. 4:61-65).
• Technical Importance: The described cascading hash process aims to provide enhanced security for anonymized tokens, a critical feature for industries like healthcare that must process and link large volumes of legally protected data (e.g., Protected Healthcare Information) from different sources. (’814 Patent, col. 1:37-41).

Key Claims at a Glance

• The complaint asserts independent claims 1 (method), 10 (computer program product), and 19 (system) (Compl. ¶49).
• Independent Claim 1 recites a computer-implemented method with the following key elements:
  • Receiving a record for an individual from one of a plurality of clients.
  • Generating a "token" based at least partially on the record's data elements and a "client tag" that uniquely identifies the client.
  • Creating a de-identified record containing a portion of the original record and the generated token.
  • Matching the token (or a new token derived from it) to another token in a database, where that other token was also generated using the same "client tag".
  • Linking the de-identified record to the other de-identified record in a data storage device.
• Independent Claim 10 recites a non-transitory computer-readable medium with instructions for executing the method of Claim 1.
• Independent Claim 19 recites a system comprising a "data supplier computer" (for receiving records and generating tokens) and a remote "data processing entity computer" (for matching tokens and linking records).
• The complaint's use of "at least claims 1, 10, and 19" suggests the right to assert additional dependent claims may be reserved (Compl. ¶49).

III. The Accused Instrumentality

Product Identification

The accused instrumentalities are Defendants' "data de-identification technology," including "de-identification software," products, and services (Compl. ¶40).

Functionality and Market Context

• The complaint alleges that the Accused Instrumentalities are software solutions for analyzing healthcare data in a secure and HIPAA-compliant manner (Compl. ¶22).
• The accused functionality involves generating "site-specific tokens" based on patient data and a "site-specific encryption key" (Compl. ¶42).
• These tokens are allegedly used to create "de-identified data sets" that allow patient records from a given site to be matched and linked, and to be matched with records from a data recipient by converting the tokens into the recipient's token scheme (Compl. ¶¶ 42-43).
• The complaint positions the Accused Instrumentalities as central to Datavant's business of "connecting data between healthcare providers" (Compl. ¶21).
• No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

’814 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
receiving a record for an individual from at least one data storage device associated with a client, the record comprising a plurality of data elements identifying the individual	Defendants are alleged to use the accused method, product, and system to provide de-identification services to their customers, which involves receiving and processing customer records.	¶45	col. 10:1-4
generating, with at least one processor, a token based at least partially on the plurality of data elements and a client tag uniquely identifying the client among the plurality of clients	The Accused Instrumentalities allegedly "generate site-specific tokens based on patient data and a site-specific encryption key."	¶42	col. 10:5-9
creating, with at least one processor, a de-identified record comprising a portion of the record and the token	The accused process allegedly "create[s] de-identified data sets with site-specific tokens for each patient record."	¶42	col. 10:10-12
matching, with at least one processor, the token or a new token based on the token to at least one other token in a database, the at least one other token generated based on the client tag...	The generated tokens allegedly allow "patient records to be matched and linked for a site," and for "corresponding de-identified patient records in the data source and recipient's data" to be matched.	¶¶42-43	col. 10:13-18
linking, with at least one processor, the de-identified record to the at least one other de-identified record in at least one data storage device	The functionality of matching records for a site or between a source and recipient inherently includes linking them.	¶¶42-43	col. 10:18-21

Identified Points of Contention

• Scope Questions: A central dispute may concern whether the accused "site-specific encryption key" (Compl. ¶42) satisfies the "client tag uniquely identifying the client" limitation of the claims. The analysis will question if a cryptographic key used for encryption serves the same role as the claimed "client tag," which the patent describes as a unique client identifier used in the hashing process.
• Technical Questions: The ’814 Patent emphasizes a "cascading" hash method as a key aspect of the invention. The complaint does not specify the technical process by which the Accused Instrumentalities generate their "site-specific tokens." A key factual question for the court will be whether the accused token generation process performs the specific sequential, dependent hashing described in the patent's specification, or if it employs a different, non-infringing algorithm.

V. Key Claim Terms for Construction

The Term: "client tag"

• Context and Importance: This term appears in all asserted independent claims and is foundational to the patent's multi-client architecture. The infringement case, as pleaded, hinges on equating the accused "site-specific encryption key" with this term. Practitioners may focus on this term because its construction could be dispositive of infringement.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification suggests flexibility, stating the "client tag" can be a "client code or client key" and may be "combined, incorporated, XORed, or used as an input to a hashing function" (’814 Patent, col. 6:26-30). This could support an interpretation that includes any client-specific data, such as a unique encryption key, used as an input in token generation.
  • Evidence for a Narrower Interpretation: The specification also states that in a preferred embodiment, the "client name is stored in the configuration file and, based on the client name, the client tag is generated or created" (’814 Patent, col. 6:36-39). This could support a narrower construction limiting the term to an administrative identifier, rather than a cryptographic element like an encryption key.

The Term: "token"

• Context and Importance: While "token" is a generic term, its meaning in the context of the patent is arguably tied to the specific "cascading" generation process. The dispute will question whether the accused "site-specific tokens" (Compl. ¶42) are created in a manner that falls within the patent's scope.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim language itself does not explicitly recite the "cascading" steps, defining the token more broadly as being "based at least partially on the plurality of data elements and a client tag" (’814 Patent, col. 10:6-9). This may support an argument that any token derived from these inputs infringes, regardless of the specific algorithm.
  • Evidence for a Narrower Interpretation: The patent's Abstract, Summary, and Detailed Description heavily feature the "cascading hash process" where "each subsequent hash depends upon a previous hash result" as a key inventive feature (’814 Patent, col. 5:1-8; Abstract). A court may be asked to import this limitation from the specification into the claims, thereby narrowing the definition of "token" to only those created by this specific sequential process.

VI. Other Allegations

Indirect Infringement

The complaint alleges active inducement (§ 271(b)), asserting that Defendants provide customers with "instructions, directions, or terms of use" that direct them to operate the accused systems in an infringing manner (Compl. ¶59). It also alleges contributory infringement (§ 271(c)), claiming the accused products are not staple articles of commerce, lack substantial non-infringing uses, and are "especially made or adapted for infringing" (Compl. ¶¶ 56, 60).

Willful Infringement

The willfulness allegation is based on alleged pre-suit knowledge of the ’814 Patent. The complaint specifically points to an April 26, 2019 email from Plaintiff to Datavant's CEO, which allegedly included a copy of the patent, as evidence of actual knowledge (Compl. ¶¶ 28, 50). The complaint alleges that Defendants' infringing activities continued after this date, constituting willful and deliberate infringement (Compl. ¶63).

VII. Analyst’s Conclusion: Key Questions for the Case

• A core issue will be one of definitional scope: can the claim term "client tag", described in the patent as a unique client identifier derived from a name or code, be construed to cover the "site-specific encryption key" allegedly used in the Defendants' system? The outcome of this claim construction battle could significantly impact the infringement analysis.
• A key evidentiary question will be one of technical implementation: does the accused method for generating tokens perform the specific "cascading" or sequential hashing that is a central teaching of the ’814 patent? The complaint does not provide these technical details, suggesting that discovery will be necessary to determine if there is a fundamental match or mismatch in the underlying algorithms.