Patent Description:
Generally described, electronic data stores can be used to store open and protected information. The information stored in a data store can be entirely open, entirely protected, or may include both open and protected information. Different items of protected information can have varying degrees of privacy associated with them, and may accordingly require more or less effort to maintain the associated degree of privacy.

Access to an electronic data store can be restricted according to the degree of privacy of the information the data store contains. Access can be restricted, for example, by requiring use of logins and passwords to access the data store, or by only permitting access from certain networks or network addresses. Access can be further limited to include only a portion of data store contents, or to grant a particular level of access based on the credentials provided. However, these access controls provide limited flexibility and require significant effort to administer and maintain.

<CIT> discloses a technique for generating a masked value from a cryptographically transformed value by using the cryptographically transformed value as a random seed, without decrypting the cryptographically transformed value. A query is evaluated against a set of data to produce a result. The result may be cryptographically transformed or unencrypted. If the result is unencrypted, the result may be cryptographically transformed to produce a random seed. If the result is already cryptographically transformed, then the result is used as the random seed. The random seed is used to generate a masked value, without decrypting the cryptographically transformed random seed value. The masked value conforms to a particular data characteristic such as a data format or a data type, which may be determined from metadata stored in a database, received with a query, or gleaned from unencrypted data. The masked value is returned as a result of the query.

<CIT> discloses a method and apparatus for implementing attribute relevant access control policies. A database server restricts a user from seeing data from restricted attributes without restricting the rows retuned to the user. This is done by masking the result set of a query before returning it to the user. Masking prevents the user from seeing values for the restricted attributes. For example, attribute restriction metadata may indicate that managers may see the salaries of people in their departments while regular employees may only see their own salaries.

Document <CIT> discloses identifying sensitive data elements from a data source through discovery tool to generate data definitions for sensitive data elements. A runtime rule set is mapped to data definitions for each of sensitive data elements.

The systems, methods, and devices described herein each have several aspects, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of this disclosure, several non-limiting features will now be discussed briefly.

Embodiments of the present disclosure relate to a dynamic data minimization server that may automatically minimize and de-minimize protected information stored in data stores, such as in accordance with privacy settings established by a system administrator. As used herein, minimization refers to the process of encrypting, masking, hashing, generalizing, randomizing, dissociating, de-personalizing, anonymizing, pseudo-anonymizing, and/or otherwise transforming an original item of information into a "minimized item" associated with a higher degree of privacy. As but one example, a masking function may transform the name "John Smith" into "J--- S-----," preserving the initials and length of the original item while reducing any association between the minimized item and a particular identity. As a further example, a generalizing function may transform an age of an individual, e.g., <NUM>, into a range of "<NUM>-<NUM>" to provide some general age information while reducing the level of personally identifiable information in the minimized item. As still further examples, a dissociating function may remove an association between the data items "John Smith" and "<NUM> E. Main Street," or a generalizing function may minimize "<NUM> E. Main Street" to "E. Main Street.

As described below, a dynamic data minimization server may be utilized with an existing data store to control access to protected data (either data regarding an individual, a group of individuals, an organization, a business, or other entity) at the level of individual items and requests. In some aspects, the dynamic data minimization server may be utilized to minimize a data store, replacing all or part of the stored protected information with transformed or anonymized data. The dynamic data minimization server may utilize a reverse transformation function, such as a decrypting function that corresponds to a previous encryption function, to fulfill requests for the original protected information (e.g., by a user that has appropriate rights to access the protected data that was originally provided in a minimized form). In other aspects, the dynamic data minimization server may provide minimization services, such that a data store maintains the original data, and requests to access information in the data store are processed via the dynamic data minimization server and minimized on demand. Further aspects of the present disclosure include generation and display of user interfaces for requesting information, displaying items of minimized protected information, and processing requests to access items of de-minimized protected information.

Reference will now be made to the accompanying drawings, which illustrate example embodiments of the present disclosure. In the drawings:.

Reference will now be made in detail to example embodiments, the examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Embodiments describe methods, systems, and transitory or non-transitory computer-readable mediums for minimizing protected information and processing requests to access de-minimized protected information. The embodiments described herein may be applied to existing data sources, with or without modification to the original source data, and may be used to create, customize, and persist minimization settings on a per-request and/or per-item basis. Items of protected information may be minimized to support, for example, privacy policies, data minimization policies, legal requirements, or other conditions, and may be accessed or de-minimized in accordance with access policies.

In order to facilitate an understanding of the systems and methods discussed herein, a number of terms are defined below. The terms defined below, as well as other terms used herein, should be construed to include the provided definitions, the ordinary and customary meaning of the terms, and/or any other implied meaning for the respective terms. Thus, the definitions below do not limit the meaning of these terms, but only provide exemplary definitions.

Protected data is any information regarding a particular entity, such as an individual, a group of individuals, an organization, a business, or any other entity or combination of the aforementioned entities, that is desirable to be kept private or concealed, such as personal, sensitive, and/or confidential information. In some implementations, protected data includes any personally identifiable information ("PII") that could potentially be used to identify a specific individual or to distinguish one individual from another.

Open data is any information regarding a particular entity that is not protected data, such as publicly available data.

Minimization process (function or transformation), refers to any process of anonymizing, encrypting, masking, hashing, generalizing, randomizing, dissociating, de-personalizing, and/or otherwise transforming an item of protected data (or a "protected data item") into a "minimized data item" associated with a higher degree of privacy and/or that is less indicative of a particular entity.

A reversible minimization process (function or transformation) can be applied to a minimized data item to recover (or regenerate) the original protected data. A reversible minimization process can only be applied to protected data that is minimized using a reversible minimization process.

Access rights are rights of a requesting entity, such as a requesting individual, group of individuals, organization, business, or any other entity, to access protected data. Access rights may be based rights of the requesting entity and/or characteristics of the requested data. For example, data items may have varying metadata that are usable to determine access rights of requesting entities. In some embodiments, an access control list (ACL) may be accessed to determine rights of a requesting entity to view protected data.

An ACL is a set of one or more permissions that govern use (e.g., read access, write access, etc.) of the associated access-controlled (e.g., protected) data. A permission in an ACL may be expressed in a variety of different forms in various embodiments. For example, a permission may specify a set of one or more trustees (e.g., a user) and one or more use rights (e.g., read access, write access, etc.) of those trustees with respect to the associated data item. As another example, a permission may specify a minimum security classification level (e.g., unclassified, secret, top secret, or a particular job title or position) such that only users that possess the minimum security classification level can use (e.g., read, write, etc.) the associated protected data item. In other embodiments, other forms for expressing an ACL permission may be used. As discussed herein, the permissions data associated with particular data items of various types may be used to determine minimization processes to perform on protected data items in order to provide some form of information to the requesting entity, while reducing personally identifiable information provided. In some embodiments, an ACL may be generated or managed as illustrated by the Sharing References.

<FIG> is a block diagram of an example network topology <NUM> for processing requests to minimize and de-minimize (which may include a process of re-identification, reverse anonymization, and/or other process) protected data in accordance with the present disclosure. In the illustrated embodiment, the network topology <NUM> includes a dynamic data minimization server <NUM> in communication with a presentation server <NUM>. In various embodiments, the dynamic data minimization server <NUM> may correspond to a wide variety of computing devices configured to implement aspects of the present disclosure. For example, the dynamic data minimization server <NUM> can include one or more computing devices (e.g., server(s)), memory storing data and/or software instructions (e.g., database(s), memory device(s), etc.), and other known computing components. According to some embodiments, the dynamic data minimization server <NUM> can include one or more networked computers that execute processing in parallel or use a distributed computing architecture. The dynamic data minimization server <NUM> can be configured to communicate with one or more components of the network topology <NUM>, and it can be configured to provide information via an interface(s) accessible by users over a network (e.g., the Internet). In some embodiments, the dynamic data minimization server <NUM> can include an application server configured to provide data to one or more presentation servers <NUM> executing on computing systems connected to the dynamic data minimization server <NUM>.

The presentation server <NUM> may similarly correspond to a wide variety of computing devices configured to implement aspects of the present disclosure. The example topology in <FIG> is not limiting, and various configurations of the dynamic data minimization server <NUM> and presentation server <NUM> are within the scope of the present disclosure. For example, the dynamic data minimization server <NUM> and presentation server <NUM> may be implemented as a single computing device, as one or more virtual computing devices, or as various combinations of physical and virtual computing devices and computer-executable instructions.

In the illustrated example, the presentation server <NUM> is in communication with one or more protected data stores <NUM>, which store protected data and may additionally store open data. Generally, a protected data store <NUM> may correspond to a hard disk drive, network accessible storage, or any other type of perpetual or substantially perpetual storage accessible by the presentation server <NUM>. For example, the protected data stores <NUM> of <FIG> may correspond to network accessible storage devices. Though depicted as external to the presentation server <NUM>, in some embodiments, protected data stores <NUM> may be internal to the presentation server <NUM>. Further, in some embodiments, the protected data stores <NUM> may be internal to the dynamic data minimization server <NUM>, may be in communication with the anonymization server <NUM> instead of (or in addition to) the presentation server <NUM>, and may be in communication with the presentation server <NUM> via the dynamic data minimization server <NUM>.

In some embodiments, the presentation server <NUM> is in communication with a minimized data store <NUM>. Generally, a minimized data store <NUM> may correspond to a hard disk drive, network accessible storage, or any other type of perpetual or substantially perpetual storage accessible by the presentation server <NUM>. For example, the minimized data store <NUM> of <FIG> may correspond to a network accessible storage device. Though depicted as external to the presentation server <NUM>, in some embodiments, the minimized data store <NUM> may be internal to the presentation server <NUM>. Further, in some embodiments, the minimized data store <NUM> may be internal to the dynamic data minimization server <NUM>, may be in communication with the dynamic data minimization server <NUM> instead of (or in addition to) the presentation server <NUM>, and may be in communication with the presentation server <NUM> via the dynamic data minimization server <NUM>. Further, in some embodiments, the minimized data store <NUM> may be omitted or combined with one or more protected data stores <NUM>.

The network topology <NUM> further includes a network <NUM> operable to enable communication between the presentation server <NUM> and the client computing device <NUM>. The network <NUM> may be, for instance, a wide area network (WAN), a local area network (LAN), or a global communications network. In some embodiments, the dynamic data minimization server <NUM>, presentation server <NUM>, protected data stores <NUM>, or minimized data store <NUM> may communicate via the network <NUM> or via a separate network, such as a private LAN.

The modules or components illustrated in <FIG> may include additional components, systems, and subsystems for facilitating the methods and processes. For example, in various embodiments, the dynamic data minimization server <NUM>, presentation server <NUM>, protected data stores <NUM>, and minimized data store <NUM> may be centralized in one computing device, distributed across several computing devices, implemented by one or more virtual machine instances, and/or distributed through a network.

<FIG> is a block diagram of an example data set <NUM> that contains items of protected information, in accordance with aspects of the present disclosure. The example data set <NUM> may be stored, for example, in a data store, such as a protected data store <NUM> of <FIG>. In the illustrated example, data set <NUM> includes record identifier <NUM>, first name <NUM>, last name <NUM>, latitude <NUM>, longitude <NUM>, telephone number <NUM>, and Social Security Number (SSN) <NUM>. Data set <NUM> is provided as an example, and the present disclosure is applicable to any data set containing protected information. As non-limiting examples, data set <NUM> may contain medical records, health information, financial records, billing records, credit card information, or other confidential data. In some embodiments, data set <NUM> may contain data subject to privacy laws, such as the Health Insurance Portability and Accountability Act (HIPAA) or the Data Protection Directive, may contain data subject to legally mandated internal controls, such as the Sarbanes-Oxley Act, or may contain data controlled by privacy policies, data minimization policies, or other policies that restrict access to all or part of the data set <NUM>. Further, in some embodiments, individual items of information may be protected while other items of the same type are open, and items of information may be accessible by requesting entities based on characteristics of the particular requesting entity. Thus, a first requesting entity may have rights to view all protected information of a first entity, while a second requesting entity may only have rights to view a minimized version of the protected information (such as by applying one or more minimization processes to portions of the protected information). As a non-limiting example, some telephone numbers <NUM> may be unlisted or otherwise have greater privacy requirements than others.

With reference now to <FIG>, an example user interface <NUM> for presentation of minimized data will be described. In the illustrated example, the minimized data presented in <FIG> corresponds to the data set <NUM> of <FIG>. <FIG> depicts a simplified interface for purposes of illustration, and in various embodiments, user interface <NUM> may have more or fewer components within the scope of the present disclosure. As non-limiting examples, user interface <NUM> may be implemented as a web page displayed via a web browser, or as an application executing on a tablet, mobile, or other computing device. Additionally, in some embodiments, the minimized data in <FIG> may be provided via an application programming interface (API) rather than an interface generated for display.

In the example of <FIG>, various transformation functions have been applied to elements of data set <NUM> as examples of minimized protected information. As an example of open information that has not been minimized, record identifier <NUM> (<FIG>) has not been transformed and is displayed without transformation in the first column <NUM>.

Column <NUM> contains minimized information corresponding to the first name <NUM> of <FIG>. A transformation function has been applied to the first name data, truncating the data at the first initial and replacing the remaining characters with a period (". ") to indicate that the information has been abbreviated. In column <NUM>, a masking transformation function has been applied to the last name <NUM>, replacing all characters after the initial with a dash. These example masking transformations, as well as certain other minimization processes discussed herein, preserve the character length of the last name data items (or other data items), allowing some analyses to be performed while limiting access to the underlying member names. As a non-limiting example, an analysis may be performed on the minimized last names to determine whether a particular input field length (e.g., an input field that accepts up to <NUM> characters) will be suitable for input of last names.

Columns <NUM> and <NUM> present transformed latitude and longitude information corresponding to the latitude <NUM> and longitude <NUM> in data set <NUM>. For these columns, an example transformation function has been applied that reduces the number of significant digits in the latitude or longitude information. The minimized data may thus be analyzed to determine, e.g., customer addresses within a general area, such as a city or region, without revealing exact locations. In some embodiments, user interface <NUM> may include a map display that presents imprecise geolocation data as a range, circle, heat map, or other indicator of potential geolocations. In further embodiments not depicted in <FIG>, data such as a street address may be transformed into a latitude-longitude pair and then further transformed to minimize the precise location.

In Column <NUM>, a transformation function has been applied to a subset of records within the data set <NUM>, replacing some of the telephone numbers <NUM> with the string "unlisted. " In some embodiments, data set <NUM> may contain a field that indicates whether a telephone number <NUM> is unlisted, and the transformation function may transform the telephone number <NUM> based on the contents of that field. Further, in some embodiments, the data set <NUM> may include user privacy preferences that indicate whether to minimize particular items of information, such as a particular user's address or telephone number.

In Column <NUM>, an encrypting transformation function has been applied to the SSNs <NUM> of data set <NUM>. The encrypting transformation function is an example of a reversible transformation function. A reversible transformation function has a corresponding reverse transformation function, such as a decrypting transformation function, that can be applied to the presented minimized data to recover the original protected data. A reversible transformation may be used to further restrict access to the original protected data. For example, in some embodiments, the presentation server <NUM> of <FIG> may interact only with a minimized data store <NUM>, and may not have access to the original item of protected data in the protected data store <NUM>. The presentation server <NUM> may nonetheless present the original item by requesting that the dynamic data minimization server <NUM> de-minimize an item of encrypted data, and the dynamic data minimization server <NUM> may in turn apply the reverse transformation function to produce the de-minimized item. In some embodiments, the presentation server <NUM> may omit presentation of transformed data in the user interface <NUM>, but may retain the transformed data and utilize it when processing de-minimization requests. Further examples of reversible transformation functions include hashing transformation functions, ciphering transformation functions, and other functions producing a result that can be utilized to obtain the original data.

Button <NUM> may be used to generate a request to provide protected data corresponding to the minimized data presented in the user interface <NUM>. In some embodiments, a separate button <NUM> may be provided for each column of minimized items, or for individual rows of data. Any other suitable user interface element or elements may be used to obtain requests to de-minimize the data or provide the original protected data.

The transformation functions described with regard to <FIG> represent only a subset of the transformation functions within the scope of the present disclosure. For example, a transformation function may add random "noise" to a quantifiable item of protected data, in a manner that preserves the general characteristics of the data set <NUM> for analysis but does not allow identification of any particular item of protected data. As a further example, a transformation function may transform items of protected data into ranges or "buckets," such that precise salary information is replaced by ranges such as "$<NUM>,<NUM> to $<NUM>,<NUM>," "$<NUM>,<NUM> to $<NUM>,<NUM>," and so forth. As a still further example, a transformation function may identify an association between two data fields, such as names and birthdates, and may dissociate the fields such that names and birthdates from the data set <NUM> are randomly paired. The example transformation functions provided herein are thus understood to be not limiting.

<FIG> and <FIG> are block diagrams of the network topology of <FIG> illustrating processing of requests to minimize and provide protected data in accordance with aspects of the present disclosure. With reference now to <FIG>), a client computing device <NUM> may transmit a request for data. Illustratively, the request may seek data without regard to whether the requesting entity (e.g., a requesting user or user group) has appropriate rights to view protected information in the requested data and/or needs to have all of the protected information displayed in order to preserve privacy rights of individuals (e.g., such as in a healthcare environment).

At (<NUM>), the presentation server <NUM> retrieves the data, including one or more items of protected information, from one or more protected data stores <NUM>, which returns the requested data at (<NUM>). At (<NUM>), the presentation server determines whether and which of the requested data items will be minimized. Illustratively, the set of data items to minimize may be determined based on rules or other criteria set up by an administrator of the protected data store <NUM>, by a supervisor or administrator of the requesting entity, and/or automatically by the system, such as based on default rules. For example, minimization rules may specify that certain types of data, such as names, addresses, telephone numbers, and the like, are to be minimized when data is initially requested. The minimization rules may further specify permissions to grant or deny to requesting entities with various access rights. For example, a rule may specify that requesting entities with certain access rights will receive minimized names and telephone numbers, will be granted permission in response to a request to de-minimize names, and will be denied permission in response to a request to de-minimize telephone numbers. "Access rights" or "access levels," as used herein, shall be understood to include such permissions.

In some embodiments, the presentation server <NUM> may determine an access level associated with the request, or (as described above) may obtain the access level with the request. In these embodiments the presentation server <NUM> may determine whether to fulfill the request, whether to minimize items of protected information, or which items of protected information to minimize, based on the determined access level. For example, the presentation server <NUM> may determine that a request corresponds to a particular stage of an investigation, and accordingly determine which items of protected information should be minimized in the response, and particular minimization processes to apply to each type of data items and/or particular data items. For example, minimization rules may indicate a first type of minimization (e.g., encrypting) is to be applied to a first data items of a first type (e.g., Social Security Numbers) in a set of requested data requested by a particular user, while determining that a second type of minimization (e.g., masking all but a first character) of second data items of a second type (e.g. last name) is applied to the set of requested data. Thus, minimization methods may be customized for different types of data within a particular data set. Furthermore, even within data items of a particular type in a data set (e.g., a list of <NUM> telephone numbers in a data set including information on <NUM> individuals), the minimization process selected for a particular data item (e.g., one phone number of the <NUM>) may be different than the general minimization process selected from the remaining data items of that type (e.g., the other <NUM> phone numbers and have the last <NUM> digits randomized based on a minimization rule set by an organization that is accessing the data). For example, the one phone number may have special permissions associated with it (or the entire individual data record associated with it), such as in an access control list, that indicates a higher or lower level of minimization. For example, the permissions associated with that data item may indicate that it is top secret and, thus, all digits of the phone number may be randomized (or minimized by some other method). Accordingly, minimization processes applied to data items may be customized extensively to requested data sets based on many factors in order to provide an optimal level of de-personalization of data items within the returned data set, such as to meet or exceed privacy requirements associated with the data set.

In some embodiments, the interaction at (<NUM>) may be carried out prior to the interactions at (<NUM>) and (<NUM>). That is, the presentation server may determine whether and how to fulfill the request prior to retrieving the requested data from the protected data store <NUM>.

At (<NUM>), the presentation server <NUM> requests minimization of some or all of the items of protected data retrieved at (<NUM>). Thereafter, at (<NUM>), the dynamic data minimization server <NUM> determines the transformation function to use for a particular item of protected information. Illustratively, the dynamic data minimization server <NUM> may determine the transformation function based on the particular item of protected information, the access level, other content of the request, or other information. For example, the dynamic data minimization server <NUM> may determine that a credit card number must always be encrypted, or that a request associated with a higher level of access corresponds to a function that provides a lower amount of transformation.

At (<NUM>), the dynamic data minimization server <NUM> applies the determined transformation function to the item of protected information to produce an item of minimized information. For example, as described above with reference to <FIG>, the minimization server may transform the surname "Smith" into "S. " by truncating the name after the first character and appending a period, apply a hashing function to transform a Social Security Number into an encrypted hash, or perform other transformations as described above.

At (<NUM>), the dynamic data minimization server <NUM> returns items of minimized information corresponding to the request at (<NUM>). Thereafter, at (<NUM>), the presentation server generates and outputs a user interface including the minimized data, as described above.

In some embodiments, information stored in the protected data store <NUM> may already be minimized. For example, the protected data store <NUM> may store passwords, SSNs, or credit card numbers in encrypted formats to further secure these data in the event of a breach. The information returned at (<NUM>) may thus already be transformed. In these embodiments, the presentation server at (<NUM>) may determine whether the data should be de-minimized, and may request de-minimization of the data rather than minimization. De-minimization is described in more detail below with reference to <FIG>.

Turning now to <FIG>, at (<NUM>), the client computing device may transmit a request for protected data corresponding to some or all of the minimized data received at (<NUM>). Illustratively, the request may be transmitted via the user interface <NUM> depicted in <FIG>. At (<NUM>), the presentation server <NUM> determines whether to grant the request. The presentation server <NUM> may determine that all, part, or none of the request should be granted. In some embodiments, the determination may be based on the access level associated with the request at (<NUM>), or an access level may be determined or obtained corresponding to the request at (<NUM>).

In embodiments where all or part of the request is granted, at (<NUM>), the presentation server <NUM> requests the protected data from the protected data store <NUM>, which returns the protected data at (<NUM>). At (<NUM>), the presentation server <NUM> generates and outputs a user interface for display of the protected data to which access has been granted. In some embodiments the presentation server <NUM> may retain the protected data retrieved at (<NUM>), in which case the interactions at (<NUM>) and (<NUM>) may be omitted and the presentation server <NUM> fulfills the request without further data retrieval.

<FIG> and <FIG> are block diagrams of the network topology of <FIG> illustrating processing of requests to minimize and de-minimize protected data in accordance with alternative embodiments of the present disclosure. With reference now to <FIG>), a client computing device <NUM> transmits a request for data in similar fashion to that described with reference to <FIG>. In the embodiment illustrated in <FIG>, however, the presentation server <NUM> at (<NUM>) requests minimized data from an minimized data store <NUM> in order to fulfill the request at (<NUM>). At (<NUM>), the minimized data store <NUM> returns the request, and at (<NUM>) the presentation server <NUM> generates and outputs a user interface, such as the user interface <NUM> of <FIG>, for display of the minimized data.

Turning now to <FIG>), the client computing device <NUM> transmits a request to access the protected data corresponding to the minimized data presented at (<NUM>). At (<NUM>), the presentation server <NUM> determines whether to grant the request, in similar fashion to the determination described above with reference to <FIG>. In embodiments where the presentation server <NUM> determines to grant the request, at (<NUM>) the presentation server <NUM> requests that the minimization server <NUM> de-anonymize the requested data.

At (<NUM>), the dynamic data minimization server <NUM> determines a reverse transformation function. Illustratively, the dynamic data minimization server <NUM> may maintain a log or transaction history of the transformation functions used to minimize data in the minimized data store <NUM>, and may identify a reverse transformation function based on the function originally used to transform the protected data. In some embodiments, information regarding transformation functions or reverse transformation functions may be stored in the minimized data store <NUM>, and the presentation server <NUM> may retrieve and provide this information with the de-minimization request.

At (<NUM>), the dynamic data minimization server <NUM> applies the reverse transformation function to the minimized data to produce de-minimized data, which it provides to the presentation server <NUM> at (<NUM>). At (<NUM>), the presentation server <NUM> generates and outputs a user interface to display the de-minimized data.

Variations on the interactions depicted in <FIG> are within the scope of the present disclosure. For example, in some embodiments, the dynamic data minimization server <NUM> may interact directly with protected data stores <NUM> or the minimized data store <NUM>, and the presentation server <NUM> may instead request data via the dynamic data minimization server <NUM>. As a further example, although not depicted in <FIG>, the dynamic data minimization server <NUM> may be utilized to transform a protected data store <NUM> into a minimized data store <NUM> in accordance with aspects of the present disclosure, or may be utilized when transforming protected data for storage in the minimized data store <NUM>.

In further embodiments, the presentation server <NUM> may determine whether or which protected data items to minimize based on previous requests for the protected data items. For example, the presentation server <NUM> may maintain a history of de-minimization requests, and may determine that a request for a particular set of data items is frequently followed by a request to de-minimize a particular protected item in the set. The presentation server <NUM> may thus determine that the particular protected item should not be minimized when fulfilling requests for the set of data items. As a further example, the presentation server <NUM> may determine that minimizing a particular protected data item seldom results in a request to provide the original protected data, and accordingly that the protected data item may be minimized for a broader set of access levels. In further embodiments, the dynamic data minimization server <NUM> may determine a transformation function based on an access level associated with the request. For example, the dynamic data minimization server <NUM> may apply a masking function that masks location information entirely, or may apply a transformation function that reduces the precision of location information, depending on the access level.

With reference now to <FIG>, an example routine <NUM> for minimizing an item of protected information will be described. The routine <NUM> may be carried out, for example, by the dynamic data minimization server <NUM> of <FIG>. At block <NUM>, an item of protected information may be obtained. For example, the item of protected information may be obtained as part of a request to minimize the item of protected information, or as part of a request to write the item to a minimized data store.

At block <NUM>, a transformation function may be determined. The transformation function may be determined based on characteristics of the item of protected information. For example, an item of protected information may be quantifiable, such as a glucose level, a test score, an annual income, or a clothing size. A transformation function may thus be determined that reduces the precision or accuracy of the quantification. In some embodiments, a transformation function may be determined based on an access level, as described above, or based on a degree of privacy associated with the item of protected information. For example, an encryption or hashing function may be determined for an item of protected information such as a Social Security number or a credit card number. In further embodiments, a reversible transformation function may be determined.

At block <NUM>, the transformation function may be applied to the item of protected information to produce in item of minimized information. In some embodiments, multiple items of protected information may be obtained at block <NUM>, and blocks <NUM> and <NUM> may be carried out iteratively to determine and apply a number of transformation functions.

At block <NUM>, the item or items of minimized information may be output. In some embodiments, the transformation function or an identifier corresponding to the function may be output to enable subsequent reverse transformations, or the applied transformation function may be logged to a data store.

With reference now to <FIG>, an example of a routine <NUM> for accessing an item of protected information that corresponds to an item of minimized information will be described. The routine <NUM> may be carried out, for example, by the presentation server <NUM> of <FIG>. In some embodiments, blocks of the routine <NUM> may instead be carried out by the dynamic data minimization server <NUM>.

At block <NUM>, a request to access an item of protected information may be obtained. The request may provide an item of minimized information or an identifier corresponding to an item of minimized information, and may further provide an access level, password, or other identifier used to validate the request.

At block <NUM>, an access level associated with the request may be determined. In embodiments where the request provides an access level, the access level in the request may be validated. In other embodiments, the access level may be determined based on, for example, the source of the request, the content of the request, a history of previous requests, the item of protected data being requested, or other factors or combinations of factors.

At decision block <NUM>, a determination is made as to whether the access level associated with the request permits access to the item of protected information. As described above, the determination may be made based on various rules or preferences specified by the provider of the item of protected information or by an administrator of the requesting entity, for example. The rules may further be customized based on criteria such as role or job title, security clearance level, connection type (e.g., a request to access protected information may be denied if it originates from a mobile device or an insecure network), physical location (e.g., a request to de-minimize health records may only be granted within the hospital), or other factors. If the determination is made that the request should not be granted, the routine <NUM> branches to block <NUM>, where output may be provided indicating that request has been denied, and thereafter the routine ends. In some embodiments, block <NUM> may be omitted and the routine <NUM> may silently end without providing output. If the determination is that the request should be granted, then at block <NUM> the corresponding item of protected information may be obtained. Illustratively, the item of protected information may be retrieved from a protected data store <NUM>, or from a previous retrieval of data from the protected data store <NUM>. At block <NUM>, the item of protected information may be output in response to the request, and thereafter the routine ends.

<FIG> is provided as an example, and that the present disclosure includes various combinations or variations in addition to the non-limiting example of routine <NUM>. For example, in some embodiments, a determination may be made that the access level does not permit access to the item of protected information, but does permit access to an item of minimized information that was minimized by a different transformation function. The item of less minimized information may thus be retrieved or generated and provided in response to the request. In further embodiments, a user interface may be generated for display that includes the item of protected information as well as other open or minimized data.

With reference now to <FIG>, an example of a routine <NUM> for de-minimizing an item of minimized information will be described. The de-minimizing routine <NUM> may be carried out, for example, by the dynamic data minimization server <NUM> of <FIG>.

At block <NUM>, a request for an item of protected information may be obtained. The request may provide an item of minimized data to be de-minimized, or may request an item of protected information without specifying how it is produced. In some embodiments, the request may provide a transformation function or an identifier that identifies the function used to produce the item of minimized data. The request may further provide an access level or other information used to determine whether the request should be granted.

At decision block <NUM>, a determination is made as to whether the access level associated with the request permits access to the item of protected information. If not, the routine <NUM> branches to block <NUM>, where output may be provided indicating that request has been denied, and thereafter the routine ends. In some embodiments, block <NUM> may be omitted and the routine <NUM> may silently end without providing output.

If the determination at decision block <NUM> is that the request should be granted, then at block <NUM> a reverse transformation function may be identified. Illustratively, the reverse transformation function may be identified based on a transformation function used to produce an item of minimized information associated with the request. The transformation function may be obtained, for example, from the request, from a log of minimization requests, or by analyzing the item of minimized information.

At block <NUM>, the reverse transformation function may be applied to produce an item of de-minimized information, which corresponds to the item of protected information originally used to produce the item of minimized information. At block <NUM>, the item of protected information may be output in response to the request, and thereafter the routine ends.

<FIG> is a block diagram of an example electronic device <NUM> in communication with various devices. Components of the network topology <NUM>, such as the dynamic data minimization server <NUM>, presentation server <NUM>, and/or client computing device <NUM>, typically include some or all of the components of electronic device <NUM>, as discussed in further detail below.

As illustrated in <FIG>, electronic device <NUM> can include a bus <NUM> or other communication mechanism for communicating information, and one or more hardware processors <NUM> (denoted as processor <NUM> for purposes of simplicity) coupled with bus <NUM> for processing information. Hardware processor <NUM> can be, for example, one or more general-purpose microprocessors or it can be a reduced instruction set of one or more microprocessors.

Electronic device <NUM> also includes a main memory <NUM>, such as a random access memory (RAM) or other dynamic storage device, coupled to bus <NUM> for storing information and instructions to be executed by processor <NUM>. Main memory <NUM> also can be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor <NUM>. Such instructions, after being stored in non-transitory storage media accessible to processor <NUM>, render electronic device <NUM> into a special-purpose machine that is customized to perform the operations specified in the instructions.

Electronic device <NUM> further includes a read only memory (ROM) <NUM> or other static storage device coupled to bus <NUM> for storing static information and instructions for processor <NUM>. A storage device <NUM>, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc. is provided and coupled to bus <NUM> for storing information and instructions.

Electronic device <NUM> can be coupled via bus <NUM> to an output device <NUM>, such as a cathode ray tube (CRT), liquid crystal display, or touch screen, for displaying information to a computer user. In some embodiments, an input device <NUM>, including alphanumeric and other keys, is coupled to bus <NUM> for communicating information and command selections to processor <NUM>. Another type of user input device is cursor control <NUM>, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor <NUM> and for controlling cursor movement on output device <NUM>. The input device typically has two degrees of freedom in two axes, a first axis (for example, x) and a second axis (for example, y), that allows the device to specify positions in a plane. In some embodiments, the same direction information and command selections as cursor control can be implemented via receiving touches on a touch screen without a cursor.

Electronic device <NUM> can include a user interface module to implement a graphical user interface that can be stored in a mass storage device as executable software codes that are executed by the one or more computing devices. This and other modules can include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, fields, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

In general, the word "module," as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, Lua, C or C++. A software module can be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules can be callable from other modules or from themselves, and/or can be invoked in response to detected events or interrupts. Software modules configured for execution on computing devices can be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disc, or any other tangible medium, or as a digital download (and can be originally stored in a compressed or installable format that requires installation, decompression, or decryption prior to execution). Such software code can be stored, partially or fully, on a memory device of the executing computing device, for execution by the computing device. Software instructions can be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules can be comprised of connected logic units, such as gates and flip-flops, and/or can be comprised of programmable units, such as programmable gate arrays or processors. The modules or computing device functionality described herein are preferably implemented as software modules, but can be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that can be combined with other modules or divided into sub- modules despite their physical organization or storage.

Electronic device <NUM> can implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs electronic device <NUM> to be a special-purpose machine. According to some embodiments, the operations, functionalities, and techniques and other features described herein are performed by electronic device <NUM> in response to processor <NUM> executing one or more sequences of one or more instructions contained in main memory <NUM>. Such instructions can be read into main memory <NUM> from another storage medium, such as storage device <NUM>. In alternative embodiments, hard-wired circuitry can be used in place of or in combination with software instructions.

The term "non-transitory media" as used herein refers to any non-transitory media storing data and/or instructions that cause a machine to operate in a specific fashion. Such non-transitory media can comprise non-volatile media and/or volatile media. Non-volatile media can include, for example, optical or magnetic disks, such as storage device <NUM>. Volatile media can include dynamic memory, such as main memory <NUM>. Common forms of non-transitory media can include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.

Non-transitory media is distinct from, but can be used in conjunction with, transmission media. Transmission media can participate in transferring information between storage media. For example, transmission media can include coaxial cables, copper wire and fiber optics, including the wires that comprise bus <NUM>.

Various forms of media can be involved in carrying one or more sequences of one or more instructions to processor <NUM> for execution. For example, the instructions can initially be carried on a magnetic disk or solid state drive of a remote computer. A modem local to electronic device <NUM> can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. The instructions received by main memory <NUM> can optionally be stored on storage device <NUM> either before or after execution by processor <NUM>.

Electronic device <NUM> can also include a network interface <NUM> coupled to bus <NUM>. Network interface <NUM> can provide a two-way data communication coupling to a network link <NUM> that can be connected to a local network <NUM>. For example, network interface <NUM> can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, network interface <NUM> can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, network interface <NUM> can send and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link <NUM> can typically provide data communication through one or more networks to other data devices. For example, network link <NUM> can provide a connection through local network <NUM> to a host computer <NUM> or to data equipment operated by an Internet Service Provider (ISP) <NUM>. ISP <NUM> in turn can provide data communication services through the world wide packet data communication network now commonly referred to as the "Internet" <NUM>. Local network <NUM> and Internet <NUM> can both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link <NUM> and through network interface <NUM>, which carry the digital data to and from electronic device <NUM>, can be example forms of transmission media.

Electronic device <NUM> can send messages and receive data, including program code, through the network(s), network link <NUM> and network interface <NUM>. In the Internet example, a server <NUM> can transmit a requested code for an application program through Internet <NUM>, ISP <NUM>, local network <NUM> and network interface <NUM>. The received code can be executed by processor <NUM> as it is received, and/or stored in storage device <NUM>, or other non-volatile storage for later execution. In some embodiments, server <NUM> can provide information for being displayed on a display.

Embodiments of the present disclosure have been described herein with reference to numerous specific details that can vary from implementation to implementation. Certain adaptations and modifications of the described embodiments can be made. Other embodiments can be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. It is intended that the specification and examples be considered as example only, with a true scope of the present disclosure being indicated by the following claims. It is also intended that the sequence of steps shown in figures are only for illustrative purposes and are not intended to be limited to any particular sequence of steps. As such, it is appreciated that these steps can be performed in a different order while implementing the example methods or processes disclosed herein. Further, the inventions illustratively disclosed herein suitably may be practiced in the absence of any element or aspect which is not specifically disclosed herein.

Depending on the embodiment, certain acts, events, or functions of any of the methods described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules and method elements described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules and steps have been described above generally in terms of their functionality. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The elements of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM or any other form of computer-readable storage medium known in the art. A storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.

Conditional language used herein, such as, among others, "can," "might," "may," "e.g." and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment. The terms "comprising," "including," "having," "involving" and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations and so forth. For example, a general purpose computer comprising one or more processors should not be interpreted as excluding other computer components, and may possibly include such components as memory, input/output devices, and/or network interfaces, among others. Also, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some or all of the elements in the list.

Disjunctive language such as the phrase "at least one of X, Y or Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y or Z, or any combination thereof (e.g., X, Y and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as "a" or "an" should generally be interpreted to include one or more described items. Accordingly, phrases such as "a device configured to" are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, "a processor configured to carry out recitations A, B and C" can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

Claim 1:
A computer-implemented method comprising:
obtaining (<NUM>), by a computing device (<NUM>, <NUM>), entity data associated with an entity, the entity data including at least an item of protected information;
applying (<NUM>), by the computing device (<NUM>, <NUM>), a transformation function to the item of protected information, or to a portion of the item of protected information, to produce an item of minimized information, wherein the item of minimized information preserves one or more characteristics of the item of protected information while reducing a determinable association between the item of minimized information and the entity;
generating, by the computing device (<NUM>, <NUM>), in response to a first request of a requesting entity to access at least a portion of the entity data, user interface data renderable to depict a user interface (<NUM>) including at least the item of minimized information and excluding the item of protected information;
rendering the user interface data to the requesting entity to depict the user interface (<NUM>);
receiving, by the computing device (<NUM>, <NUM>), a second request of the requesting entity to provide at least the item of protected information corresponding to the item of minimized information;
determining, based at least in part on an access level associated with the second request, wherein the access level is determined based at least in part on previous requests to access the item of protected information, that the item of protected information should be provided in response to the request; and
updating, by the computing device (<NUM>, <NUM>), the user interface data to include the item of protected information.