WO2015073260A1

WO2015073260A1 - Obfuscating data using obfuscation table

Info

Publication number: WO2015073260A1
Application number: PCT/US2014/063893
Authority: WO
Inventors: Brian J. Stankiewicz; Eric C. LOBNER; Richard H. Wolniewicz; Lyle W. SCHOFIELD
Original assignee: 3M Innovative Properties Company
Priority date: 2013-11-14
Filing date: 2014-11-04
Publication date: 2015-05-21
Also published as: US10503928B2; US20160321468A1; EP3069287A4; EP3069287A1

Abstract

At least some aspects of the present disclosure feature systems and methods for obfuscating data. The method includes the steps of: receiving or retrieve an input data stream comprising a sequence of n-grams; mapping at least some of the sequence of n-grams to corresponding tokens using an obfuscation table; disposing the corresponding tokens to an output data stream.

Description

OBFUSCATING DATA USING OBFUSCATION TABLE

Technical Field

The present disclosure is related to obfuscating restricted, confidential, and private data where the obfuscated data can be used in research, investigation, and other data services.

Summary

At least some aspects of the present disclosure feature a method for obfuscating data using a computer system having one or more processors and memories. The method includes the steps of:

receiving a first data stream comprising a sequence of n-grams; generating a second data stream, by the one or more processors; mapping, by the one or more processors, each of the sequence of n-grams to a corresponding token using a obfuscation table; disposing, by the one or more processors, the

corresponding token in the second data stream.

At least some aspects of the present disclosure feature a system for obfuscating data implemented in a computer system having one or more processors and memories. The system includes a data retrieval module and an obfuscation module. The data retrieval module is configured to retrieve a first data stream comprising a sequence of n-grams. The obfuscation module is operative to: for each of the sequence of n- grams, using an obfuscation table to identify a corresponding token; and disposing the corresponding token in a second data stream.

Brief Description of the Drawings

The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention. In the drawings,

Figure 1 illustrates a block diagram for an embodiment of a data obfuscation system;

Figure 2 illustrates a data flow diagram for an embodiment of providing data service using a data obfuscation system;

Figure 3A is a module diagram illustrating an embodiment of a data obfuscation system;

Figure 3B illustrates a module diagram of an embodiment of a data obfuscation system using the data dictionary approach;

Figures 4A and 4B show examples of the process and output format of data obfuscation using obfuscation table;

Figures 5A and 5B show examples of the process and output format of data obfuscation using data dictionary; and

Figures 6A and 6B illustrate functional flow diagrams for embodiments of a data obfuscation system. Detailed Description

As the amount and type of personal and private data collected, stored, and analyzed continues to rise, governments all over the world have responded by enacting laws designed to protect individual privacy within this data. Privacy laws vary from country-to-country, but generally focus on upholding privacy of its members through restricting access and dissemination of the data. Confidential information is also widely collected and used by large and small business and government organizations. At least some aspects of the present disclosure are directed to systems and methods for obfuscating private and/or confidential data while maintaining attributes allowing element or n-gram driven research and analysis to the obfuscated data. An element is a textual or numeric representation of data and may include a letter, a number, a word, a phrase, a sentence, an n-gram, or a paragraph. N-gram refers to a contiguous sequence of n words including numbers and symbols from a data stream, which typically is a phrase or a sequence of words with meaning. For example, "left leg" is a 2-gram, "bonfire" is a 1-gram, and "first thermal sensor" is a 3 -gram. N-grams are generally interpreted to include any word, number (e.g., sequence of numbers as a single token in an n-gram), symbol (usually symbols are stand-alone, like a comma or a period or a dollar sign as a single token in an n-gram). N-grams also typically include some "special" tokens such as "<start of sentence>" or the like. In some cases, a data obfuscation system includes an obfuscation module to generate or apply mapping an n-gram to a token. In some other cases, a data obfuscation system includes a dictionary module to use dictionary terms to replace n-grams and redact data to include only dictionary terms corresponding to the n-grams that are included in the dictionary.

At least some aspects of the present disclosure are directed to systems and methods that encrypt on an n-gram basis that is different from encrypting at a bit level. By tokenizing the n-gram and encrypting at that level, a data obfuscation system can perform data analysis on the tokenized n-grams without having the risk of exposing confidential and/or privacy data. For example, the system can apply machine learning algorithms on the encrypted or tokenized data. In some other cases, a data obfuscation system can tokenize elements in a document and perform data analysis on the tokenized elements.

Figure 1 illustrates a block diagram for an embodiment of a data obfuscation system 100. The system 100 typically receives an input data stream 110, applies data obfuscation 120 to the input data stream 110 and generates an output data stream 130, and uses the output data stream 130 for further research or analysis 140.

In some cases, the input and output data stream can include content of or in the format of a document, a data set, a database record, data table, or the like. The data stream may contain sensitive data, for example, medical records, financial statements, technical specifications, legal contracts, academic publications, life or death certificates, or the like. For example, medical records include but not limited to electronic health or medical records (EHR/EMR), physician notes, and billing or claim data.

Data obfuscation refers to methods of obfuscating data, mapping data and/or redacting data, for example, by eliminating private or personally identifiable data. At least some aspects of the present disclosure are directed to systems and methods for achieving data obfuscation. In a first embodiment, the data obfuscation 120 includes a one-to-one mapping in which every element of the input data stream 110 is mapped to an obfuscated token saved in the output data stream 130. In a second embodiment, the data obfuscation 120 includes an encryption method that maps a meaningful word into new value that by itself has no meaning. In the first embodiment, the mapping retains the statistical properties of the input data stream 110 that, as an aggregate, can be valuable for identifying patterns without having to know the meaning behind the patterns thereby maintaining the confidentiality of the original data. The second embodiment does not maintain the one-to-one mapping. Instead, the data obfuscation 120 may map multiple words/phrases and even different sets of words to a single value. In this case, the obfuscation can be implemented because the mapping algorithm does not retain or store sensitive components of the original document.

In some embodiments, the data obfuscation 120 uses an obfuscation table to map an element or an n-gram to a token. In some cases, the obfuscation table maps variations of an element/n-gram to a token. A one-to-one mapping obfuscation method has the benefits that the statistics of the original text are maintained but the specific items (e.g, medical words, names, etc.) are obfuscated. In some cases, because the occurrence of sensitive data (e.g., protected health information) is not frequent when multiple documents are aggregated (i.e., the name of a person will not occur in many documents), most data analysis (e.g, machine learning algorithms) will naturally discount the sensitive data as a weak signal. However, those items that are good predictors (e.g., specific procedures or lab tests) will occur more frequently in an aggregated data stream (e.g., a combination of many medical documents). A token is used as a representation of an element or an n-gram, for example, a decimal, hexadecimal, alphanumeric, or the like. In some other embodiments, the data obfuscation 120 uses a predefined data dictionary to perform a first level summarization of a data set before the element/ n-gram obfuscation is performed.

In some embodiments, the system 100 or another computer system receives the output data stream and applies a statistical process on the second data stream generating a statistical result.

Application of a statistical process provides valuable insight and information about underlying patterns and knowledge that exist within the data. In addition to statistical processing, other classification and computational techniques can be performed including, machine learning, regression, data mining, visualization, or the like. For example, a user may want to know if there are items within medical documentation that predicts a Potentially Preventable Condition (PPC) such as sepsis. Potentially

Preventable Conditions (PPC) are negative events or outcomes that results from the process of medical care or treatment. One machine learning approach that can make use of elements, specifically n-grams, within this context is using a clustering algorithm that uses the n-grams as the feature vector for a particular document (Pereira et al. "Distributional Clustering of English Words" Association for

Computational Linguistics (ACL '93), pp 183- 190, 1993). In this case, a user may want to cluster documents that are generated from similar types of diagnosis and procedures. By using the n-grams within the documents, a user can build a high- dimensional representation and based on the words used (or tokens used in this case) the user can find documents of similar type.

Often following the identification of hidden structure in data (e.g., unsupervised clustering), it is useful to understand what features are used to define class inclusion versus exclusion. This can be valuable to better understand aspects of the data that are difficult to interpret without aggregating the data. For example, it might be found that the unsupervised classifier inadvertently created two classes (based on the text) for a single n-gram (e.g., appendicitis). By looking at the features that created the class exclusion, one might find that these two classes are used differently in the original data stream (e.g., two different procedures). However, in order to be able to determine this, a user would want to go from the obfuscated data back to the original data. In some cases, a user could utilize the obfuscation table to determine the original data that is mapped to the obfuscated data. Another approach is to use a random seed that is used to encrypt and tokenize the original data and then provide the random seed to the user to "decode" or "unmap" the obfuscation when needed and/or under the appropriately controlled situation. This could be done with a look-up table or simply inverting the encryption technique using the originally generated encryption key.

Many data (e.g., medical records, legal records, etc.) contain both structured data (i.e., fields that take specific values with explicitly stated labels such as "Age") and unstructured data (i.e., free written text generated by the caretaker). Typically the structured data is a subset of the information that is available in the unstructured text and because of this, it has been shown that there can be more predictive power when one uses the unstructured data than when one uses the structured data to generate predictive or patient classification models. It is frequently the case that structured data is incorrect, out of date, or lacks critical details that are more accurately captured in the unstructured data (e.g., clinical summary, etc.). For example, in healthcare data, a lot of life-style issues are being used in predictive modeling (alcohol use, smoking, living alone, etc.) which are not structured elements (e.g., an actual diagnosis of alcohol abuse). As another example, to classify documents in which there were occurrences of PPC versus those there were not, a user can identify the word(s) in the unstructured text that are better to differentiate the two groups of documents. Utilizing the obfuscated tokens, a user would be able to safely work with the data (with the same statistics of the original text) to determine if there are text elements that best predict a PPC. Once it is determined that there is an appropriate signal, a user could determine the words or features that can better to classify the documents. Furthermore, this classification can lead to signals or features that can predict PPCs.

Figure 2 illustrates a data flow diagram for an embodiment of providing data service using a data obfuscation system. First, a user (e.g., a researcher) 210 sends a data request 220 to retrieve data from the system. In one embodiment, the data request 220 includes the data being requested, the type of package this data will be delivered within, and the user credentials of the user 210. The data being requested describes the specific fields and sets of data desired by the user. The data package type describes the structure of the data once it has been processed to obfuscate or remove the private or restricted information. An optional parameter of the data request 220 includes the user credentials. The credentials are used by the system to enforce access control, log use of data and maintain other compliance and regulatory requirements. Next, the request interface 230 receives the data request 220 and composes a request package 240 that is either equivalent to the data request 220 or includes additional information such as user credentials to the data obfuscation system 250. The data obfuscation system 250 receives the request package 240 and optionally validates the user credentials. The data obfuscation system 250 retrieves data according to request, and obfuscates and/or redacts data according to the data request and/or the data type. The data obfuscation system 250 compiles an obfuscated data package 260 and a response package 270 is transmitted via the request interface 230. The user 210 can perform further research activities on the data contained in the response package 270.

Figure 3A is a module diagram illustrating an embodiment of a data obfuscation system 300A. The system 300A includes a receiver module 315, an access verification module 320, a data retrieval module 325, an obfuscation module 330A, a data transmission module 340, a data analysis module 350, data repository 360, and communication interface 380. One or more modules illustrated in Figure 3 A are optional, such as the access verification module 320, the data analysis module 350. In some

embodiments, the data obfuscation system 300A can be implemented on a computer system 310 including one or more processors and memories.

Various components of the data obfuscation system 300A can be implemented by one or more computing devices, including but not limited to, circuits, a computer, a processor, a processing unit, a microprocessor, and/or a tablet computer. In some cases, various components of the data obfuscation system 300A can be implemented on a shared computing device. Alternatively, a component of the system 300A can be implemented on multiple computing devices. In some implementations, various modules and components of the system 300A can be implemented as software, hardware, firmware, or a combination thereof. In some cases, various components of the data obfuscation system 300A can be implemented in software or firmware executed by a computing device.

The receiver module 315 is configured to receive a request for data. The request can be submitted from a HTTP request, an API call, a database query, or the like. As an example, the user opens a website that contains a list of data that is viewable based upon their authorization access level. User authorization access level may be a numeric designation (e.g., Level 1, 2, etc) or indicated by a status such as restricted or unrestricted. Numeric designation may be system defined. As an example, Level 1 access may permit visibility to all the data contained within a document. Within the receiver module 315, the user selects data with possible constraints (e.g., data field, date ranges, location, etc). For example, a user would like to analyze medical records that were updated for a population of patients treated for appendicitis during the first quarter of 2013. The user enters a Jan 1 , 2013 to March 31, 2013 date range in the date field and selects a medical condition related to the appendix in a condition field on the receiver module 315.

The access verification module 320 may verify user credentials, for example, whether the login information is correct, whether the user is authorized to request data, whether the rights granted to the user allow the user to make the specific request. The access verification module 320 can also direct the obfuscation module 330A about the potential obfuscation methods available to a particular user. For example, one user may be allowed to request data in a raw n-gram format, where another user may only be allowed to request data after it has been passed through a predefined data dictionary.

The data retrieval module 325 retrieves a first data stream in response to the request received. The first data stream typically includes a sequence of n-grams. The first data stream is provided to the obfuscation module 330A. In one embodiment, the obfuscation module 330A can generate a second data stream; for each of the n-grams, use a obfuscation table to identify a corresponding token; disposing the corresponding token in the second data stream. In some cases, the obfuscation table is generated for one or more data streams retrieved. In some other cases, the obfuscation table is stored in a data repository and can be retrieved when it is needed.

In some embodiments, the type of data requested by the researcher defines the operations on the data that will be performed before the private information has been processed and deemed safe for viewing and use by the researcher. The type and definition of possible data packages varies by application and restrictions or legislation applicable to the application data. For example, a type of data is Protected Health Information (PHI) data.

In one embodiment, the obfuscation module 330A is configured to extract the n-grams (e.g., words and phrases, etc.) from a data stream and perform a one-way obfuscation (e.g. one-way hash) routine on each n-gram. Many methods exist in current literature describing how to extract individual n- grams from a data stream. One of the simplest methods is to split the n-grams using a predefined delimiter character. In the case of a textual data stream, the most common delimiter character is a space. Other delimiters include, but are not limited to, other forms of punctuation, key words or phrases, and document section headers or titles. In addition to extraction of individual words, methods exist to formulate element or n-gram objects from individual words. The process of generating element or n-gram sequences in a data stream is known in literature and implemented in many existing systems. Once all the n-grams have been extracted, tokens can be generated using the obfuscation table to an obfuscated output data stream.

Tokens can be generated in many ways, including random number generation, alphanumeric seeding and consecutive index counting. The study of methods to generate random numbers is one that has been evaluated for several decades, culminating in the development of a variety of methods for generating random sequences. Once a random number has been generated, it can be used in its native form as the token, or utilized as a seed to generate the token in a different representation. A token can be represented as a number, a hexadecimal number, an alphanumeric representation, binary string, textual representation, or the like. This technique will obfuscate private and confidential information, while still maintaining word occurrence and position information contained from the original data. This type of technique is optimal for statistical based research methods that rely little on the actual content of the data, but look for usage or occurrence patterns in a dataset. In some cases, a consistent one-way obfuscation scheme is utilized across all documents within a data request to maintain consistency and statistical properties across the dataset. In some implementation, the obfuscation module 330A generates the obfuscation table by creating a mapping for an n-gram when the n-gram is first encountered in the first data stream.

The data transmission module 340 is configured to compile a response package using the data stream provided by the obfuscation module 330A and transmit the response package. In some cases, the response package can include at least part of, or some translated form of, the obfuscation table. In some cases, the conversion of obfuscated tokens back into original data format can be critical to the data analytics process and the interpretation of statistical assessment results. For example, a researcher performing analysis on a set of medical documents may discover that obfuscated token (e.g.,

0x83223CCA) precedes token (e.g., 0x1 1355340) in 93% of document occurrences. In the event of this discovery, the researcher would submit a request to the proposed system for original document text for tokens (e.g., 0x83223CCA) and (e.g., 0x1 1355340). In this example, the researcher could have discovered that a particular behavior, consuming antacids (e.g., 0x83223CCA), always precedes a diagnosis, appendicitis (e.g., 0x1 1355340).

The data analysis module 350 provides the functions and processes to conduct the statistical analysis and data processing functions necessary to derive valuable knowledge and information from the obfuscated output data stream. In addition to statistical processing, other classification and computational techniques can be performed including: machine learning, regression, data mining, visualization, or the like. For example, a user may want to know if there are items within medical documentation that predicts a Potentially Preventable Condition (PPC) such as sepsis. Potentially Preventable Conditions (PPC) are negative events or outcomes that results from the process of medical care or treatment. One machine learning approach that can make use of elements, specifically n-grams, within this context is using a clustering algorithm that uses the n-grams as the feature vector for a particular document. In this case, a user clusters documents that are generated from similar feature vector or types of diagnosis and procedures. By using the n-grams within the documents, a user builds a high-dimensional representation and based on the words used (or tokens used in this case) the user can find documents of similar type.

The data repository 360 may include any transitory and non-transitory computer readable medium to store information and data for the data obfuscation system 300A, including but not limited to, privacy and/or confidential data, requests, user credentials, data dictionaries, obfuscation maps, and response data packages. The data repository 360 may include random access memories, flat files, XML files, and/or one or more database management systems (DBMS) executing on one or more database servers or a data center. A database management system may be a relational (RDBMS), hierarchical (HDBMS), multidimensional (MDBMS), object oriented (ODBMS or OODBMS) or object relational (ORDBMS) database management system, and the like. The data repository 360, for example, may be a single relational database such as SQL Server from Microsoft Corporation. In some cases, the data repository 360 may include a plurality of databases that can exchange and aggregate data by data integration process or software application. In an exemplary embodiment, at least part of the data repository 360 may be hosted in a cloud data center.

Various components of the system 300A can communicate via or be coupled to via a communication interface 380, for example, a wired or wireless interface. The communication interface includes, but not limited to, any wired or wireless short-range and long-range communication interfaces. The short-range communication interfaces may be, for example, local area network (LAN), interfaces conforming to a known communications standard, such as Bluetooth standard, IEEE 802 standards (e.g., IEEE 802.1 1), a ZigBee or similar specification, such as those based on the IEEE 802.15.4 standard, or other public or proprietary wireless protocol. The long-range communication interfaces may be, for example, wide area network (WAN), cellular network interfaces, satellite communication interfaces, etc. The communication interface may be either within a private computer network, such as intranet, or on a public computer network, such as the internet.

An example of the process and output format of data obfuscation is shown below in Figure 4A. A first data stream 410 containing private and/or confidential data is retrieved. An obfuscation table 420A is used to tokenize the first data stream 410 and generate a second data stream 430A. In some cases, the first data stream 410 is retrieved according to a data request. In some cases, a set of data streams including the first data stream 410 are retrieved according to a data request. In some other cases, the first data stream 410 is retrieved according to an on-going data request, for example, clinic visit summaries for a certain type of disease. In some implementations, the obfuscation table 420A is created based on the n-grams in the first data stream 410. In some other implementations, the obfuscation table 420A is created based on n-grams in a set of data streams. In some cases, the obfuscation table 420A is continuously revised and updated based on data streams retrieved.

In some cases, research to be conducted relies on the underlying structure of a document, for example, parts of speech, the obfuscation table and/or the tokens can include such information. For example, an additional field can be appended onto the end of each token to encode this information, as illustrated in Figure 4B. In the example described in Figure 4B, each obfuscated token in the obfuscation table 420B has been appended with a part-of-speech identifier. As an example, the original name (John Doe) has been obfuscated through the data package process, but the structure of the word within the sentence has been maintained by appending the N P (noun, proper, singular) tag to the end of the obfuscated token. Using the obfuscation table 420B, a second data stream 430B is generated.

In some embodiments, a data dictionary approach can be used to protect privacy and confidential data. For example, any restricted data can be removed and only words or phrases listed in the data dictionary can be mapped to standardized dictionary terms and provided to user for further research and analysis. Figure 3B illustrates a module diagram of an embodiment of a data obfuscation system 300B using the data dictionary approach. The system 300B includes a number of modules that are the same as the data obfuscation system 300A illustrated in Figure 3A, including the receiver module 315, the access verification module 320, the data retrieval module 325, the data transmission module 340, the data analysis module 350, the data repository 360, and the communication interface 380. The system 300B includes a dictionary module 330B to perform data obfuscation and masking. One or more modules illustrated in Figure 3B are optional, such as the access verification module 320, the data analysis module 350. In some embodiments, the data obfuscation system 300B can be implemented on a computer system 310 including one or more processors and memories. Processors may each comprise a general-purpose microprocessor, a specially designed processor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a collection of discrete logic, or any type of processing device capable of executing the techniques described herein. In one example, memory may store program instructions (e.g., software instructions) that are executed by one or more processors to carry out the techniques described herein. In other examples, the techniques may be executed by specifically programmed circuitry of processor. In these or other ways, processor may be configured to execute the techniques described herein.

Various components of the data obfuscation system 300B can be implemented by one or more computing devices, including but not limited to, circuits, a computer, a processor, a processing unit, a microprocessor, and/or a tablet computer. In some cases, various components of the data obfuscation system 300B can be implemented on a shared computing device. Alternatively, a component of the system 300B can be implemented on multiple computing devices. In some implementations, various modules and components of the system 300B can be implemented as software, hardware, firmware, or a combination thereof. In some cases, various components of the data obfuscation system 300B can be implemented in software or firmware executed by a computing device.

In some cases, the dictionary module 330B maps a set of n-grams to dictionary terms to perform data obfuscation. The dictionary terms can be, for example, standardized terminology (e.g., joint, contract, etc.), tokens, or symbols (e.g., al34m, c343, etc.) representing the standardized term. In such cases, the dictionary module 330B receives a first data stream retrieved by the data retrieval module 325. The first data stream includes a sequence of n-grams. The dictionary module 330B generates a second data stream and compares each of the sequence of n-grams in the first data stream with the dictionary. If the n-gram is included the dictionary, the dictionary module 330B disposes a corresponding dictionary term to the n-gram in the second data stream; and if the n-gram is not included in the dictionary, the dictionary module 330B will evaluate the next n-gram.

The data dictionary approach can be tailored to research involving key words and phrases associated with a dataset. The process involved in producing this data package takes a raw data document and parses it to identify key words or phrases from a predefined data dictionary, for example, a 3M™ Health Data Dictionary (HDD). These words and phrases listed in the predefined data dictionary have been identified as key information to use in the related domains. The output of this data package type is a list of textual or numeric terms or values (e.g., Numeric Concept Identifier (NOD)) from the data dictionary that have occurred or within the requested dataset. An example of the process and output format of this data package are shown below in Figure 5 A. A first data stream 510 containing private and/or confidential data is retrieved. A data dictionary 520 is used to provide dictionary look-up and mapping to generate a second data stream 530A, which contains terms (i.e., standardized terms, etc.) that are listed in the dictionary. In an alternative embodiment, the system may generate a second data stream 540A, which contains tokens representing the dictionary terms, after the dictionary look-up and mapping. In some cases, the first data stream 510 is retrieved according to a data request. In some cases, a set of data streams including the first data stream 510 are retrieved according to a data request. In some other cases, the first data stream 510 is retrieved according to an on-going data request, for example, clinic visit summaries for a certain type of disease. In some implementations, the dictionary module redacts the first data stream to include n-grams that are listed in the data dictionary 520 to the second data stream. In some other implementations, the dictionary module maps various n-grams in the first data stream 510 to dictionary terms in textual format and dispose the dictionary terms in the second data stream 530A or the dictionary terms in token format in the second data stream 540A.

In some embodiments, the dictionary module uses a specific output format for the second data stream, as illustrated in Figure 5B. For example, a Common Annotation Structure (CAS) can be used.

The CAS summarizes the contents of the data stream into a standard format using consistent language and nomenclature. Once data has been processed into the CAS format, as illustrated as 530B containing dictionary terms in textual format and 540B containing dictionary terms in token format, it can easily be consumed by automated processing techniques.

Figure 6A illustrates a functional flow diagram for an embodiment of a data obfuscation system.

First, the system receives a first data stream (step 61 OA), for example, a document. The first data stream includes a sequence of n-grams. Next, the system parses the n-grams from the first data stream (step 620A). In some cases, the system may separate the first data stream into individual elements (e.g., words) and then group the individual elements into n-grams. For each n-gram, the system searches for the n- gram in the obfuscation table (step 630A). If the n-gram is in the obfuscation table, the system disposes the corresponding token identified from the obfuscation table to a second data stream (step 660A). In some cases, the corresponding token comprises a metadata describing the properties of the n-gram. If the n-gram is not in the obfuscation table, the system generates a token for the n-gram (step 640A); store the generated token in the obfuscation table (step 650A); and dispose the token in a second data stream (step 660A). In some cases, each of the n-grams has a position in the sequence in the first data stream, and the corresponding token is disposed at the same position in the second data stream as the position of the n- gram. After each n-gram in the first data stream is processed, the second data stream is provided either in a data transmission package or for further research and analysis (step 670A).

Figure 6B illustrates a functional flow diagram for an embodiment of a data obfuscation system. First, the system receives a first data stream (step 61 OB), for example, a data set. The first data stream includes a sequence of n-grams. Next, the system parses the n-grams from the first data stream (step 620B). For each n-gram, the system searches the n-gram in the dictionary (step 630B). If the n-gram is in the dictionary, the system disposes the corresponding dictionary term to a second data stream (step 640B). In some cases, the dictionary term can be identical the n-gram. In some other cases, the dictionary term can map to a number of n-grams having similar meanings. If the n-gram is not in the dictionary, the system advances to the next n-gram (step 650B). In some cases, each of the n-grams has a position in the sequence in the first data stream, and the corresponding dictionary is disposed at the same relative position in the second data stream as the position of the n-gram. After each n-gram in the first data stream is processed, the second data stream is provided either in a data transmission package or for further research and analysis (step 670B).

In some embodiments, the second data stream comprises a predetermined data structure including descriptors (e.g, condition, treatment, fee, etc.). In such embodiments, the system will dispose the dictionary terms along with the descriptors. The descriptors may be metadata describing the categories, functions, units, or other information regarding the n-grams, for example. As another example,

"abdominal tenderness" is contained with a document, the assigned dictionary term would become 1009896 and may be assigned a 'diagnosis' descriptor (e.g., xlOO) by the system.

The present invention should not be considered limited to the particular examples and embodiments described above, as such embodiments are described in detail to facilitate explanation of various aspects of the invention. Rather the present invention should be understood to cover all aspects of the invention, including various modifications, equivalent processes, and alternative devices falling within the spirit and scope of the invention as defined by the appended claims and their equivalents.

Exemplary Embodiments

Embodiment 1. A method for obfuscating text data using a computer system having one or more processors and memories, comprising:

receiving a first data stream comprising a sequence of n-grams; generating a second data stream, by the one or more processors;

mapping, by the one or more processors, each of the sequence of n-grams to a corresponding token using a obfuscation table;

disposing, by the one or more processors, the corresponding token in the second data stream.

Embodiment 2. The method of Embodiment 1, further comprising:

applying, by the one or more processors, a statistical process on the second data stream.

Embodiment 3. The method of Embodiment 2, wherein the statistical process comprises n-gram-based statistical analysis that generates an n-gram based statistics.

Embodiment 4. The method of any one of Embodiment 1 through Embodiment 3, wherein the first or second data stream comprises at least one of a document, a data set, a database record, and a medical record.

Embodiment 5. The method of any one of Embodiment 1 through Embodiment 4, wherein the corresponding token comprises at least one of a number, a hexadecimal number, an alphanumeric representation, a binary string, and textual representation. Embodiment 6. The method of any one of Embodiment 1 through Embodiment 5, wherein the corresponding token comprises a metadata describing the properties of the n-gram.

Embodiment 7. The method of any one of Embodiment 1 through Embodiment 6, wherein the obfuscation table maps variations of an n-gram to a token.

Embodiment 8. The method of any one of Embodiment 1 through Embodiment 7, wherein each of the sequence of n-grams has a position in the first data stream, and wherein the disposing step comprises disposing the corresponding token in a corresponding position of the n-gram in the second data stream. Embodiment 9. The method of any one of Embodiment 1 through Embodiment 8, wherein the obfuscation table is predetermined.

Embodiment 10. The method of any one of Embodiment 1 through Embodiment 9, wherein the one or more processors generate the obfuscation table by creating a mapping for an n-gram when the n- gram is first encountered in the first data stream. Embodiment 1 1. The method of any one of Embodiment 1 through Embodiment 10, further comprising:

storing the obfuscation table in the one or more memories. Embodiment 12. The method of Embodiment 3, further comprising:

interpreting the n-gram based statistics using the obfuscating table.

Embodiment 13. The method of Embodiment 2, further comprising:

predicting a relationship of a combination of n-grams with an event.

Embodiment 14. The method of Embodiment 13, wherein the event is predetermined.

Embodiment 15. A system for obfuscating data implemented in a computer system having one or more processors and memories, comprising:

a data retrieval module configured to retrieve a first data stream comprising a sequence of n- grams;

an obfuscation module operative to:

for each of the sequence of n-grams, using a obfuscation table to identify a corresponding token; and

disposing the corresponding token in a second data stream.

Embodiment 16. The system of Embodiment 15, further comprising:

a receiver module configured to receive a request for data from a user,

wherein the data retrieval module retrieve the first data stream according to the request for data.

Embodiment 17. The system of Embodiment 16, further comprising:

an access verification module configured to receive user information entered by the user and verify access level of the user. Embodiment 18. The system of any one of Embodiment 15 through Embodiment 17, further comprising:

a data transmission module coupled to the obfuscation module and configured to compile a response package using the second data stream. Embodiment 19. The system of Embodiment 18, wherein the data transmission module is further configured to compile the response package to include at least part of the obfuscation table. Embodiment 20. The system of any one of Embodiment 15 through Embodiment 19, further comprising:

a data analysis module configured to receive the second data stream and apply a statistical process to the second data stream.

Embodiment 21. The system of Embodiment 20, wherein the data analysis module is further configured to generate an n-gram-based statistics using the statistical process. Embodiment 22. The system of any one of Embodiment 15 through Embodiment 21 , wherein the first or second data stream comprises at least one of a document, a data set, a database record, and a medical record.

Embodiment 23. The system of any one of Embodiment 15 through Embodiment 22, wherein the corresponding token comprises at least one of a number, a hexadecimal number, an alphanumeric representation, a binary string, and textual representation.

Embodiment 24. The system of any one of Embodiment 15 through Embodiment 23, wherein the corresponding token comprises a metadata describing the properties of the n-gram.

Embodiment 25. The system of any one of Embodiment 15 through Embodiment 24, wherein the obfuscation table maps variations of an n-gram to a token.

Embodiment 26. The system of any one of Embodiment 15 through Embodiment 25, wherein each of the sequence of n-grams has a position in the first data stream, and wherein the disposing step comprises disposing the corresponding token in a corresponding position of the n-gram in the second data stream.

Embodiment 27. The system of any one of Embodiment 15 through Embodiment 26, wherein the obfuscation table is predetermined.

Embodiment 28. The system of any one of Embodiment 15 through Embodiment 27, wherein the obfuscation module is configured to generate the obfuscation table by creating a mapping for an n-gram when the n-gram is first encountered in the first data stream. Embodiment 29. The system of Embodiment 20, wherein the data analysis module is configured to predict a relationship of a combination of n-grams with an event.

Embodiment 30. The system of Embodiment 29, wherein the event is predetermined.

Claims

What is claimed is:

1. A method for obfuscating text data using a computer system having one or more processors and memories, comprising:

receiving a first data stream comprising a sequence of n-grams;

generating a second data stream, by the one or more processors;

2. The method of claim 1, further comprising:

3. The method of claim 1, wherein the corresponding token comprises at least one of a number, a hexadecimal number, an alphanumeric representation, a binary string, and textual representation.

4. The method of claim 1, wherein the corresponding token comprises a metadata describing the properties of the n-gram.

5. The method of claim 1, wherein the obfuscation table maps variations of an n-gram to a token.

6. The method of claim 1, wherein each of the sequence of n-grams has a position in the first data stream, and wherein the disposing step comprises disposing the corresponding token in a corresponding position of the n-gram in the second data stream.

7. The method of claim 1, wherein the obfuscation table is predetermined.

8. The method of claim 1, wherein the one or more processors generate the obfuscation table by creating a mapping for an n-gram when the n-gram is first encountered in the first data stream.

9. A system for obfuscating data implemented in a computer system having one or more processors and memories, comprising:

an obfuscation module operative to: for each of the sequence of n-grams, using a obfuscation table to identify a corresponding token; and

disposing the corresponding token in a second data stream.

10. The system of claim 9, further comprising:

a receiver module configured to receive a request for data from a user,

1 1. The system of claim 10, further comprising:

an access verification module configured to receive user information entered by the user and verify access level of the user.

12. The system of claim 9, further comprising:

a data transmission module coupled to the obfuscation module and configured to compile a response package using the second data stream.

13. The system of claim 12, wherein the data transmission module is further configured to compile the response package to include at least part of the obfuscation table.

14. The system of claim 9, wherein the corresponding token comprises a metadata describing the properties of the n-gram.

15. The system of claim 9, wherein each of the sequence of n-grams has a position in the first data stream, and wherein the disposing step comprises disposing the corresponding token in a corresponding position of the n-gram in the second data stream.

16. The system of claim 9, further comprising:

17. The system of claim 16, wherein the data analysis module is further configured to predict a relationship of a combination of n-grams with an event.