TABLES, TEXT FI LES, AND DATA FEEDS

TECHN ICAL FI ELD

This invention addresses issues of data privacy and forensic analysis of data files using content-based zero-watermarking techniques to determine the date a file was created.

BACKGROUND ART

Owners of data (each a "Data Provider") often give, lease, or sell their data to individuals or organizations that are supposedly trusted to handle that data in a legal fashion ("Trusted Third Parties" or "TTPs"). The TTPs are obligated to follow contractual requirements or data-handling regulations, such as Regulation B in financial services or privacy laws set by local, state or federal government. This data is usually transmitted to the TTPs as a series of database tables (.sql), text files (.csv, .txt. or other format), or as a real-time data feed (e.g. , XML or JSON). Despite this, the Data Provider's data may leak (the leaked file is defined as a "Leaked Subset") into the hands of others ("Bad Actors") who either knowingly or unknowingly use the data illegally. This can happen because a TTP knowingly releases the data, an employee of the TTP knowingly or accidentally releases the data, or an employee of the actual Data Provider knowingly or unknowingly leaks the data.

Once the Data Provider's data leaks, it can be manipulated by Bad Actors in numerous ways: elements can be altered, it can be merged with data from other Data Providers, or it can be broken into subsets or

rearranged, among other types of manipulation. This makes it difficult for the Data Provider to recognize the data as its own, identify the party responsible for leaking the data, and recover lost revenue in a court of law.

The applicant has developed systems and methods in hardware and software for watermarking data sets to identify a Leaked Subset and identify which TTP or TTPs were the Bad Actors ("Guilt Assignment"), as disclosed in co-pending international patent application number PCT/US2016/068418. This system and method solves for two problems, outbound processing and inbound processing. Outbound processing refers to the association of unique data with each outbound data subset from a Data Provider (also known as a "watermark" or a "fingerprint" depending on the technique used) so that the data contained in any Leaked Subset, even if altered in some way, can still be identified as coming from the data provider and that specific file. Inbound processing allows the Data Provider to then track the flow of data back to a specific TTP so that a probability that it is the likely source of the Leaked Subset can be assigned and its guilt determined in a way that can be enforced in a court of law. This requires the ability to take a data file acquired from a third party (a "Wild File") that realistically could contain a Data

Provider's data, whether or not the third party is known to be a Bad Actor, and process it in a way that the data can be recognized as coming from a specific data file, from a specific TTP. The problem for inbound processing in making this determination is that it is necessary for the Data Provider (or their agents, such as a third-party service) to match the data contained in the Wild File with the matching Leaked Subset from a specific TTP. In a commercial system that provides data fingerprinting and guilt assignment, each TTP may receive hundreds of files a month over the course of many years, and there may be thousands of TTPs. Making a match to a single file in a universe of millions files through a brute force approach where a comparison is made to every file would be computationally expensive, if not impossible, with today's technology.

An example will give a sense of scale to this problem. Assume a Data Provider ships 200,000 files a year over 1 0 years, representing 2,000,000 total files shipped (the "File Universe"). Also assume that it takes one hour to determine if a specific file is the source of the leaked data in a specific Wild File. If one is required to search the entire file universe, it would take

2,000,000 hours, which equates to 228 years. It may be further noted that this example ignores the fact that any Data Provider may be processing multiple Wild Files acquired from multiple sources at the same time. A solution that takes this long is obviously useless.

It may be seen then that a system and method that allows the Data Provider to determine if a Wild File matches a specific Leaked Subset in a reasonable period of time that makes undertaking data fingerprinting worth doing in the first place would be highly desirable. DISCLOSURE OF I NVENTION

The invention is directed to systems and methods that utilize change fingerprinting. Change fingerprinting may be defined as a process that can be applied to any text file, database table, or data feed generated by a specific software program that allows it, or associated programs, to determine a posteriori the timeframe (e.g. , the month and year) in which the file was generated, even when its original creation date is unknown. By doing this, the problem space described above is reduced to a reasonable number of files to make Guilt Assignment possible in a reasonable period of time. In the example above, the problem space for matching is reduced from a file universe of two million files to 16,666 files needed for comparison. This reduces the problem space to something manageable where hardware or other forms of system scaling can be used to match the Wild File to a specific Leaked Subset.

When any file or stream of text is generated by a software system , the date and time of its creation is generally recorded. This information may be found, for example, in the details available through Windows file explorer or by the Is command in Linux. A problem arises, however, when the file is given to a third party and, either intentionally or unintentionally, all meta-data (e.g. variable names, value labels) contained within the file is stripped away and the file name is changed or, alternately, the data in the file is manipulated (e.g. recoded, such as altering the variable name and changing values from 1 - 10 to A-J) and the file saved under another name with different meta-data (e.g. , altered variable names and value labels). The most likely situations in which this occurs are data theft from a software-based system or, alternately, when a file containing data from that system is handed in the clear to a TTP, and then that TTP manipulates the file and its data to intentionally obfuscate its ownership/generation from the specific software program . These two scenarios are within the definition of the term "data leakage", and while they represent the two most likely scenarios, this invention is meant to cover any use case where data leakage and the concomitant loss of file-identifying information may occur.

In certain implementations of the invention, the text file, data table, or data feed consists of rows of records, or a string of records in the case of an XML or JSON feed. Each row contains data on a single object - for example, personal information on a single consumer (e.g., unique user id, name, address, demographic information, etc.) or production information on items (e.g., manufacturer, make, model features). In both examples, at least one column contains a "valid" age for each object at the time the file was created. A valid age is one that can be verified against a Date of Birth or Production Date, although the invention also covers the case where a date of birth or production date "anchor" may not be available. In this case, one or more secondary columns containing data that changes in some predictable way over time can be used as an alternate "anchor" to triangulate a valid age for a specific Wild File. For purposes of these implementations of the invention, an individual item in the Wild File can be identifiable via a name, address, etc., or other id, as long as the record contains a persistent and unique identifier (e.g., Acxiom Corporation's ConsumerLink variable) that does not change over time.

Once a Bad Actor is suspected of using a Leaked Subset, the Data Provider can resort to legal means to stop the leak and recover lost revenue. As part of the process, the Data Provider often has a contractual right to audit a TTP suspected of misusing data. However, many TTPs may have been receiving hundreds of data files a month for a long period, such as a decade or more, so the problem becomes difficult due to scale. Lacking any mechanic for bounding the search, the Data Provider would be required to go through emails, documents, spreadsheets and other physical documentation for the entire period during which data files were sent to try to discover where, when, and how the leak occurred. The cost of such discovery would be substantial and prohibitive in terms of time required for litigation and effort/money spent on the discovery process. If the search space could be restricted to one month, as opposed to twelve, 92% of the search space is eliminated. If data is retained for more than a year then the search space reduction is even greater. It may be seen then that there is a need to restrict the search space for discovery to speed litigation and lower costs. These are two problems this invention addresses. This invention specifically applies to the inbound processing portion of the machine, as well as to certain elements of legal discovery.

These and other features, objects and advantages of the present invention will become better understood from a consideration of the following detailed description of the preferred embodiments and appended claims in conjunction with the drawings as described following:

BRIEF DESCRIPTION OF DRAWINGS

Fig. 1 illustrates the overall conceptual framework and design for a change fingerprinting system according to an implementation of the invention.

Fig. 2 illustrates the system reduction mechanics for a watermarking system according to an implementation of the invention.

Fig. 3 illustrates two example files for comparison, a W, wild file and a current data file, according to an implementation of the invention.

Fig. 4 illustrates a merge of the W, wild file with the current data file according to an implementation of the invention.

Fig. 5 illustrates the determination of file year using the change fingerprinting system according to an implementation of the invention.

Fig. 6 illustrates the determination of file month and year using the change fingerprinting system according to an implementation of the invention.

Fig. 7 illustrates a comparison of a W, wild file with two files of known date according to an implementation of the invention.

Fig. 8 is a table containing merged example data from two current Data Provider files of known date and a W, wild file of unknown date according to an implementation of the invention.

BEST MODE FOR CARRYING OUT THE INVENTION

Before the present invention is described in further detail, it should be understood that the invention is not limited to the particular embodiments and implementations described, and that the terms used in describing the particular embodiments and implementations are for the purpose of describing those particular embodiments and implementations only, and are not intended to be limiting, since the scope of the present invention will be limited only by the claims.

Figure 1 shows the overall system flow, including the Data Owner environment 9 and the data fingerprinting system 1 . The Data Owner environment 9 denotes clients, including Data Owner internal clients who use the data fingerprinting system. It is included in this document to provide context for the present discussion and to illustrate the end-to-end data flow. The main system components are numbered and correspond to the brief description below.

• 10 - Data Extraction - Customer Data Delivery. This is the process where the Data Provider extracts data from its master database 2, output as data files 3 or data feeds 4 to deliver or distribute to third parties.

• 1 1 - Data Transfer. This is the specific data transfer mechanic (e.g., SFTP) employed by the Data Provider to transmit data to Trusted Third Parties 6. It interacts with TTPs 6 through firewall 5.

• 12 - File Storage System. This is the beginning of the data

fingerprinting system. The Data Provider submits a copy of all data files and data feeds delivered to third parties to the file storage system 12.

• 13 - Wild file. When a wild file is uncovered by the Data Provider the file is transmitted to the data fingerprinting system at file transfer 1 1 .

• 14 - File Handler. The system detects a new file in the system and triggers the file handler process.

• 15 - Fingerprinting Process. The system copies the new file to the database server's file system and loads the wild file into the fingerprint database 7.

• 16 - Guilt Assignment Process. The user kicks off the guilt assignment process for the wild file. The system parses the file and checks if a date anchor exists at decision block 8. If at least one date anchor exists the system executes the change fingerprinting process 17.

• 17 - Change Fingerprinting Process. This subsystem will be described in detail below.

• 18 - Output Month/Year Fingerprint. The system returns the estimated date(s) of the wild file in month and year to the guilt assignment process 16. • 19 - Request Matching Month/Year Files. The guilt assignment process 16 executes a request to retrieve data files from the month and year from step 18.

• 20 - Extracted Files. The system extracts the files per request in

request matching month/year files step 19 for the guilt assignment process 16.

• 21 - Generate Guilt Score Report. The guilt assignment process 16 generates a guilt score for the wild file 13.

Figure 2 shows the general system design for the reduction mechanics involved in processing a wild file 13 to determine which TTP 6 originally received the file from the Data Owner. In this example, the wild file 13 input to the system has age related information, as well as date of birth (DOB) as an anchor. Age-related information includes age in two-year increments, new 18 year olds added on a monthly basis, and records for those older than 60 possibly being suppressed. Accurate, consistent, and persistent DOB is provided through a service provider's recognition process, such as the AbiliTec service from Acxiom Corporation, where personally identifiable information (Pl l) (e.g., name and address) from the wild file 13 is matched against the service provider's data. At this point the wild file 13 could be derived from any of the files that have gone out to the Data Owner's customers over the entire period of the Data Owner's records retention, which in this example is ten years.

The date reduction process described in this implementation of the invention allows the wild file 13 to be dated to the month and year it was created. With each monthly file release in this example assumed to be approximately 1 TB in size, the total for all monthly releases for the last ten years of retained files would be approximately 120 TB. Narrowing the search space to one year out of ten reduces the search space by 90%, but reducing it to one month out of ten years of monthly data eliminates over 99% of the search space. At this point the file could originate from any customer receiving files for the particular month/year. This processing is shown at step 7 of Figure 2.

The fields and individuals associated with a customer order provide a unique fingerprint that acts as an additional reduction mechanism, since each fingerprint is unique and tied to each TTP. As one example, the horizontal salting procedure described in the applicant's co-pending international patent application no. PCT/US2016/068418, which is incorporated herein by reference, permits a file to be associated with a specific Data Owner client and a TTP with whom the Data Owner has shared their data. The result is a further reduced set of files at step 30 in this Figure. At this step in the process, the wild file 13 can be ascribed to a file received by a specific customer in a specific month/year.

The final reduction mechanic occurs through statistical comparisons of the properties of variables in the wild file 13 with those from the Data Provider file that went to the specific customer, which occurs at step 32. While it is possible for a Bad Actor to change variable names and how values are labeled, it is much more difficult to alter the statistical properties of the variables per se. Two files from the same month based on the same individuals, and with the same variables, should be statistically the same. Statistically similar means the probability density functions of continuous variables and the probability mass functions of categorical variables should be the same. Likewise, bivariate and multivariate relationships among the variables in the files should be essentially the same. A guilt score may thus be created (in a range, for example, of 0 to 1 ) that provides a numeric measure of the strength of association between the wild file 13 with the identified Data Provider file. At the most simple level, the guilt score may correspond to the percentage of rows in wild file 13 that are found in the Data Provider file. Other considerations in generating the guilt score may be, for example, the percentage of the variables in wild file 13 that are in the source file; the percentage of the variables in wild file 13 that are also in the source file and have the same metadata characteristics; whether the variable names and levels are exactly the same or have been recoded; and, even in the absence of identical variable names and labels, whether the probabilistic characteristics of variables are statistically the same or similar.

Basic Concept: Change Fingerprinting with an Available DOB (or similar) Anchor Referring now to Figure 3, change fingerprinting process 17 can be described in greater detail. Consider a specific wild file (W,) 13 with data as shown in table 20 that was been acquired through some mechanic, such as an active file acquisition program or a government agency bringing a file to the Data Provider and asking them if this is their data. On the right side of the diagram is the latest Data Provider File (D) that has been produced 22, in this case for September, 2014. Each row in the file represents a unique individual, and most people have a value for a two-year age range. Age changes each year, and since birthdays are distributed across a year, each month when D is updated the ages of some individuals advance by one year.

To reduce compute cycles, the Data Provider wants to minimize the number of potential core data files it must compare the wild file 13 against to determine if any of the data in the wild file originates from D. The wild file Wi 13 contains a field that indicates age of head of household in two-year increments, and it looks suspiciously like the age in two-year increment field in D. To ascertain their equivalence, the Data provider uses match keys on a random sample subset of W, 13 to match against the Data Provider's current file, and incorporate the two age fields into a single table 24, as shown in Figure 4.

Once single table 24 is created, the Data Provider applies a recognition process to table 24 (e.g. , Acxiom Corporation's AbiliTec service) and acquires these individuals' DOBs, the best information about their current age based on original legal documents such as birth certificates, passports, government issued identification, and so on. By taking the difference between current true age, as defined against a fixed, stable reference like DOB, and the age range in the matched rows from the W,, the system can predict the most likely date, specifically year and month, of the Data Provider's source file from which the data in the W, may have been obtained. This can be done in a one-step process (not shown) or in a two-step process, as shown in Figures 5 and 6.

Figure 5 shows an example of ranging for the year, while Figure 6 shows an example of ranging for month-year, and how the wild file date can be established as August of 2009 in a particular example. One of the individuals shown, Steven Box, had a birthday in September, and his age changed. But the ages for Jack Joseph and Mark Miserd, with birthdays in November and December, respectively, did not change. Stevens's age shows as 46-47, Jack's as 30-31 , and Mark's as 44-45, and given their birth months, it may be deduced that the file date must be August of 2009.

Change Fingerprinting Without DOB or Similar Anchor as a Stable Reference

In an alternative implementation of the invention, it is possible to execute the same process as described above without reference to a date of birth from AbiliTec or other recognition source. If we assume that the data in any Data Provider's master data set 2 is accurate with a high level of precision, independent of being tied to a DOB anchor, then we can build a DOB reference column from twelve sequential files generated from a common (master) data source, like Acxiom Corporation's InfoBase. This is essentially a reverse birthday append to the files by watching the months in which ages change. That yields birth months and years for each individual in the master data source. After creating that reference column, the Change fingerprinting mechanic can then be applied.

File Dating Lacking Accurate Information from the Data Provider

Age information is often acquired by third-party data providers, and even first parties, from sources such as web forms, where people do not put their true age. The result is that ages in a wild file W, could be highly inaccurate, lacking a DOB anchor to validate against.

At the time a specific Wi file 13 is acquired, the Data Provider does not know if any included age data is from D, hence there is no guarantee that the data in the file is accurate on an individualized basis. In this case, they use the same mechanic against a DOB anchor, but only keep age matches on recognized individuals. This means they have matched the records and put them through some type of recognition process, where the ages between the two files are the same (for one-year increments) or, in the case of two-year ranges, where the age ranges are the same. The rest of the data is considered "tainted" and is discarded. Most files are large enough that even if the data in the W, file 13 did not come from D and even if the data is not of high quality, the Data Provider should be able to get a large enough sample that does match to be able to identify the month/year in which the source file was created.

This use case is important when the service is provided by the Data Owner to third parties. It allows the provider to date the source file for wild files (Wi's) 1 3 suspected of containing those third parties' data.

Additional Change Fingerprinting Mechanic - Added and Deleted Records

Change fingerprinting has a second mechanic, layered on top of the one described previously, which helps triangulate the month and year of the correct S _j,t . This mechanic takes advantage of the fact that records are added to or deleted from S _j as it is created and then refreshed at times t, t+1 , t+2... .t+n. In the case of consumer data files, people are typically added when they turn 18, and removed once they are 61 or are deceased. As a result, one can treat those additions and deletions as a specific type of salted record ("natural salted records") that allows the Data Owner to more accurately determine the month and year of a specific file.

Figure 7 serves to illustrate the use of naturally salted records. In this example, there are three files: on the left a wild file Wi with data 20

suspiciously resembling data from the Data Provider, and on the right two files from the Data Provider, created in September and October of 2014, denoted as Data Provider files 22 and 26, respectively. Note that Rosa Vasquez has been deleted from the October 2014 file 26 (because she turned 61 ), and Lisa DeBeers has had a birthday between the September and October files.

These files 20, 22, and 26 from Figure 7 are combined, the Date of Birth anchor appended, and the current actual age determined, as shown in Figure 8. Two features emerge from this comparison. First, Rosa Vasquez appears in the wild file W, 13, which means the data could not have come from the October, 2014 file. In addition, Lisa DeBeers could only have been added to the file when she turned 18 (which is shown in the W, file 13). In the wild file W, 13, she is in the 18 to 19 age interval, meaning the S _j had to come either from 2010 or 201 1 . However, given that her real age is 22 and she has just had a birthday between September and October, we know that the wild file Wi 1 3 must have come from a S _j, t of September 2010. This is consistent with Rosa Vasquez being in the W, file 13. One may therefore conclude that the S _j, t for the Wi file 13 is the September, 201 0 file.

One additional observation has to do with the primacy of new records for 18 year olds added to the Data Owner's consumer database on a monthly basis. Consider the situation where the Data Owner recovers a wild file 13 from the Internet or other electronic media. As a file ages on a monthly basis, the number of 18 year olds decreases by about 8% each month. After one year, there will be no 18 year olds remaining in the file. Carried to the extreme, after two years there will be no 18 or 19 year olds, and so on. Using an identity recognition process as described above, Pl l from the wild file 1 3 is used to match against the Data Providers master file 2, and true DOB is appended. If the wild file 1 3 is a representative statistical sample of the Data Providers file, simply sorting the wild file 13 by DOB from oldest to most recent provides the date (month and year) of file creation. The most recent DOB dates will be for the most recently added 18 year olds. If the wild file 13 is from the current month, say November of 2016, the most recent DOB on the file will be November of 1 998, exactly 1 8 years ago. If the most recent DOBs on the file are from March of 1 998, the wild file 13 was created in March 2016. If the wild file 13 was created in July of 2010, the latest DOB on the file would be July 1992. This mechanism can be used for quickly determining file creation date, and serves as an alternative validation to the main proposed DOB mechanism.

Additional Change Fingerprinting Mechanic - Changed Records The change fingerprinting process can also be extended, in an alternative embodiment of the invention, to any change in a database field occurring between two dates, as long as an audit trail of original files is maintained. For example, if Lisa DeBeers was shown as unmarried in July 2010 but married in September 2010, and if she was shown as married in the Wi 13 (she was a child bride), it would serve as another signal that the original S _j, t could not have predated September 2010. As such, the accuracy of the prediction by ranging on the earlier timeframe of the S _j,t (whereas the loss of Rosa Vasquez ranges on the later timeframe) is reaffirmed.

Files for Which the Invention is Applicable

Although the implementations of the invention described above focus on data files containing consumer data that may have age-related fields, the invention is not so limited. In alternative implementations, types of data files that might contain this data include:

• Files from third-party consumer data providers

• First-party customer relationship management (CRM) files containing customer information for specific merchants

• Airline or other travel reservation files where passenger age or DOB is captured

• Consumer health records

• Files from loyalty programs

• Corporate personnel records

• Government tax files and other government records (e.g., Social Security Administration records, passport records)

• Academic records Other Categories of Data

The lack of a dependable age anchor is usually not an issue for data tables containing information about "hard goods" like dishwashers, plumbing pipes, watches, stereos, and televisions, among many others, where a product date, warranty date, batch id, and batch ship dates are inherent in a file, or ages of the product vary less than in typical consumer data. Take for example data on used cars on a website dealer such as autotrader.com. The model year of the car is known from the 10 ^th digit of the Vehicle Identification Number, so if a data file containing car ages was stolen and Edmunds wanted to know if the data came from their databases and if so when (the month and year), it would be unlikely that the underlying age data is inaccurate or that a Bad Actor could manipulate that specific feature without the tampering being evident.

For soft goods (e.g., clothing) or goods from continuous processes (e.g., petrochemicals or steel), age tends not to be something that is relevant. Even though a file would likely have a batch id and order date, there is no age measure that can be used. Note also, but as an aside, these types of goods tend not to have warranties or be associated with a specific individual, so it is unlikely data stolen from these types of producers would have value in a larger market for illicitly obtained data that would make it worth watermarking.

Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein.

All terms used herein should be interpreted in the broadest possible manner consistent with the context. When a grouping is used herein, all individual members of the group and all combinations and subcombinations possible of the group are intended to be individually included. When a range is stated herein, the range is intended to include all subranges and individual points within the range. All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification.

The present invention has been described with reference to certain preferred and alternative embodiments that are intended to be exemplary only and not limiting to the full scope of the present invention, as set forth in the appended claims.