JP2020519210A - Systems and methods for implementing centralized privacy controls in decentralized systems - Google Patents

Abstract

Data values of data related to systems, computer-unreadable media, and methods to improve privacy and anonymity, data subjects are used and stored in distributed ledger data structures such as blockchain. While minimizing the risk of non-anonymization by unauthorized parties, data containing similar identifiers related to the data subject can be used to identify the authorized party's purpose, duration, location, and EU General Data Protection Regulation ( Allowing access to only authorized data, such as GDPR) and other similar regulatory regimes, such as criteria for obscuring certain values, allows disclosure to authorized parties. The techniques described here maintain the level of privacy, anonymity, while maintaining universality for distributed storage of processed data, auditability, and proof dictated by blockchain and other distributed ledger technologies (DLTs). Can meet the sex. [Selection diagram] Figure 1Z-1

Description

[Cross reference to related applications]
[1] This application claims priority to US Patent Application No. 15/963,609 of "Systems and Methods for Implementing Centralized Privacy Control in Decentralized Systems" filed April 26, 2018. To do.
Filed April 28, 2017 US Provisional Patent Application No. 62/491,294 entitled "Anonosizing for Healthcare Data Collection and Sharing".
Application July 21, 2017 US Provisional Patent Application No. 62/535,601 entitled "Dynamic Pseudonymization with Pseudonymization".
U.S. Provisional Patent Application No. 62/554,000 entitled "Anonos Global Data Protection Regulation Compliant Analytics" filed September 4, 2017
U.S. Provisional Patent Application No. 62/580,628 entitled ``Anonos Big Privacy Compressible Dynamic De-Identifiers'' filed November 2, 2017
U.S. Provisional Patent Application No. 62/644,463 entitled ``Anonos BigPrivacy GDPR Compliant Block Chain Systems and Methods'' filed March 17, 2018
US Provisional Patent Application No. 62/649,103, entitled "Big Privacy Data Compliance in the Cloud," filed March 28, 2018, is hereby incorporated by reference.

[Field of Invention]
[2] The present disclosure generally relates to improving data security, privacy, and accuracy by using dynamically changing identifiers to identify elements of data, such as stored in Distributed Ledger Technology (DLT), such as blockchain. Regarding rendering. (Note: In this document, the terms "privacy" and "anonymous" are used interchangeably to refer to data protection, privacy, anonymity, pseudonym, ambiguity, and other behaviors. Or an individual, such as a group of corporations, quarantines, quarantines, or edits information about himself from unauthorized parties, thereby selectively providing information about himself. , And used to refer to a data storage element that contains the consensus of synchronized digital data, and may be geographically dispersed across multiple sites, countries, or institutions, for example, “Distributed Ledger Technology” DLT use cases. Includes blockchain, cryptocurrencies, smart contracts, and even distributed file storage.

[03] This section is intended to provide the context or context of the invention as claimed.
The descriptions in this document include concepts that may be pursued, but are not necessarily those that have been previously conceived, implemented, or described.
Accordingly, unless otherwise stated in this section, what is described in this section is prior art by virtue of its inclusion in this section rather than prior art in the description and claims of this application. Absent.

[04] There is a contradiction between these three.
(I) Respect the goals of the parties to maximize the value of the data and the privacy rights of individuals.
(Ii) The individual's goal of protecting the privacy rights of individuals and the goal of benefiting from highly personalized services. And (iii) the goals of US and international government agencies to promote research and commerce and the protection of civil rights.

[05] One goal of non-healthcare stakeholders is to reach "highly qualified" prospects. A potential buyer with the necessary financial resources, motivation, and purchasing authority.
Merchants consider it more profitable to reach undifferentiated prospects because they are more likely to complete a deal with a qualified prospect given the interest, predisposition, and means of closing the deal. Pay more to reach qualified prospects.
The level of personalization/customization of the product for prospective customers, which is directly related to the likelihood of completing a transaction, is enhanced by the depth and scope of information available about individual prospective customers. One of the goals of health care professionals is to conduct research on health and/or illness with the goal of advancing discovery in applications that may improve human health.

[06] The advent and dissemination of computer networks, Internet, intranets, and supporting technology developments have made widely available cost-effective technologies for collecting, transmitting, storing, analyzing, and using information in electronic form. became.
As a result, entities can now easily collect and analyze vast amounts of information.
However, this created tension between (a) and (b).
(A) There is an increasing amount of information available to qualify prospects, develop personalized/customized products for potential customers, and/or conduct health-related or other research.
(B) Poor personal security, anonymity, or privacy, often unaware of the existence of many data elements and often having little or no effective control of those data elements.

[07] Data elements can be collected both online and offline through various sources. (Internet browsing and other activities such as activities on social networking sites, electronic or digital records, email, participation in rewards, bonus card programs to track purchases and locations, physical stores and e-commerce websites. (Activities and purchases)
Merchants, healthcare and other service providers, governments, and other organizations use this vast amount of data that is collected, stored, and analyzed to suggest or find patterns and correlations and draw useful conclusions. I will.
This data is sometimes referred to as "big data" because of the amount of information that can be collected today.
This big data analysis allows entities to unlock and maximize the value of their data.
Health-related entities may access big data to conduct medical research. However, behavioral marketing and big data analytics have made stakeholder privacy and anonymity much lower.

[08] Attempts at reconciling the contradiction between privacy/anonymity and value/personalization/research often involved using alternative identifiers rather than real names or identities.
However, these alternative identifiers are typically statically assigned and long-lived.
Static identifiers can be more easily tracked, identified, cross-referenced to confirm the true identity, and used to confirm additional data about the subject associated with a data element without the consent of the parties involved.
Privacy and information professionals are concerned that re-identification techniques may be used on data associated with static identifiers, and may be limited to specific computers, devices, or activities (that is, associated static identifiers). The identifiable data (through) is actually kept anonymous or protected anonymously.
If the identifier does not change over time, the adversary entity has unlimited time to add, analyze, and associate additional or exogenous data with the persistent identifier. In addition, that time provides the adversary entity with the opportunity to carry out brute force attacks used against the encrypted data.

[09] According to a 2011 McKinsey Global Institute report:
・Retailers who make the best use of big data may raise operating profit margin by more than 60%. ;
・There is great potential for utilizing big data in the public sector. If US healthcare institutions creatively and effectively use big data to improve efficiency and quality, this sector will generate over $300 billion in value each year, two-thirds of which will cost US healthcare. Will be reduced by about 8%. ;
In developed European countries, government managers could save over €100 billion ($149 billion) on operational efficiency through the use of big data. ;
By using big data that can use the location information of individuals, there is a possibility of obtaining a consumer surplus of $600 billion.

[10] Many potential benefits of big data include ambiguity about the ownership/use rights of the underlying data, tensions on the privacy of the underlying data, and secondary (compared to primary) sources. It is not fully realized due to erroneous data collected from, and/or results of inaccurate analysis inferred from the activities of the parties without the active participation or verification of the parties.

[11] Distributed networks or platforms, including linked networks or platforms on a peer-to-peer or other decentralized basis, including systems that do not require authorization or distributed ledger technologies such as blockchain. The explosion of popularity has further increased the difficulty of maintaining the desired level of privacy/anonymity for users, while properly extracting information value by authorized third parties, personalized services It is possible to provide. Providing a high level of privacy/anonymity, at least because of the inevitable static nature of the information recorded in such distributed ledgers, especially due to the requirements of distributed ledger technology regarding immutability, auditability, and verification. Has never been possible.

[12] What is needed is to overcome the limitations of static and/or permanent privacy/anonymity and security systems, and the accuracy of data for exchange, collection, transactions, analytics and other uses. Systems, methods, and devices that improve, for example, applications that store data in a distributed fashion using distributed ledger technology such as blockchain. In other words, privacy/anonymity-enhancing techniques, such as those described herein, allow authorized users to "give away" such information when given certain times and contexts. Providing tools that allow unlocking the "true" meaning can help reconcile the tension between auditable and immutable information stores.

[13] Embodiments of the present invention can improve the privacy and security of data by allowing subjects to which the data relates to be "dynamically anonymous", ie, as anonymous as desired. Embodiments of the present invention create, access, use (eg, collect, process, copy, analyze, combine, modify, distribute, etc.), store, erase data with increased privacy, anonymity, and security. Includes systems, methods, and apparatus thereby facilitating the availability of more qualified and accurate information. Also, embodiments of the present invention allow for the delivery of time, geographical, and/or limited purpose information to recipients, where the data is allowed to be shared with third parties. It can facilitate sharing information in a dynamically controlled manner. Embodiments of the present invention may also be used in distributed networks built on blockchain or other distributed ledger technologies that require immutability and auditability of records over time.

[14] Storage and erasure may be done in terms of the data in terms of the present invention if it is easily accessible for use with electronic data as compared to existing systems (eg, collect, process, copy, analyze, combine, modify, distribute, etc.). Embodiments may use dynamically changing de-identifiers (“DDIDs”), people, places, or things (eg, events, documents, contracts, or smart contracts), data directly or indirectly related or related. Allows a data subject (“Data Subject”) and/or actions, activities, processes and/or characteristics related to a Data Subject, a unique time period, and a data subject to be “dynamically anonymous”.
As used herein, "Dynamically anonymous" and "Dynamic Anonymity" refer to a user's ability to remain anonymous until a decision is made not to remain anonymous, and only the intended information is for one or more purposes. Shared with one or more actions, activities, processes, or characteristics, whereby embodiments of the present invention, under the control of a data subject or control entity, which may be a trusted party or proxy, It enables the data subject's ability to maintain a flexible level of privacy.

[15] Embodiments of the invention may use DDIDs to prevent retention of data.
Sometimes referred to as metadata that provides information about one or more aspects of a Data Subject and data attributes that reflect the actions, activities, processes, and characteristics associated with the Data Subject to third parties.
(For example, and not by way of limitation, by means of creation, purpose, creation date and time, identification of the Data Subject and creator of the data attribute, where the data attribute was created, the criteria used to create it, or use of the data attribute, etc. )
This is due to the fact that something needs to be attached (or associated) to the metadata in order to establish a continuous record of the information associated with one or more specific data attributes.
"Data", "attributes", "elements", or similar terms used in this application include:
I structured data (data of a predetermined structured schema),
(Ii) Unstructured data (iii) Metadata (iv) Other data (v) Any of the above types Data initially recorded in analog format but later converted to digital format

[16] Embodiments of the present invention use a first DDID at a time for a specific purpose with respect to a first data subject, action, activity, process, and characteristic, and then associate it with a first Data Subject. And use the second DDID to perform actions, activities, processes, and characteristics for different purposes,
Use the first DDID in association with the second Data Subject, action, activity, process, and characteristic, for other purposes.

As a result, different DDIDs are associated with the same data subject, action, activity, process and/or characteristic and/or the same DDID is not Used for Subject, Action, Activity, Process, Characteristics, Purpose.

[17] Embodiments of the present invention may be used by Data Subjects at different points in time for various actions, activities, processes or characteristics to track and record different associated DDIDs.
This allows you to store, select, and retrieve information applicable to a particular action, activity, process or characteristic, and a particular data subject.
Conversely, the system uses DDIDs and lacks the information available outside of the system to determine the relationships between DDIDs and Data Subjects, actions, activities, processes, and thus third parties outside the system. May not be able to effectively hold and aggregate the data.

[18] Each DDID can be associated with one or more data attributes as follows for a particular action, activity, process, or characteristic.
a) Information that reflects the action, activity, process, or characteristic associated with the data subject while associated with the current DDID (eg, the current web of the data subject while associated with the current DDID). Browse information that reflects the activity of the base) DDID is replaced by another DDID.
b) Information about past actions, activities, processes, or characteristics that were previously associated with a data subject associated with multiple previous DDIDs.
(Example: A data subject shares pricing information with an e-commerce website that it collected from a website while associated with a previous DDID in a previous browsing session.)
(C) new information (eg, a new desired size for the purchase of the currently desired clothes) to help facilitate the desired action, activity, process, or characteristic on behalf of the data subject while associated with the current DDID. E-commerce website showing colors).
For the purposes of this document, the combination of the DDID and the data element associated with the DDID of the temporally unique period is called the temporal data representation "TDR".

[19] From the perspective of implementation of an embodiment of Dynamic Anonymity, which is a closed system, the DDID intended to represent the ID of the Data Subject, that is, the “primary identifier”, is temporary during the DDID allocation period to the data subject. Must be uniquely unique. -That is, no two existing Data Subjects can have the same primary identifier DDID at the same time.
The DDID Transient Uniqueness requirement applies when it is desirable for the separation of IDs in a Data Subject to be represented by a DDID. If you want to represent the elements other than the separability of the ID of the data subject by the DDID, you can assign the DDID accordingly and represent the association, relationship, etc. of the purpose.
DDIDs can be instantiated in two ways.
(I) Within the implementation of the present invention (ii) Depending on the identifier created externally, the "temporary unique" requirement ("Cookie" or other unique identifier) Data Subject ID separation is represented by DDID If it is desirable to do so, it will effectively serve as a DDID when first assigned to a visitor by the website.

[20] Cookies are small pieces of data that are generally sent from websites and stored in the data subject's web browser while the data subject is browsing the website. Each time the Data Subject returns to the website, the browser sends back a cookie to the server associated with the website, notifying that the Data Subject has returned to the website. However, because the cookie acts as a DDID, the browser ensures that the cookie sent by the website is not retained between browsing sessions. (Copy the user's cookies, cache, and browsing history files to an anonymous system server and delete them from the user's computer.)
Make sure that a new cookie is assigned for each browsing session.
As such, the various cookies issued by the website (this embodiment acts as a DDID that represents the separation of the data subject's ID) are created "externally" to the system, and Remember the stateful information or aggregate the browsing activity of the Data Subject as each is considered unrelated by the website.
This leaves the Data Subject dynamically anonymous for as long as needed.

[21] As mentioned in the example embodiments above, the Dynamic Anonymity system may collect and maintain information regarding different browsing sessions, various actions, activities, processes or characteristics associated with cookies. (In this example, it acts as a DDID that represents the separation of the data subject's ID.)
Then, until the decision is made to keep the Data Subject anonymous, or instead, the combined information in the Data Subject's aggregated data profile is stored, at which point only the required information from the Data Subject's aggregated data is saved. The profile you retrieve must be shared with one or more desired stakeholders in relation to one or more actions, activities, processes or characteristics.
In this exemplary embodiment of the invention, the Data Subject may include determining from the entire data profile to provide information to the website (control entity) as a TDR. In the above exemplary embodiment of the invention,
Instead of using the cookie assigned by the website accessed by the data subject as the DDID (removing the dynamically changing proxy,
As a DDID, the system must use a globally unique identifier (GUID) (that is, a unique reference number used as an identifier in computer software), whether created internally or externally by the implementation of the present invention. there is.
In the above, the control over the data collection of browsing activity by the Data Subject lies with the Data Subject or other controlling entity, not the website that the Data Subject visited.
In yet another example, rather than determining when to "push" information to a website from the data profile that the Data Subject aggregates,
Websites can "pull" relevant information and associated DDID and Data Subject association information from the Data Subject's aggregate data profile when it needs the information with appropriate authorization and authentication.

[22] As another example, the task of dynamically anonymizing and controlling the transmission of relevant portions of a data subject's aggregate data profile may be handled by the data subject's client device itself.
For example, a complete view of a particular Data Subject's information, related DDID's to a Data Subject's related information can be stored on the Data Subject's client device for a defined or flexible period of time, and then stored in a central Dynamic Anonymity system. Synced (and synced with other client devices that the data subject has registered with the central anonymous system).

[23] TDRs and DDIDs may include multiple levels of abstraction for tracking and identification purposes.
A system according to some embodiments of the invention may store a TDR (DDID value and data element associated with the DDID, if any). Subject, Data Attribute, Action, Activity, Process, or Property-These allow TDRs to be later re-associated with a particular Data Subject, Data Attribute, Action, Activity, Process, or Property. Such systems facilitate the development of aggregated data profiles by referencing and using keys that reveal relationships between various DDIDs, Data Subjects, data attributes, actions, activities, processes, and characteristics. Available for.
In other words, the "Dynamic Anonymity" provided by the use of TDRs and DDIDs described in this document allows data subjects to benefit from ongoing technological advances (eg, Internet of Things (IoT), personalized medicine, etc.). Can get
You don't have to give up privacy, anonymity, security, or control.
This is achieved by:
(I) Assign dynamically changing DDIDs to Data Subjects, Actions, Activities, Processes, and Characteristics.
(Ii) Holds information about the association of DDIDs with Data Subjects, Actions, Activities, Processes, and Properties.
(Iii) Provides data subjects and control entities (trusted parties/proxies) that deterministically control access/use of association information. With dynamically mutable things, transient DDIDs, current systems, and processes (such as web browsers and data analysis engines) can't recognize relationships between unrelated or replaced data elements. There are cases.
You can use existing functionality to process the information, but without creating inferences, correlations, profiles, or conclusions, unless explicitly permitted by the data subject and trusted parties/proxy. I will.
Further, the DDID used by the embodiments of the present invention can be dynamically replaced not only at the Data Subject level or the data recording level, but also at the data element level that enables Dynamic Anonymity. This means that individuals have control over the data they share or access, enabling dynamic de-identification without "degrading" the information.

[24] Controlling information up to the data element level goes beyond the scope of control only at the data record level or the data subject level, allowing controlled information sharing during big data.
In addition, it enables a "binding relationship" between the data subject and the website or other entity that receives information about the data subject. Most existing systems collect information about unique identifiers over time.
Even if the DDID contains a certain amount of history or other information about the Data Subject, the next time the Data Subject visits the site, store, doctor, etc., the DDID will have a unique identifier, name, or email address. The Data Subject is completely different only if it is included. For example, the recipient can associate the then DDID that represents the data subject with the DDID that was previously used to represent the data subject. At that point, the recipient can interact with the data subject based on the collection of data about the data subject, but the next time the recipient encounters the data subject, the data subject will re-identify unless the data subject wishes. can not.

[25] Dynamic Anonymity also enables controlled “data fusion”.
(Here, "data fusion" is defined as what happens when data from different sources come into contact with each other and reveal new facts.)
Obfuscating the connection between the above provides controlled anonymity of data, identity (of the Data Subject and/or controlling entity) and context (eg time, purpose, location). Therefore, dynamic anonymity can also revoke or revoke access to granted rights or data. (For example, you can provide certain parties with access to the data underlying the DDID, and you can revoke access by changing the replacement key.)
To support additional authorized secondary usage without violating the rules on the Data Subject (for example, one or more DDIDs can be used to initially result in X-rays via one or more exchange keys). Accessing and changing the exchange key may later reflect the X-ray results and follow-up results.)

[26] The reason why dynamic anonymity remains attractive in the commercial market is often wondering who the Data Subject actually interacts with (the actual "real-world" identity). Because I don't. The more accurate and lean the targeting, the more likely anonymous consumers will be to react favorably to personalized services.
Therefore, Dynamic Anonymity removes the need for companies to follow data subjects in the digital world and persuade them to buy products and services they don't really need. If you use this, you will be able to expect matching sales and customers, and you will be able to generate high profits.
Currently, the best way many companies can do is to use demographics and statistics to “segment” their potential customers, but they may not know the actual interests of each individual.
Companies instead care what the Data Subject is, what the Data Subject does, and how it works. Dynamic Anonymity improves demographics by providing personalized interest from members of the segment who are qualified prospects.
With Dynamic Anonymity, the ability to allow a Data Subject to directly or indirectly control the use of data depending on an individual's privacy/anonymity preference is the difference between different data use/privacy/anonymity in such jurisdictions. Despite the requirements, it can support different treatments of data in different jurisdictions.
(Example: The European Union's "fundamental rights" and the difference in the US balance from a commercial perspective in terms of privacy rights/free expression rights/data privacy/anonymity).

[27] In medicine and related fields, Dynamic Anonymity is better than traditional approaches that use a defensive approach to protect data privacy/anonymity. -For example a masking procedure applied directly to the identifier (name, address).
Masking or statistics-based operations are applied to quasi-identifiers (eg age, gender, occupation) to reduce the possibility of re-identification by unauthorized third parties.
This defensive approach to protecting data privacy/anonymity offers a trade-off between protection against re-identification and retention of access to user information. Represents actions, activities, processes and characteristics between Data Subjects.
Its meaning can change over time and, as a result, it is necessary to identify the underlying value of the appropriate key at that time.
Therefore, Dynamic Anonymity eliminates the need to permanently irrevocably sacrifice information content to minimize the risk of loss of anonymity. Instead, Dynamic Anonymity minimizes both the risk of loss of anonymity and the amount of information lost, making most data recoverable only with authorization.

[28] The keys used by embodiments of the invention may differ depending on the use of the corresponding DDID. For example, you can use the time key (“TK”) to associate a time period for associating a DDID with a data subject, action, activity, process, and/or characteristic. That is, the association key (“AK”) can be used to reveal an association between two or more data elements or TDRs that are indistinguishable from each other because they use different DDIDs. The replacement key (“RK”) can be used when the DDID is used to replace one or more data attributes in the TDR. In this case, one or more DDIDs contained in the TDR can reference the lookup table to determine the value of one or more data attributes to be replaced.

[29] If you do not have access to the applicable TK, AK, RK, or if the third party intercepts information about one or more Data Subjects, actions, activities, processes, or characteristics, the third party cannot:
(I) In the case of the association function of the present invention, the data subject is re-identified by associating the DDID with the corresponding data attribute (including TDR).
(Ii) To know the value of the data element represented by the DDID in order to correctly understand the information in the case of the replacement function of the present invention.
Conversely, embodiments of the present invention allow a data subject or other control entity to only send data attributes specifically related to a particular action, activity, process or characteristic to one or more desired third parties. You can (The system recognizes that it is related to the Data Subject by the tracking/logging/recording function of the system.)

[30] The following terms may be used in connection with anonymizing data in accordance with various embodiments described herein.

[31] "A-DDID", "Association DDID":
The DDID (data element and value) used to convey information value in a non-specific way, according to optionally specified grouping rules, to replace the identifying data element and the dereference (point) to the value of the data element. ). Indexes used to resolve dereferences include, but are not limited to, keys, schema conversion tables, anonymous identifiers, pseudonym identifiers, tokens or other representations. A-DDID dereference grouping rules can be at least two types of grouping: number and category. Number refers to the range of numbers represented by A-DDID. Category grouping replaces "correlations" (that is, two or more related or complementary items) with the A-DDID selected to represent the correlation between the values within each grouping category.
A-DDID dereferencing rules may cover multiple fields.
For example, blood tests can cover a variety of variables that can infer the risk of heart attack.
As a result, rules can specify the different combinations (high, medium, low, etc.) needed to assign a heart attack risk to a particular category.

[32] “R-DDID”, “Replacement DDID”: Refers to a DDID that can be used to replace the identifying data element and dereference (eg, point) to the value of the data element.

[33] "Mosaic Effect" refers to the ability to re-identify a Data Subject by correlating data between seemingly anonymous datasets.

[34] In this document, information about one or more Data Subjects such as individuals, places, things, and various systems for private and secure management and use of related actions, activities, processes, and/or characteristics, A method and device are disclosed.
The systems, methods, and devices described in this document link data-related elements to independent or dependent attributes, and separate data-related elements into independent or dependent attributes to provide data subjects, actions, and activities. You can abstract data related to, processes, and characteristics. For purposes of this disclosure, attributes can be used independently or in combination with other data elements to directly or indirectly identify individuals, places, things, and related data subjects such as actions and activities. Refers to a data element.
Note that the Data Subject may have its own attributes or combination of attributes. (For example, an individual data subject's social security number, and the attribute or combination of attributes that the Data Subject shares with other data subjects.)
In some cases, an attribute can be an electronic or digital representation of a Data Subject or related actions, activities, processes, characteristics.
Similarly, an attribute may be an electronic or digital representation of information or data related to a Data Subject or related actions, activities, processes, and/or characteristics.
By separating and linking, relocating, defining, initializing, merging and extending attributes, you can form attribute combinations for specific data subjects and groups, related actions, activities, processes, and characteristics.
With respect to Data Subject, Action, Activity, Process, and Characteristics, a combination of attributes can include any combination of attributes and other data that is added to or combined with the attribute.
In addition, an attribute or combination of data attributes can identify a Data Subject, but it is not a Data Subject. -A person, legal entity, identified by a combination of attributes or data attributes, may be considered a related party in connection with that attribute because he/she is interested in it. Or it may be associated with a combination of the above attributes or data attributes.

[35] In some embodiments, a client-server structure or architecture can be utilized to enterprise wide, on-premises or public cloud, private or public hybrid cloud, or any combination of the above, which itself is virtual, Features and/or services may be provided to one or more private clients, which may be logical or physical.
These privacy clients, which may reside on the data-centric device, are accessible through the cloud network on the service provider device and may be within the cloud network or on the same computing device.
The privacy server initiates requests for such features and services by interacting with the data subject's association information, data attributes stored in a database on the hard drive or other memory elements associated with the privacy server. You may. For example, data attributes are linked to or separated into independent or dependent attributes by a privacy server that is bound to a database in response to requests for features and services from one or more private clients. Will be done. It should be noted that implementations of the present invention use a single computer or computing device as both a private server and a client, while other implementations use one or more computers in one or more locations. Or use your computing device as a private server.
Without limitation, multiple system modules can be used to perform one or more of the features, functions, and processes described herein. Determine and change the attributes required for the attribute combination.
Track DDID usage. Expiration or reassignment of existing DDIDs. Enables or provides data associations related to or required by a particular action, activity, process, or characteristic.

[36] In an embodiment, these modules include a privacy server abstraction module configured as follows. :
Dynamically associate an attribute with at least one data subject, action, activity, process, and characteristic.
Determine and modify the required attributes that are related to or required by a particular action, activity, process or characteristic. Generate a DDID, store it, and assign it to at least one data attribute to form a TDR.
Use the DDID component of the TDR to assign the TDR a given expiration date.

[37] These system modules, and optionally other modules disclosed herein, may be implemented in program code executed by a processor of a privacy server computer, or in another computer in communication with the privacy server computer.
The program code can be stored on a computer-readable medium accessible by the processor. Computer-readable media can be volatile or non-volatile, removable or non-removable.
Computer readable media can be, but are not limited to, RAM, ROM, solid state memory technology, erasable programmable ROM (“EPROM”), electrically erasable programmable ROM (“EEPROM”), CD-ROM, DVD, magnetic. Not limited. It can be a cassette, magnetic tape, magnetic disk storage, or other magnetic or optical storage device.
In a particular embodiment, the privacy client resides or is implemented on a "smart" device, smartphone, tablet, notebook, desktop computer, and the private client processes one or more requests for information from the private client and responds with one or more. To communicate with your private server.
(Requests for data attributes, attribute combinations, and associations between data attributes and data subjects, typically connected to other devices or networks via various protocols such as Bluetooth, NFC, WiFi, 3G, etc. Wearable, mobile, or immobile electronic devices that can operate dynamically and autonomously.)

[38] In one embodiment of the invention, DDIDs associated with attributes and attribute combinations may be limited in scope and duration.
In addition, DDIDs are reassignable, and DDIDs can reference multiple data subjects or multiple actions, activities, processes, or characteristics at different times.
DDIDs can be reassigned on a configurable basis to further abstract, dilute or attenuate the data trail while preserving the timeliness and saliency of the TDR and the data it contains.

[39] Rather than, for example, storing, sending, or processing all data attributes associated with or required by a particular action, activity, process, or characteristic in connection with a Data Subject, embodiments of the present invention , An initial layer of abstraction may be introduced by the association function.
For example, by including only some of the relevant data attributes in each TDR.
In this way, the data attributes associated with the Data Subject may be disassociated within the seemingly unrelated TDR,
To know which two or more TDRs need to be correlated, you need access to and use of one or more AKs. The substitution feature may further improve or enhance the privacy, anonymity, and security of the data attributes included or referenced in the TDR.
(A replacement that allows you to access and use one or more RKs, for example by replacing a data attribute in one or more TDRs with a DDID, and use a lookup table to determine one or more values. Data element)
The privacy, anonymity, and security of the data attributes contained within or referenced within the TDR can be further improved or enhanced by using other known protection techniques such as encryption, tokenization, pseudonymization, and deletion. I can do it. Or replace the key with a second or nth level DDID to introduce an extra layer of abstraction.

[40] Both times:
Disassociation of data attributes related to Data Subject, Actions, Activities, Processes, and Characteristics to request an AK.
Substitution of data attributes related to data subjects, actions, activities, processes, and characteristics.
Because it requires an RK, the effective privacy level, anonymity, and security are enhanced based on the method and frequency associated with the DDID. The data attributes in question have changed and are modifiable.
In an exemplary embodiment of the invention, DDIDs may be assigned and their initially assigned values retained for purposes of separation and replacement. -Permanent assignment. In another exemplary embodiment of the invention, the DDID is assigned for purposes of disassociation, replacement, and retains the initially assigned value until "ad hoc modifiability" until the value is changed on an ad hoc basis. be able to.
In yet another exemplary embodiment of the present invention, DDIDs are assigned for purposes of disassociation and replacement, and are initially assigned until values change based on random, fixed, variable, or other dynamic basis. Can hold the assigned value-"dynamic mutability"

[41] Embodiments of the present invention replace the identifying references in the system with external networks, the Internet, intranets, and computing devices capable of integrating or communicating with one or more embodiments of the present invention. , It is possible to create additional layers of abstraction.
Therefore, to enable access to and use of lookup tables, and to identify the ID of a computing device replaced by one or more external networks, the Internet, an intranet, and one or more DDIDs, one or more You need RK and AK.

[42] The modifiable and reassignable nature of DDIDs that combine to create a TDR allows the recipient of the TDR to utilize the information contained in the TDR at its intended time and for its intended purpose.
This is the association key (which may be needed to chain the TDRs in order to understand the meaning of the information contained in the seemingly irrelevant TDRs) and the replacement key (the information represented by the temporary DDID sent. The third party as part of the TDR may temporarily have limited usefulness.
Usefulness as the AK and RK are intended not to disclose relevant information and the DDID component of the TDR may be modified by the Data Subject or other administrator if the purpose and intended time are no longer applicable. Is temporarily restricted.
Conversely, the relevant information revealed by AK and RK may change over time to support additional secondary use of the data.

[43] In one example, a maintenance module is used to associate information about a particular DDID's association at a particular point in time with the privacy server by the system.
However, it is not accessible to parties other than the controlling entity or parties authorized by the controlling entity (this period may be represented by a time key (TK), etc.). In one example, the privacy server maintenance module and associated database store and maintain all associations of DDID and attribute combinations.
Thus, the system provides secure data exchange and non-repudiation of data attributes, attribute combinations, and TDRs, while meeting stricter privacy, anonymity, and security standards while ensuring safer data-related collection, use, and Facilitates research and analysis.

[44] For example, the privacy server and associated database validation modules provide an authenticated data structure that enables validation and verification of the integrity of information and DDIDs embedded in aggregated data profiles.

[45] In another example, the authentication module of embodiments of the present invention may be used to anonymously verify the right to continue with respect to a Data Subject, action, activity, process or characteristic at a particular time. Place via TDR allocation.

[46] The TDR and DDID included in the TDR can also be used as an advanced key for known protection techniques such as encryption, tokenization, pseudonymization, and deletion.
The authentication module unlocks TDR content protection techniques such as encryption, tokenization, pseudonymization, and deletion unless the TDR, DDID, private related data subject, attribute, combination of attributes, or parties involved are verified. It can be used to hold the keys needed for.
You are authorized to participate in the desired action, activity, process or characteristic at a specified time, location, and through known verification techniques such as DDID and TDR verification and password verification, multi-factor authentication or similar means. There is.

[47] In another example, an access log module is provided that can collect and store information that allows for post-trial analysis in case of system or privacy server errors.

[48] In accordance with an aspect of an embodiment of the invention, disclosed herein is a computer-implemented method of providing controlled delivery of electronic information.
In one example, a method may include the step or operation of receiving data at a computing device.
Identifies one or more attributes of the data.
Select the DDID via the computing device.
Associates the selected DDID with one or more data attributes.
Create a temporally unique data representation (TDR) from at least selected DDIDs and one or more data attributes.

[49] For example, the step of selecting a DDID includes generating a dynamically changing DDID that is unique in time, accepting a dynamically changing value that is created outside the system and that acts as a DDID. Or include changes.

[50] For the purposes of this document, the term "dynamically changing" means the DDID assigned to a Data Subject, action, activity, process, or characteristic.
(A) (i) Aging over time (ii) Flexible passage of time (iii) Expiration of the purpose for which the DDID was created (iv) Virtual subject related to the Data Subject, behavior, activity, process or characteristic Or change the real world location.
(B) Different times and times for the same or similar data subjects, actions, activities, processes, characteristics.

[51] For the purposes of this document, "thing with time intent" means that the DDID is not assigned an infinite period of time to a Data Subject, action, activity, process or characteristic.
If the duration of the DDID's assignment to the Data Subject, action, activity, process, or characteristic ends at a discrete point in time, the information about the end time of the assignment is known, and in a particular implementation of the present invention, the DDID and the aforementioned Data Used to identify relationships or connections between subjects, actions, activities, processes, or characteristics.

[52] For the purposes of this document, the term "policy" means how to programmatically perform mathematical, logical, sampling, or other functions on a dataset (eg, a dataset of any number of dimensions). To do.
This is equivalent to an enforcement mechanism to enable privacy-enhancing technologies (“PET”), including but not limited to the introduction of public key cryptography, k-anonymity, l-diversity, “noise”, and discriminatory privacy. that's all.

[53] For the purposes of this document, the term "Non-Attributing Data Element Value" (NADEV) is a value that becomes apparent when the A-DDID is re-identified, or a particular A-DDID has been re-identified. ..
NADEV creates derivative or related versions or subsets of elements of a dataset to reflect the application of one or more PET or other privacy and security-enhancing methodologies to the dataset and select portions of the dataset. Say that.
For example, assuming that the dataset contains 65 heartbeat values per minute for data subjects, the data values can be generalized to two NADEVs.
For example, specify "61 to 70 beats per minute" or simply specify "normal". -Each NADEV can independently suppress or publish independently without exposing the true data value of 65 beats per minute and without revealing the identity of the data subject.

[54] In another example, the method may revoke the association between the selected DDID and one or more data attributes.
In yet another example, information for a period of time when the selected DDID was associated with a different data attribute or time key (TK) or other combination of attributes could be stored in a database accessible to the computing device. I will.

[55] Another embodiment includes reassociating the selected DDID with another data attribute or combination of attributes after the expiration of the association of the DDID with the initial data attribute.

[56] In one example, DDID expiration occurs at a given time. Alternatively, expiration may occur after the completion of a given event, purpose or activity.
In addition, DDIDs are only permitted to be used in place for a certain period of time.

[57] In another example,
This method involves modifying the DDID associated with one or more data attributes, attribute combinations, and TDRs.
DDID changes can occur on a random or scheduled basis, or after the completion of a given activity's purpose and event.

[58] According to another aspect of another embodiment of the invention, disclosed herein is a method of facilitating a transaction over a network for receiving a request from a client device at a privacy server. It is the operation to be performed. It determines which of the multiple data attributes or combinations of attributes in the database are needed to complete the requested activity in activities over the network.
Create and accept DDIDs; associate a DDID with a determined data attribute to create a combined temporally unique data representation (TDR).
Allows at least one network device to access a combined temporally unique data representation (TDR) to perform or initiate a request activity. Receives a modified temporally unique data representation (TDR) containing additional information related to the performed activity, the modified temporally unique data representation (TDR), the DDID and data subject association information Save to memory database.

[59] In an example, network devices include servers operated by internet service providers, merchants or service providers, servers operated by mobile platform providers, or servers in cloud computing environments.

[60] According to another aspect of another embodiment of the invention, disclosed herein is a method of providing controlled delivery of electronic information.
In one example, the method may include receiving a request at a private server to perform the activity over the network. Select the attributes of the data in the database that are accessible to the privacy server that are determined to be required to satisfy the request, and other attributes of the data that are not determined to be required are not selected. Assigning or accepting DDID assignments to selected attributes, DDID does not reveal unselected attributes in the attribute combinations applied by the Privacy Server Abstraction Module. Records the time when the DDID was assigned.
You will receive an indication that the requested activity is complete. Receives the DDID and the determined attributes and attribute combinations applied by the privacy server. The attributes are modified to include information about the performed activity.

[61] In one example, the method can also include assigning an additional DDID to one or more of the selected combination of attributes included in the TDR.
In another example, the method involves reassociating with a DDID, a combination of data attributes, or a data subject identity using a time key (TK) that reflects the recorded time.
This method also includes reassigning the DDID to other data attributes and recording the time when the DDID was reassigned. Records the time when the activity performed was completed, the DDID and what they were applied to. The privacy server receives the determined attributes and combinations.

[62] According to another example, disclosed herein is a computer-implemented method for improving data security, wherein the data includes at least one attribute.
In one example, the method includes associating at least one attribute with the DDID to create a temporally unique data representation (TDR).
Here, a Temporary Unique Data Representation (TDR) provides access to data attributes only to those attributes needed to perform a particular action (for example, completing a purchase of a product from an online website). Limit

[63] The method may include assigning an association key (AK) to a temporally unique data representation (TDR).
Access to the Association Key (AK) here is required for authorized access to the (TDR).

[64] In another example, the method may also include revoking the association between the DDID and the at least one attribute.
Expiration occurs at a predetermined time and may occur after completion of predetermined events and activities. In another embodiment, the method includes reassociating the DDID after expiration of the association between the DDID and the attribute.

[65] According to another aspect of the invention, disclosed herein is a system for improving electronic data security.
In one example, the system can include modules configured to dynamically associate attributes with data subjects, actions, activities, processes, and characteristics.
A module that is configured to generate or accept a DDID, and that is also configured to associate the DDID with at least one data attribute. A module configured to track activities associated with a DDID, configured to associate additional electronic data generated by the activity with the DDID.
This method also involves storing information in the database about one or more time periods associated with different data attributes or combinations of attributes that are reflected by the applicable time key (TK) or other DDID.

[66] According to another aspect of another embodiment of the present invention, disclosed herein is a device for performing secure private activities over a network.
In one example, the device can include a processor configured to execute the program modules. (The program module includes at least the privacy client.); Memory attached to the processor
Communication interface for receiving data over the network Privacy Clients have a time-unique Data Representation (TDR) that includes the DDIDs and associated data attributes required to perform activities on the network from a private server. It is configured to receive.

[67] It may be further configured to capture the activity performed using the device and associate the activity performed with a temporally unique data representation (TDR).
In another example, the privacy client may be configured to send the captured activity and a temporally unique data representation (TDR) to the privacy server.
In one example, the privacy client may reside on the mobile device as a mobile application.
In another example, the privacy client resides on the network as a cloud-based application and is accessible over the network.
The privacy client may also reside on the same computing device.

[68] In another example, the device can also include a geolocation module on the mobile device and the temporally unique data representation (TDR) is modified with information from the geolocation module.
And the temporally unique data representation (TDR) limits access to information about the identity of the device.
The device may also include a user interface configured to allow the user to modify the TDR, including the option to modify the DDID or data attributes associated with the TDR at specific times. This includes selectable options for temporally sharing the TDR only with other network devices within a given physical, virtual or proximity to the mobile device.

[69] In the example, the device responds to a shared temporally unique representation (TDR) based on the physical, virtual, or logical location of the mobile device for targeted advertising or Receive marketing information. Here, the shared TDR includes demographic information, time information, geolocation information, psychographic information and other formats.
In an example, a shared temporal TDR contains information related to a purchase transaction made or made using a mobile device, targeting advertising or marketing information based on a previous or desired purchase transaction. To receive.
In this way, the vendor can almost immediately know the relevant characteristics of nearby users and potential customers. We never know or learn the identity of such users. It does this in real time without compromising the privacy/anonymity of the user/potential customer.

[70] According to another aspect of another embodiment of the invention, disclosed herein is a system for providing privacy and anonymity of electronic data.
In one example, the system includes at least one user device having a first privacy client running on the user device. At least one service provider device having a second privacy client operating on the provider's device.
At least one privacy server connected to the network. The privacy server communicates with the first and second privacy clients.
The privacy server includes an abstraction module that electronically links and separates data attribute combinations, which associates DDIDs with data attributes and attribute combinations.

[71] In an example, the privacy server can include an authentication module that accepts generation of one or more of the previous DDIDs.
In another example, the privacy server may include a maintenance module that stores a combination of DDIDs and their attributes.
In yet another example, the privacy server may include a validation module that validates data attributes, attribute combinations, and DDID integrity.

[72] In another example, a privacy server is an access log module that collects and stores information about DDIDs and data attributes for use in one or more post-incident forensic analyzes in the event of one or more errors. Can be included.

[73] In one example, the DDID expires after a predetermined time, and after the DDID expires, the abstraction module assigns the DDID another data attribute to another data subject.

[74] According to another aspect of another embodiment of the invention, disclosed herein are a method, a computer-readable medium, and a system for:
(I) Transforming a multidimensional dataset by technically enforcing one or more policies for at least one dimension or subset of a given dataset.
(Ii) Transform the data set in subsection (i) before, during, and after the original conversion, for example by creating one or more A-DDIDs.
(Iii) Use Just-In-Time-Identity (JITI) or other types of access control-based keys to technically enforce policies that restrict access to all or part of a dataset.
(Iv) Apply parametric or non-parametric, mathematical techniques so that the information in the transformed datasets can be ranked or evaluated according to a value metric suitable or relevant to different industries.
It can be ranked or evaluated in terms of quantitative and/or qualitative measures of effectiveness in providing anonymization to a dataset.

[75] In accordance with another aspect of another embodiment of the invention, the computer readable medium and artificial intelligence algorithms are used to analyze schema, metadata, structure, etc. of the dataset to determine algorithm actions. System Used to obfuscate, generalize, or otherwise transform a dataset to comply with a predetermined privacy policy.

[76] In accordance with another aspect of another embodiment of the present invention, disclosed herein is a method, computer readable medium, for providing a privacy policy "as a service", eg, via a network or application program. , And the system. We provide our users with the means to maximize compliance with regulatory and contractual restrictions in a way that maximizes the value of their data, that is, enables it to be used and at the same time enhances data security and privacy.

[77] In accordance with another aspect of another embodiment of the present invention, disclosed herein is computer readable media, and electronic data privacy and anonymity for distributed stored user information. The method of providing systems (eg, between unauthorized systems or using immutable and verifiable distributed ledger technology such as blockchain).

[78] Other embodiments of the disclosure are described herein. Features, utilities, and advantages of various embodiments will be apparent from the more detailed description below.

FIG. 1 shows an example of a block diagram of a system including a private server. FIG. 1A illustrates an example block diagram of a system including a private server in which the present invention is provided as a service that interacts with an external database. Figure 1B shows the various ways in which DDID assignment, enforcement, expiration, and recycling can occur for data attributes and attribute combinations. Figure 1C-1 illustrates the potential input and output flow of a system that includes a privacy server from a trusted perspective. Figure 1C-2 illustrates the potential input and output flow of the system, including the privacy server, from a data subject perspective. Figure 1D shows an example of using DDID in connection with a network blood pressure monitor. FIG. 1E illustrates an example use of DDIDs in connection with serving a patient with sexually transmitted disease (STD). FIG. 1F shows an example of the use of DDIDs in connection with providing coupons. FIG. 1G illustrates an example use of DDIDs associated with a physician looking at blood pressure levels. FIG. 1H illustrates an example of using DDIDs to provide dynamic data obfuscation in educational related information. FIG. 1I shows an example of a process of performing a Disassociation Level Determination (DLD) and creating an anonymity measurement score (AMS). FIG. 1J shows an exemplary calculated anonymity measurement score. FIG. 1K shows an exemplary category of levels of consent/engagement required by a Data Subject for a particular calculated anonymity measurement score. FIG. 1L shows an example of the use of DDID in the area of emergency response. FIG. 1M shows an example of security and privacy usage for Just-In-Time-Identity (JITI). FIG. 1N illustrates a Just-In-Time-Identity (JITI) compliant security and privacy use case. FIG. 1P-1 shows a usage example of the static anonymous identifier. FIG. 1P-2 shows an example of using Just-In-Time-Identity (JITI) compliant security and privacy. FIG. 1Q illustrates an example of the use of Just-In-Time-Identity (JITI) enabled security and privacy in the context of healthcare services. FIG. 1R illustrates an example system for implementing Just-In-Time-Identity (JITI) enabled security and privacy. FIG. 1S illustrates an example of a system that implements Just-In-Time-Identity (JITI) compliant security and privacy to support the OpenHealth platform (OH). FIG. 1T illustrates an example system for implementing policy management and access control that reduces data risk. FIG. 1U shows examples of various data risk reduction schemes. FIG. 1V shows an example of a market for various data risk elimination policies made available for purchase. Figure 1W-1 shows an example of an intelligent policy compliance engine. FIG. 1W-2 illustrates an exemplary flow diagram for using an intelligent policy compliance engine. 1X-1 illustrates an exemplary system for providing data privacy services via a shim. 1X-2 illustrates an exemplary system for providing data privacy services via inline services from a web browser, device, or other sensor. Figure 1Y-1 shows a cloud-based platform and application that provides a data anonymization system. Figure 1Y-2 shows a cloud-based platform and application that provides a system for re-identifying anonymized data. 1Y-3 illustrates a cloud-based platform and application for providing a system that integrates with extract, transform, and load (ETL) applications. FIG. 1Z-1 illustrates a distributed network built on blockchain-based technology, which may employ anonymized privacy control in accordance with one or more embodiments. 1Z-2 illustrates a distributed network built on blockchain-based technology, according to one or more embodiments. 1Z-3 illustrates a distributed network built on blockchain-based technology, according to one or more embodiments, in which anonymized privacy control may be employed. FIG. 2 shows an example of TDR generation and use. FIG. 3 shows an example of TDR generation and use. FIG. 4 shows an example of TDR generation and use. FIG. 5 illustrates two exemplary attribute combinations with different levels of abstraction due to the system's association and replacement features. FIG. 6 shows an example of a process of selecting a combination of attributes, generating a TDR to abstract or anonymize data, and reassociating or anonymizing data (from the perspective of a sample control entity and system). ) FIG. 6A shows an example of a process of receiving attributes from one or more external databases, generating TDRs to abstract or anonymize data, and then reassociating or anonymizing (sample control entity and system). From the point of view). Figure 6B shows an example of a process that provides dynamic anonymity for data elements that are considered too sensitive to be exposed in a way that is identifiable outside the organization. FIG. 7 shows an example (from the perspective of the recipient entity) of the process of FIG. FIG. 8 shows an example of a process for verifying authority. Figure 9 shows an example of a process that holds key protection information unless it is verified. FIG. 10 shows an example of a process for anonymously analyzing interests of interested parties. Figure 11 shows various examples of interactions between interested parties, service providers, and privacy servers, including the combination of DDIDs and attributes generated, transmitted, and tracked. Figure 12 shows various examples of interactions between interested parties, service providers and privacy servers, including combinations of DDIDs and attributes generated, transmitted and tracked. Figure 13 shows various examples of interactions between interested parties, service providers, and privacy servers, including the combination of DDIDs and attributes generated, transmitted, and tracked. Figure 14 shows various examples of interactions between interested parties, service providers, and privacy servers, including combinations of DDIDs and attributes generated, transmitted, and tracked. Figure 15 shows various examples of interactions between interested parties, service providers and privacy servers, including combinations of DDIDs and attributes generated, transmitted and tracked. Figure 16 shows various examples of interactions between interested parties, service providers, and privacy servers, including the combination of DDIDs and attributes generated, transmitted, and tracked. Figure 17 shows various examples of interactions between interested parties, service providers, and privacy servers, including the combination of DDIDs and attributes generated, transmitted, and tracked. Figure 18 shows various examples of interactions between interested parties, service providers, and privacy servers, including combinations of DDIDs and attributes generated, transmitted, and tracked. Figure 19 shows an example of attribute combinations that multiple service providers can access and the attributes that each service provider resends to the privacy server. Figure 20 shows data that is accessible to interested parties, including all attribute combinations sent to and retransmitted by the service provider. FIG. 21 illustrates how a service provider, which acts as a controlling entity and provides information to various vendors, provides each vendor only with the combination of attributes required to perform the services assigned to it. FIG. 22 illustrates how a service provider, which acts as a controlling entity and provides information to various vendors, provides each vendor only with the combination of attributes required to perform the services assigned to it. FIG. 23 shows an example of DDID implementation in the field of Internet advertising. FIG. 24 shows an example of implementation of DDID in the field of healthcare. FIG. 25 shows an example of implementation of DDID in the field of healthcare. FIG. 26 shows an example of implementation of DDID in the field of healthcare. FIG. 27 is a block diagram of an example programmable device for implementing a technique for dynamically creating, assigning, modifying, reassigning, and using dynamically modifiable temporary unique identifiers (DDIDs). Indicates. FIG. 28 shows a block diagram illustrating a network of privacy clients and servers for implementing techniques for dynamically creating, assigning, modifying, reassigning, and using DDIDs.

[131] In this document, various systems for the private and secure management and use of information about one or more Data Subjects, such as individuals, places, or things, and related behaviors, activities, processes, and characteristics, Methods and devices are disclosed. The systems, methods, and devices described herein enable data subjects and associated actions, activities, processes, and characteristics by linking data relating to the attributes to independent and dependent attributes and isolation elements. Abstracts data attributes related to related actions, activities, processes, and characteristics. You can then associate the DDID with a selection data attribute or combination of selection attributes to create a TDR.
In this way, embodiments of the present invention can be utilized to provide data security, privacy, anonymity, and accuracy to a Data Subject such as a person, place, thing, behavior, process, characteristic, etc. It is stored across distributed storage systems in the form of an immutable, verifiable, distributed ledger as provided by blockchain technology. This document discloses various embodiments of the present invention.

[132] Dynamic Anonymity / Circle of Trust (CoT)

[133] Dynamic Anonymity is based on the principle that static anonymity is an illusion and the use of static identifiers is fundamentally flawed.
The Dynamic Anonymity system dynamically segments reassignable dynamic identifiers (DDIDs) at various stages and applies them to data stream elements. (Note: Dynamic segmentation may include time-lapse, but is more likely to be determined by activity, location, and subject.)
This preserves the ability of trusted parties to re-stitch data stream elements and the ability of other users while minimizing the risk of unintentional information sharing during transmission, use, and breaks. I will.

[134] As shown in Figure 1C-1, a cleartext primary key can be used internally within a circle of trust (“CoT”) to identify Data Subjects, actions, activities, processes, and characteristics. However, these keys cannot be shared outside CoT. Rather, Dynamic Anonymity uses a dynamically changing and reassignable composite key outside of the circle of trust that may consist of:
(I) DDID;
(Ii) DDIDs associated with Data Subjects, Actions, Activities, Processes, and Characteristics.
Information about this association may not be available outside of CoT (the DDID representing the connection to a data subject, action, activity, process, or characteristic may not be recoverable if it does not contain recoverable information). Yes, for each of the above one or more Data Subjects, Actions, Activities, Processes, or Characteristics, in each case the connection is broken and cannot be calculated).

[135] Dynamic Anonymity enhances privacy, anonymity and personal data protection with distributed platforms and fragmented ecosystems,
Provides excellent access and use of data according to policies established by the Data Subject (on behalf of the Data Subject). In this way, everyone, including those who choose to use closed or distributed systems, will benefit from enhanced data privacy and anonymity.

[136] Dynamic Anonymity delivers certain immediate benefits without changing existing business and technology practices. With dynamically changing temporally unique DDIDs, current systems and processes (such as web browsers and data analysis engines) are unaware of the relationships between data elements. These systems and processes allow existing functionality without creating inferences, correlations, profiles or conclusions, unless the Data Subject and trusted proxies explicitly allow it through the Circle of Trust (CoT). You can use it to process the information. However, new business and technology practices that leverage the specific attributes and capabilities of DDID, Dynamic Anonymity, and Circle of Trust (CoT) provide even greater benefits.

[137] Dynamic Anonymity has advantages in each of the four points of data processing.
A. Data capture
B. Data transmission/saving
C. Data analysis.
D. Privacy/Anonymous Management of Data At each point, data is protected by the Data Subject to which it pertains or according to the PERMS specified on behalf of the Data Subject.

[138] A. Data capture

[139] In applications where static identifiers are associated with capturing data associated with a Data Subject, dynamic anonymity can provide:
1. Dynamic identifier (including DDID) that changes over time
Data subjects, actions, activities that limit associations by tracking, profile, or otherwise (triggered by passage of time, change of purpose, pause of activity, or change of virtual or physical location) Process, data with characteristics.
2. An association from each DDID to one or more applicable Data Subjects, actions, activities, processes, and/or characteristics. Only stored and recognized within the applicable CoT.
3. Dynamic Anonymity also provides an optional feature to store the data associated with the DDID in CoT.

[140] An important feature of Dynamic Anonymity is the ability to anonymize and separate data elements at the data element level, not at the data record level, that is, at the level of individual data elements associated with data subjects, actions, and activities. Circle of Trust maintains the relationship information between data elements and Data Subjects, actions, activities, processes, and/or characteristics, and allows reassociation by data according to established privacy policies, rules on behalf of the data. .. (In this manual, it is also called "PERMS".)

[141] Example: Search engine

[142] Consider, for example, a person who frequently uses a particular search engine.
Now search engines assign users a "cookie" or other digital footprint tracker that lasts for months or years (via a browser). It is then accumulated, often analyzed, and then aggregated by multiple parties. -Users often publish personally identifiable information without their consent by the Data Subject.

[143] Dynamic Anonymity can leverage the natural response of search engines to create a new cookie/digital footprint tracker for each Data Subject that is recognized as interacting with the search engine for the first time.
When you clear your history, cache, cookie/digital footprint tracker, and related data, the search engine will generate a new cookie/digital footprint tracker for your data subject.
CoT can store information about cookies/digital footprint trackers and Data Subjects, and optionally also a list of queries and selected links.

[144] This approach allows search engines to continue to access aggregated data (trend search terms, websites, ad clicks, etc.).
However, you cannot derive inferences related to the Data Subject based on the observed data. CoT can allow search engines to perform more detailed analysis when permitted by privacy/anonymous policies and rules established on behalf of the Data Subject.
This can be implemented using an HTTP proxy or browser extension and requires no changes (or cooperation) to existing search engines

[145] In the old days, anonymous cookies should have solved the problem of supporting both privacy and analysis.
But because all the data is stored together and is associated with a random static identifier that can easily be linked or linked to a Data Subject ("personal data" or "PD"), anonymous tracking cookies I couldn't achieve this goal. This invalidates or attenuates the value of static "anonymous" identifiers. Dynamic Anonymity employs dynamically changeable and re-assignable DDIDs, saves the resulting DDID association, obscures the key within the Circles of Trust, and allows the Data Subject and trusted/third party participants to Overcoming these shortcomings by providing a unique interaction model that allows participation of the.

[146] B. Data transmission/saving

[147] CoT consists of one or more trusted parties, each of which provides one or more independent data storage features, and a secure means of segmenting sensitive data into these data stores for transmission.

[148] Or Dynamic Anonymity compliant application developers should only store the data subject and DDID associations in the CoT and instead use the Dynamic Anonymity definition steps to obfuscate, encrypt, and segment the data. You can choose that. Allows applications to securely store information generated or collected in their own facilities without losing context or business value.

[149] In the past, techniques similar to those used by the present invention have been used for:
-Segment data;
-Encrypt and obfuscate data in transit
-Distributed at rest, obfuscation, and security adoption
Dynamic Anonymity improves on these traditional approaches by:
-Hide data at the data element (for data record) level using DDIDs that can be dynamically changed and reassigned.
-Preserving the resulting DDID association/key obfuscation within the trust circle;
-Provides a unique mutual model to enable participation between Data Subjects and trusted/third party participants.

[150] C. Data analysis

[151] Traditional methods of data "cleansing" (also called data cleaning and data scrubbing) suffer from two main problems.

[152] 1. Certain data cleansing techniques may be invalid. Despite serious efforts or the use of legally licensed technology to obscure personal data, it may be possible to identify Data Subject and personal data from "cleansed" data .. Despite serious efforts or the use of legally licensed technology to obscure personal data, it is still possible to identify data subjects and personal data from "cleansed" data is.
Three famous examples:
a. In the mid-1990s, the Massachusetts Group Insurance Commission (GIC) published data on individual hospital visits by state employees to support important research. Latanya Sweeney was a MIT graduate student at the time, but by purchasing a Cambridge voter registration record and linking the two data sets, they were completely harmless individually, but with names, addresses, social security numbers, etc. All obvious identifiers were removed and "anonymized".
b. In 2006, UT-Austin graduate student Arvind Narayanan, along with his advisor, helped many Netflix users link "anonymized" Netflix datasets to the Internet Movie Database (IMDb). There was a possibility of being re-identified.
c. In 2013, a team led by Dr. Yaniv Erlich of the Whitehead Institute for Biomedical Research, recruited men to participate in the 1000 Genomes Project, an international consortium for placing 2500 sequenced genomes into an open online database. Re-identified.

[153] 2. More effective data cleansing techniques can diminish the business value of the data itself. Many obfuscation techniques are costly.

[154] The Dynamic Anonymity approach to data privacy/anonymity provides a way to avoid both pitfalls at the same time.

[155] D. Data Privacy/Anonymous Management

[156] To protect personal data, Dynamic Anonymity can use multiple means to measure, specify, and enforce data privacy/anonymity.
1. A system that determines a privacy/anonymity level for each type of potential exposure of data associated with a Data Subject, action, activity, process, and/or characteristic.
These privacy/anonymity levels consist of a set of discrete values (between the extremes of full privacy/anonymity and full disclosure) or such mathematical specifications (“anonymity score” or “AMS”) ..
2. PERMS that specifies the actions permitted or restricted by the policy on the data. (Eg share, update).
3. A PERM that correlates access levels, permissions, and data to allow or deny specific levels of access to data based on one or more criteria, including data type, time, organization seeking access, and so on.

[157]Data Subject's PERMS may be combined with statutory policies or restricted by law. (For example, US medical data must be protected in accordance with US Health Insurance Portability and Accountability Act (HIPAA).)

[158] In addition, if permitted by a trusted party and with the consent of the data owner, an offer to modify or grant certain restricted rights will be presented and accepted in the Data Subject.

[159] Dynamic Anonymity also uses privacy/anonymity level decisions to improve existing frameworks and also prevent improper use of data in a way that matches the specified privacy level of each Data Subject. I can do it.

[160]Dynamic De-Identifiers (DDIDs)

[161]A dynamic de-identifier DDID is a temporary restricted pseudonym that references and obscures the following values:
(I) A primary key that references data subjects, actions, activities, processes, and characteristics.
(Ii) The value, action, activity, process, and characteristic of that Data Subject attribute (eg, zip code)
(Iii) Data subject, action, activity, process, and the type or type of data associated with the characteristic.

[162] DDIDs may further protect the data if there is no recognizable unique computable relationship between its content and the value (clear text) it references. Furthermore, the association between a particular DDID and a cleartext value may not be exposed outside the Circle of Trust (CoT).
Unlike static identifiers, hidden values and keys do not have to have the same associated DDIDs when used for different contexts, purposes and at different times.

[163] DDIDs can be generated by the Circle of Trust or external IDs can be used as DDIDs if the above criteria are met.

[164] DDID has a time limit.

[165] As mentioned above, DDID associations are time-limited.
That is, a given DDID may reference one value at a time for a single type of data, even within the same context. (You can also refer to different values at different times if you wish.)

[166] In order to decipher and expose the meaning of a particular DDID, the application necessarily needs to have knowledge of when the DDID was applied.

[167] This knowledge may be obvious. -That is, the allotted time may be part of the record or document in which the DDID is stored, or it may be implicit. For example, if the entire dataset is obscured as a batch, occupies the same moment (regardless of how long it actually takes to process), and there is only one consistent set of DDID mappings per field type. there is. To reconstruct such data, you also need to provide a reference to the corresponding set of DDID/value associations (stored within the CoT).

[168] DDIDs are purpose-dependent.

[169] Note that DDIDs are also context and purpose dependent.
-Means that the same DDID can occur in multiple contexts at the same time.
For example, consider a stream where each record contains a social security number (SSN) and postal code. All occupy a single block of time.
In such cases, the specific DDID can be used as a postal code alternative or an SSN alternative.

[170] Means that some indication of context (postal code or SSN) is required to get the cleartext referenced by the DDID as described above.

[171] Replace data with DDID

[172] Consider the task of replacing a single data stream with the same type of data (such as a zip code or SSN) and occupying the same time block with a DDID.
A (pseudo-like) "pseudocode" description of an application programming interface (API) that performs such operations in a potential embodiment of the invention looks like this. :
interface DDIDMap {
DDID protect(Value cleartext);
Value expose(DDID ddid);
}

[173] The English "interface" defines a collection of functions (called "DDIDMap") that operate on the same underlying data.
Here, the data type is indicated by the first capital letter (eg "DDID").
Variable or function parameter names are initially shown in lower case (for example, a "cleartext" function parameter must be data of type "Value": ID, quantity, name, zip code).

[174] One function, protect (), accepts a clear text value and returns the corresponding DDID.
If that value was previously seen, its DDID is returned.
If not previously found, a new DDID (unique to this dataset) is generated and associated with that value and returned.

[175] The function expose () reverses this process.
When the DDID is sent, it retrieves and returns the clear text value that was previously encoded as the DDID.
If the specified DDID has never been displayed, it indicates an error.

[176] The data managed under these operations is a bidirectional mapping from each clear text value to the DDID that replaced it, reverting to its original value.

[177] Mentioned that a particular DDID can only reference a single value. However, if desired, you can implement a variant version of this algorithm to associate values with multiple DDIDs.

[178] DDID management by time and purpose

[179] The above bidirectional DDID-to-value map is
(I) a single type of data (that is, with the same type, context, purpose)
And (ii) within the same time block. To support operations across multiple times and contexts, you can deploy another potential API that provides the appropriate DDID-to-value map for a particular time and purpose.
interface DDIDMapManager {
DDIDMap getMap(Context context, Time time);
}

[180] The "context" and "emits" keys indicate that certain types of data are hidden. (Otherwise it is called association key or A_K.)
For example, "context" may be the name of the table and column where the hidden data resides (eg "employee.salary"). You can also include other non-chronological views of the purpose or range.

[181] "time" indicates that the DDID was (or was) associated with a cleartext value. DDID-to-value maps span blocks of time.
Also, there are many time instances within the block. This means that there is a function that finds the time block associated with each time. (I'll talk more about this later.)

[182] DDID Generation and Time Blocking Strategy

[183] Note: Different types of data can be replaced with different DDIDs.
In addition to what is mentioned in the next two sections, the size of a DDID depends on whether it is universally unique or unique in its dataset (or timeblock).
Also, the type of encoding used (such as integer or text) and the DDID generation should normally be random, but you can also use a deterministic or pseudo-random DDID generator for demonstration, testing, or debugging purposes. ..

[184] Unique or reused DDID

[185] A potential strategy allows a specific DDID to be assigned to two different Data Subjects within the same context. But only between two different time blocks. For example, the DDID "X3Q" within the same collection of time-fixed records may reference "80228" at some point (in one time block).
Then (in another time block) see "12124". (This strategy is called "DDID reuse".)

[186] Another way is to prohibit "reuse" and specify that a particular DDID can only refer to a single subject in the same context.
(Subjects may receive different DDIDs over time.)

[187] Choosing between these two strategies involves increasing the ambiguity and making the trade-off between facilitating aggregate queries on fuzzy data.

[188] Let's say you want to count patients by zip code.
If the zip code DDIDs are unique, you can aggregate the counts for each DDID.
Then ask CoT to finish the query by resolving these DDIDs into the corresponding postal codes and recounting.
However, if I have a "reuse" DDID, I can't see that two instances of the same DDID refer to the same value, so I send the DDID or the entire corresponding timelist to the CoT for resolution (and aggregation) need to do it.

[189] DDID time block

[190] Implementations also have the freedom to choose strategies for segmenting the DDID map by time.
Blocks of time can vary depending on size and time offset.
The size can be fixed, random, or by the number of records allocated per hour. (Note that using an infinitely sized time block for a particular context is equivalent to using a "static" identifier.)

[191] Implementation

[192] There are many strategies for creating new DDIDs. However, the API for generating such DDIDs may look essentially the same regardless of the strategy implemented internally.
For example:
interface DDIDFactory {
DDID createDDID();
}

[193] Next, consider the task of determining which time block is associated with a particular DDID assignment.
Each time block requires some "time key" (abbreviated as "T_K" elsewhere in this document), because time blocks can contain many instances of time. This means that the function needs to get the appropriate key at any time.
TimeKey timeKey = getTimeKey(Time time);
And both time blocking and DDID generation strategies depend on the type of hidden data.
That is, they are both associated with a particular "context". That is, at least one "context" API must be provided for each function that supports it.
interface Context {
TimeKey getTimeKey(Time time);
DDIDFactory createDDIDFactory();
}

[194] Given these two additional features,
The implementation of "getMap ()" of "DDIDManager" (described above) is as follows.
DDIDMap getMap(Context context, Time time) {
TimeKey timeKey = context.getTimeKey(time);
DDIDMap map = getExistingMap(context, timeKey);
if (map was not found) then
DDIDFactory factory = context.createDDIDFactory();
map = createMap(factory);
storeNewMap(context, timeKey, map);
endif
return map;
}

[195] "getExistingMap ()" is a function that finds the map assigned to a particular context and timekey.
"CreateMap ()" creates a map that uses the specified DDID factory, and "storeNewMap ()" associates the newly acquired map with a context and time key that will be acquired later.

[196] Obfuscating data and attribute types using context

[197] Dynamic Anonymity can define the following types of data to protect:
(I) A primary key that references a Data Subject, action, activity, process, and characteristic (such as an employee ID). (ii) Attribute data that is associated with the Data Subject, action, activity, process, and characteristic, but is not unique. (Employee postal code, etc.)
(Iii) A representation of the disassociated (hidden) data element type itself ("association key" or "A_K").

[198] Each can be achieved by defining a different context.
First, I will explain (i) and (ii). Both can be done by obfuscating the data values. (In other places, replace with the "replacement key (replacement key)" DDID (abbreviated as "R_K").)
(Iii) The indication of the type of unassociated (unclear) data element is described below.

[199] Consider an example. :
An order table that records which products a customer purchased on a particular day.
Each record has a day number, customer ID, and product ID.
We want to obfuscate this data for use or analysis by a third party outside of CoT.
In particular, keep the customer and product IDs confusing, but leave the day numbers as they are.

[200] And two "context" instances can be created.
One for the "Customer ID" and one for the "Product ID".
The DDIDs should ideally be random, but here we assume that the "DDIDFactory" will create an integer DDID starting from 0 in sequence.
Furthermore, we assume that each DDID map has a deadline of 3 days, so after 3 days, a new set of DDID mappings will be used. That means the DDID is "reused". Different blocks allow the same DDID to refer to different values.
(This is not an ideal strategy and is used only for illustration.)

[201] Table 1 shows sample data in clear text.

[202] After being specified as above, this data will be as shown in Table 2 below.

[203] To understand this, read each column and think in groups of three days. (The first time block of the DDID is the obscure field for 1-3 days each, and the second cover is the 4-6th day.)

[204] Customer IDs are 500, 600, 600 for the first 3 days. The resulting encoding is 0, 1, and 1 (note that DDID and 1 are repeated because 600 is repeated).

[205] Customer IDs on days 2 and 3 are 700, 600 and 500. And (starting from 0) the result is 0, 1, 2 (previously 500 was 0, but now it is 2).

[206] Product ID uses a different context. Therefore, since it is a DDID stream, it starts from scratch. For the first time, the block (XXX, YYY, TTT) becomes (0, 1, 2). The second time block (TTT, YYY, TTT) will be (0, 1, 0).

[207] Another "context" can be used to hide the display of ambiguous data element types (iii above) where the column name is the attribute key (A_K).
This can be done using a DDID-to-value mapping for the entire set (substantially replacing the column names with DDIDs) or in a timeblock (just like any other field) (appropriately random) The affected records could not be analyzed without the help of CoT.

[208] Notes on locality and time

[209] The example API defined above assumes that once the data is encoded, each datum or record will be passed the encoding time.
This is only necessary if the DDID is "reused" within the same context (thus it takes time to distinguish between the two potential meanings of that DDID).
If a DDID is assigned to only one value per context, then that DDID is sufficient to find the (single) original value.

[210] Time issues can also occur if "reused" DDIDs are employed across different systems.
If you can't pass the time associated with a DDID encoding, you can use a (time-series) "buffer" to prevent the DDID from being too close to its original allocation for reuse. And if the time associated with the encoded data can be passed, that time is sanity checked against the local system clock.
Skew within a small window (smaller than the DDID reclaim buffer) is acceptable, but a large difference causes error reporting.

[211] Finally, note that there is also flexibility in where the data is encoded. : The data is streamed to the machines that reside in CoT, encoded and sent to its destination. However, instead, the resulting DDID-value association is (a) not stored locally on the localhost, and (b) secured to the CoT host for persistence (using encryption, proper protection against data loss, etc. If you want to stream and have low latency in your critical applications, you can also run the coding part of the above algorithm outside CoT.

[212] Dynamic Anonymity: Deletion of identification without devaluation

[213] The "de-identification" technique traditionally used in certain situations (eg HIPAA or health-related situations) to protect the privacy/anonymity of the data is inherently defensive. There are many. For example, in order to reduce the possibility of re-identification by unauthorized third parties, a series of masking steps are applied directly to the identifier (name, address, etc.) and operations based on masking or statistics are associated with the quasi-identifier (e.g. Age, sex, occupation). This approach can result in a tradeoff between protection against re-identification and maintaining access to available information.

[214] Dynamic Anonymity can be of great value in that it retains the value of information and can be leveraged for approved purposes, even though the risk of data re-identification is not statistically significant. There is. Dynamic Anonymity may deny the proposition that the value of information content must be sacrificed to minimize risk and the traditional dichotomy, but instead Dynamic Anonymity does risk and the amount of information lost. Minimize both, and allow most, if not all, of your information to be recovered. However, it can only be restored if approved by the Data Subject/Trusted Party, not by a rogue enemy/"black hat"-like hacker.

[215] Dynamic Anonymity enables multiple parties to use information in different ways in a controlled environment that facilitates unlocking data and maximizing value. Dynamic Anonymity maximizes the value of potential business intelligence, research, analytics, and other processes while potentially significantly improving the quality and performance of data privacy/anonymous processes.

[216] When collecting or storing sensitive data, you can "disassociate" sensitive data from the subject using one or more of the following methods: There is no loss of value with either method.
1. Segmentation: Sensitive data is divided into multiple parts for each data type and managed separately (in different circles of trust or using different DDID mapping sets managed by the same trusted side) It is sent and/or stored so that each piece alone does not generate personal data.
2. ID replacement: Static identifiers can be replaced by dynamically changing and re-assignable DDIDs, which obscures the relationship between the data and the target data referenced by the data.
3. Obfuscation: Data values and data type indicators can also be replaced with DDIDs.

[217] The DDIDs associated with these operations are stored within the functions of the Circle of Trust CoT, as shown in Figure 1C-1. Thus, the original data can be reconstructed by reversing these transformations, but only with the cooperation of CoT itself, and thus the Data Subject gave such permission on its behalf. Only works if.

[218] FIG. 1 illustrates an example of one embodiment of the present invention, which illustrates various data attributes and combinations of data attributes (including behaviors) for data objects for use in different applications 56. A system that securely manages data, transaction history, credit ratings, identity information, social network data, personal history information, medical and employment information, and education history (including but not limited to) Privacy server 50, or privacy server Including modules. These applications 56 include, but are not limited to:
-Medical applications-Medical records-Mobile applications-Real-time critical care applications-Compliance with laws and regulations (eg HIPAA)
・Research 〇 Education application ・Student list ・Research 〇 Mobile application ・Geolocation (beacon, GPS, Wi-Fi fingerprint authentication)
・Mobile payments and royalties ○ Financial service applications ・Banking, securities, etc.
・Payment processing ・Credit card industry (PCI) security ・Authorization ・Confirmation of card membership ・Compliance with laws ・Research ・Credit assessment ・Uncover fraud 〇 Web application ・Casting ・Content review ・E-commerce ・Social network 〇 Internet application" Telematics-Smart grid-Smart city-Traffic monitoring-Utility monitoring 〇 Power supply 〇 Fuel 〇 Water/sewerage/waste management/Smart office/Smart factory/Smart home/Connected entertainment 〇 Television 〇 Streaming device/ Automation 〇 HVAC
-Lighting-Security-Window/door lock-Fire/smoke/carbon monoxide detector-Appliance-Smart car-Agricultural field sensor-Wearable terminal-Medical surveillance-Fitness equipment-Eyewear-Clothing-Drone-Private wireless/wired network・Crop sensor ・Tagged animal tracking ・Military movement 〇Private security application 〇E-commerce application 〇Offline retail application 〇HR/recruitment application 〇Government application ・National security application ・Call detail record analysis ・Web browsing Behavior analysis-Analysis of online and offline purchasing behavior-Travel behavior analysis-Analysis of social media activities-Analysis of circles of friends, acquaintances, and other relationships Retention ・Electronic Discovery 〇 Application for consumer contest 〇 Dating application 〇 Gambling, e-Wagering application (e-Wagering)

[219] Figure 1A illustrates receiving electronic data from one or more external databases 82 and including one or more external databases for Data Subjects (this includes behavioral data, transaction history, credit ratings, identity information, social network data). , Personal history information, employment information, medical and educational history) to securely convert various data attributes and combinations of data attributes into TDRs for use in different applications. -Shows an example of an embodiment of the invention, including a system with modules.
Alternatively, the application stores only the Data Subject to DDID association information in the privacy server 50 and uses a dynamic anonymous definition procedure to obfuscate and encrypt the data stored in the external database 82, Segment. In this way, the Data Subject to DDID association information stored in the privacy server 50 can provide greater context and business value to the information generated, collected and stored in the external database 82. You can

[220] In one example, embodiments of the present invention can form a secure, comprehensive aggregate data profile 58 of data objects for use in one or more applications 56.
The Data Subject or its related parties, such as user 59, is the Data Subject's aggregated data profile 58 (which may be an unrelated data source that consists of a combination of data attributes or parts thereof). The parties involved in the data subject are interested in communicating 57 via the network 72 (e.g., availability of services or possible purchase transactions) based on one or more characteristics such as The data subject's identity and data attributes can be communicated anonymously or selectively disclosed from the data subject's aggregated data profile 58 to a vendor, service provider, advertiser or other entity having ..
As such, embodiments of the present invention may be directed to individuals ("DRMI"), related parties or third parties, or one or more data subjects that manage data attributes and combinations of data attributes associated with a Data Subject. Provides non-identifying digital rights management (“DRMD”) consisting of a third party that manages related data attributes and combinations of data attributes.
In one example, the extent to which data attributes, combinations of data attributes, data subject matter, and/or information about related parties are made available to other parties can be controlled by embodiments of the present invention.

[221] In the example of FIGS. 1 and 1A, multiple users 59, such as a Data Subject or service provider, may be connected to a smart device 70, smartphone, tablet, notebook, desktop computer, wired computer to access a network 72 such as the Internet. Or utilize a device such as a wireless device or other computing device running the privacy client application 60.
As shown in FIGS. 1 and 1A, there is shown a system 80 that communicates by connecting to the Internet or other public or private network, which system comprises a privacy system that is securely connected to one or more databases 82. -A server 50 can be included.
In one example, the May 50 privacy server is implemented using computer program modules, code products, or modules running on a server or other computing device.
May 82 one or more databases include techniques for securely storing data (such as encryption) in redundant locations such as RAID storage, network attached storage, or any other conventional database; It is implemented using any conventional database technology.

[222] In one example, the privacy server 50 performs one or more of the operations, processes, functions or process steps described herein, and the privacy server 50 implements a particular implementation of the present invention. Optionally, other operations, functions or process steps may be included or configured to include any of the following processes, operations or functions performed by the indicated module: Contains:

[223] Authentication module 51 that can provide both internal and external authentication, including the following processes:
a. Internal authentication of 60 privacy client requests to TDR, and 50 generations of TDR privacy server.
b. External authentication prior to allowing participation in the desired action, activity, or process, and the use of TDR, may be required to unlock the content of the TDR, time key (TK), Use of TDR to authenticate the recipient as authorized to receive the association key (AK), replacement key (RK).
c. One embodiment of the authorization module may include allowing delegation of the ability to request the generation of DDIDs and associated TDRs to other entities authorized by the controlling entity.

[224] Abstraction module 52 that may provide internal and external abstractions that may include one or more of the following processes:
a. Select a DDID by generating a DDID or accepting or changing a value that is unique in time and dynamically changing to act as a DDID.
b. The DDID is associated with a data attribute or attribute combination to form a TDR for a given data subject, action, activity, process or characteristic.
c. The inclusion of only some of the relevant data attributes in the TDR decouples the data attributes that are relevant to the data subject and/or that are associated with a given action, activity, process or trait.
d. Replace the data attribute included in TDR with DDID.
e. Replacing one or more references to an external network, internet, intranet, computing device with a DDID that can be integrated or communicated with one or more embodiments of the present invention.

[225] Maintenance module 53 that can store:
a. Data Subjects, Acts, Activities, Processes or Characteristics, “Relevant Data” (defined as data initially associated with a DDID and/or aggregated by DDID during and/or after the association period.)
b. (a) a time key (TK) that reflects information about the period in which each DDID was associated with a particular data subject, attribute, attribute combination, action, activity, process or characteristic, (b) an association key (AK) or (c) Key information about the replacement key (RK).
This allows the TDR to be later re-associated with specific attributes, attribute combinations, actions, activities, processes, characteristics, and related Data Subjects.
Further, the maintenance module can perform analysis and processing of attributes or combinations of attributes in a secure environment.

[226] System log, an access log module 54 that may include collecting and storing information to enable forensic analysis after an accident in case of misuse.

[227] A validation module 55 that includes validating and validating the integrity of aggregate data profiles including data attributes, attribute combinations, DDIDs, and TDRs at any point in time.

[228] As described herein, embodiments of the present invention are directed to promoting privacy, anonymity, security, and accuracy for electronic data and network communication, analytics and research.
In one example, the data elements associated with a Data Subject, action, activity, process or property can be abstracted by separating them into independent or dependent attributes.
For the purposes of this disclosure, data attributes, either individually or in combination with other data elements, identify a Data Subject such as an individual, place or thing, and related behavior, activity, process or characteristic. It can refer to any data element that can be used.

[229] In addition to abstracting data that can be used to identify a Data Subject, such as a person, place, or thing, as described above, the abstraction module 52 of FIG. 1 or 1A It can include: :
Physical or virtual things and entities; hardware or virtual devices; software applications; legal entities, objects; images; audio or video, information; sensory information; multimedia information; geolocation information; privacy, anonymous information; security Information; electronic messaging information, including senders and recipients, message content, hyperlinks in messages, embedded content in messages, and information about devices and servers involved in sending and receiving messages; social media and electronic forums; online web Sites and Blogs; RFID (Radio Frequency Identification); Tracking Information; Tax Information; Educational Information; Military, National Defense, and Other Government Program Identifiers; Virtual Reality Information; Multiplayer Online Role Playing Games (MMORPG) Medical information; biometric data; behavioral metric information; genetic information; data that refers to physical or virtual locations of other data; examples or representations of data or information.

[230] The systems, methods, and apparatus described herein are used in one example to provide digital rights management for individuals (DRMI) and de-identification (DRMD).
Personal digital rights management can include personal-oriented privacy/anonymity in which related parties manage data attributes related to one or more related parties.
In this case, the related party will be the controlling entity. Alternatively, a third party can manage the data attributes for one or more related parties, thereby providing entity-oriented privacy/anonymity. In this case, a third party will be the controlling entity. Digital rights management for de-identification is also an entity-oriented privacy policy in which a third party manages data attributes related to related parties and controls the extent to which data attributes and related party information is available to other parties. / Including anonymous.

[231] The systems, methods and apparatus disclosed herein are used to provide DRMI so that one or more related parties can manage an online digital fingerprint of data, either directly or indirectly. May be. Related parties also control the extent to which data attributes, data subjects, or information related to one or more related parties are made available to third parties to ensure that information and data are anonymous and non-reviewable. Can be made available in a way. The systems, methods and apparatus provide a dynamically changing environment in which the parties may want to share data at one point but not the next. This is done with the understanding that the time interval, the particular receiving entity, the physical or virtual location, or other mechanism that triggers a change in the shared data may be dynamic in nature. Implementing DRMI makes it impossible to re-confirm anonymity and provides different information about data attributes, Data Subjects and parties dynamically changing, time and/or location sensitive, on a case by case basis. And may allow sharing for different purposes. Specific needs for data attributes, Data Subjects or information related to parties at a particular time and place can be adjusted without revealing additional unnecessary information. However, unless such clarification is permitted by the management entity. Additional unnecessary information may, for example, be relevant to a non-related party with respect to the Data Subject or the related party's true identity, email address, email address, previous online behavior, or certain behavior, activity, process or characteristic relating to the related party. Other information that is not needed.

[232] The systems, methods, and apparatus disclosed herein are used to provide DRMD, so that entities are able to retrieve data attributes, Data Subjects, and online information related to the parties to which they are responsible. Centrally manage digital fingerprints. Such an institution can control how much information is available to other parties in a non-reconfirmable and identifiable manner.
This allows the organization to meet its Data Subject, related parties, and de-identification objectives or obligations to comply with regulatory protection and prohibition requirements.

[233] Exemplary embodiments of some embodiments of the present invention may be configured to provide DRMI or DRMD capabilities in terms of data attributes composed of image or video files exhibiting discriminating facial characteristics. ..
The Data Subject or related parties benefit from others who can reason about identity based on characteristics in electronic images.
However, the use of face recognition technology in combination with the rapidly expanding commercial and electronic image availability is problematic with respect to the privacy/anonymity, security of the data subject and interested parties.
In one example, privacy/anonymity, security is protected using one or more aspects of this disclosure with respect to a Data Subject and related parties in the context of data attributes, which are photographs that include facial images and Data Subject features. be able to.

[234] In some embodiments, the systems, methods, and apparatus disclosed herein include registration with websites or other electronic image sharing applications that include data attributes, authorized visitors vs. unregistered/unregistered. It can be configured to distinguish the status of a party as an unauthorized visitor.
Also, if a visitor who is registered and authorized on a website or other photo sharing application contains data contact information for a data subject or a related party, data attributes about a friend, as well as contact/friends of the data subject or a related party. It can be distinguished from the case where it is not.
In an example, the system of the present invention can control whether image data attributes including facial features are presented.
When presented with image data attributes that include facial features, the system further controls unauthorized use and copying of photos, which may lead to unintended secondary use, through additional protection techniques, Can be restricted.
Further, some embodiments of the present invention provide the Data Subject, related parties, and controlling entities with the ability to specify which additional parties and for which particular purpose the image data attributes can be presented. be able to.
When data attributes are presented, the Data Subject, parties or control entities aim to limit the unauthorized use and reproduction of photographs by the images, thereby preventing or reducing the risk of unintended secondary use of the images. It is possible to specify whether or not to use the known protection technology.

[235] DRMI manages photos, including facial images, directly or indirectly by Data Subjects and related parties, and allows third parties to identify, identify, and play back photos related to related parties. You can control the available range in an impossible way.

[236] Potential embodiments of the present invention include the use of DRMI by a provider of wearable, embeddable, embeddable, or otherwise connectable computing technology/devices to use the technology/devices. Reduce potential public interest in the information that is acquired and processed.
For example, Google(R) can promote widespread adoption of Google GLASS(R) by adopting DRMI. DRMI is a digital display prohibition list (FTC restricts unwanted solicitation to an individual that allows the Data Subject or related parties to register and prohibit the digital display of unauthorized photos taken or displayed using it. This is achieved by establishing a (similar to a bar solicitation list that you maintain). (Google and Google GLASS are trademarks of Inc.)

[237] The DRMI provided by an example of the present invention may also be used by third parties to identify, unidentify, play, or play photos with Data Subjects or interested parties who are members of the professional networking site LinkedIn.com. It is possible to provide a function for managing the range to be made available in a non-renewable manner. Access, use, and copying of photographs that include facial images of the Data Subject or related parties can be controlled, in one example, using a three-tier classification scheme.

[238] Category A
Status may apply to visitors of the LinkedIn.com site who are not registered/approved members of LinkedIn. They may not provide you with the means to view or copy photos that contain registered/certified LinkedIn(R) (LinkedIn(R), a trademark of LinkedIn Corporation.) Members' facial images. Instead, provide via your web browser, mobile application or other application a graphic, image, indicator or avatar that indicates that the photo is only available to registered/authorized users of the LinkedIn.com website. I can.

[239] Category B Status may apply to members whose LinkedIn registered/approved contact information has not been verified.
Unauthorized use of photos that may lead to unintended secondary use, limited use for viewing or copying their photos by using additional protection technology aimed at limiting copying Get the means. These additional protection techniques include:
1. A tiling process that divides an image into smaller image tiles. The image tiles appear as a series of images, but the entity you are trying to copy the image is limited to one tile piece at a time.
2. Adopt image digital watermark technology
3. Hide the layer and place the image with facial features behind the transparent foreground image
4. Providing images without using color profiles or palettes
5. Prevent download by table instruction that disables "right-click" copy or use of image
6. Preventing downloads with JavaScript technology that disables "right-click" copying or use of images
7. Prevent downloads with Flash technology that disables "right-click" copying or use of images
8. Hiding images by URL encoding
9. Use META tags to prevent images with facial features from being indexed by search engine spiders, robots and robot images
10. Use Robot. This is to prevent images containing facial features from being indexed by search engine spiders, robots, and robot images.

[240] Category C Registered/Approved Members of LinkedIn.com Also applies to Verified Contacts of other Registered/Approved Members. These registered/certified members can be provided with a complete means to view or copy photos, including facial images of other LinkedIn(R) members.

[241] DRMD can be provided according to some examples of the present invention so that an entity can centrally manage photo data attributes, including facial images that are responsible, and other photo data attributes. Can be made available in a identifiable, non-identifiable, reproducible or non-reproducible manner to the parties concerned.

[242] As one of the possible embodiments of the present invention, the Data Subject or relationship of the photo data attribute including the registered/approved Data Subject that can view the facial elements or the recognizable facial elements of interested parties. It may also include the use of a system that provides DRMD by an administrator that leverages known facial image recognition capabilities to limit the exposure of elements by those not authorized by the person. In other words, you are trying to upload, use, or browse a registered/approved Data Subject or a photo that contains facial elements of an interested person whose facial features are registered in the DRMD system, but the registered/approved Data Revision of photos modified by the DRMD system in order to block out or “untagged” recognized or recognized Data Subject or stakeholder facial elements by persons not authorized by the Subject or stakeholder. Only the edition can be viewed and used. For example, a photo taken in a public bar containing a Data Subject or a party's face that is registered with a system that provides DRMD will show all of the photographs except for versions that are specifically approved by the Data Subject or a party. Can be modified to block out or "untagged" the faces of interested parties for the version of.

[243] In one example of the invention, the authorization module may be configured such that the decision of who sees what information is made by the administrator in a configurable manner. In another example, the configurable controls allow administrators to dynamically change the composition of information, which consists of data attributes, at any time, automatically or on a timely basis. It can include manual decisions and updates. The enhanced customization gained by dynamically changing the composition of data attributes leads to greater relevance and accuracy of the information provided about data attributes and interested parties. As disclosed herein, the use of DDIDs as a component of privacy, anonymity, and security allows each recipient of information to receive different information that is appropriate for each particular purpose. Is new, timely and relevant, unlike the old, time-consuming, inaccurate and progressively increasing data provided through traditional immutable static identifiers or other mechanisms. Encourage high and accurate information distribution.

[244] FIGS. 1 and 1A show various examples of privacy clients 60 operating on user equipment 70, including computers, smartphones, and other wired and wireless equipment, which user equipment includes: It is also possible to communicate with privacy server 50 over network 72, which is the Internet or other public or private network.

[245] In one example, the privacy client that is an element of this disclosure can also be a resident on a mobile device. The privacy client may be provided as part of a mobile app or operating system on the mobile device, or it may be configured as a hardware device built into the circuitry or elements of the mobile device. A mobile device that incorporates one or more elements of the present disclosure may carry real-time information about the location, activity, and behavior of a Data Subject or a party with whom the device is associated. The mobile device can also send, receive, and process information to other devices and sources. Mobile apps that work with privacy clients allow administrators to anonymously share information with third parties, rather than being able to personally identify the timing and level of participation in apps that are location and time dependent. You can also provide management rights for both. Mobile devices incorporating one or more elements of the present disclosure may be of a user's personal preference collected from irrelevant, disparate sources (mobile devices, conventional computers, or a combination of both). Facilitate mobile device's unique ability to aggregate information, and, with the user's approval, dispose of the user's information (either anonymously or individually) depending on the time and place, individual business opportunities It can also be shared with vendors for this. Here, as it is more clearly understood, does it make sense for a user to be identified in connection with a transaction by the benefit of such time- and location-dependent individual business opportunities? You can also make a decision.

[246] For example, without the embodiment of the present invention, a static identifier that is conventionally associated with a mobile device provides a mobile app provider and other third parties with information about the use of the mobile device. It can also be aggregated. And by aggregating data about the use of mobile devices, app providers and other third parties can't get through the data from one-time relationships with users of that device, users of that device. It is also possible to obtain information including, but not limited to, information about frequent physical locations, calling habits, content preferences, and online transactions of the. By using some embodiments of the present invention, app providers and other third parties may be prevented from collecting information about Data Subject and related parties' use of mobile devices. And, according to some embodiments of the present invention, using dynamically created, modifiable, reassignable DDIDs different from traditional static identifiers, mobile devices, data subjects, or interested parties can be used. May be configured to provide the mobile device with the use of the mobile app requesting access to geographical location information (eg, directions and maps apps) without revealing the identity information of the mobile device.

[247] In one example, in embodiments of the present invention, by activating DDIDs rather than aggregating static identifiers, for immutable static identifiers, enhanced privacy, anonymity, security, And may be configured to provide accuracy. Thereby, the embodiments of the present invention can provide a solution to online fingerprints left in networks and the Internet. As a result, embodiments of the present invention empower the administrator to determine who can see what data and allow the data aggregator to connect data about a Data Subject or interested parties without the administrator's permission. It can be difficult to understand and give the administrator control over the propagation of information upstream or downstream.

[248] In one example of the invention, continuous access may also be provided due to the benefits of big data parsing with DDIDs to provide multiple levels of protection to abstractions. In addition, systems, methods, and equipment embodying certain elements of the present invention exclude access to the data required for effective big data analytics and are free or discounted in return for information. It does not suffer from tracking denials or the basic flaws of other initiatives that do not fit the economic model of providing the product or service. Do-not-track is a technology and policy suggestion that allows the Data Subject and others to opt out of certain tracking online by data collectors by websites and third parties, including analytics services, advertising networks and social networks. is there. While Do Not Track provides enhanced privacy, anonymity, and security to Data Subjects and interested parties, it offers customized, individually relevant offers to Data Subjects and interested parties, from online to big data analytics. Reject the gain to receive. This also impacts the financial benefits of big data analytics for vendors and service providers, as well as the Data Subject and stakeholders themselves.

[249] On the other hand, some embodiments of the invention have a net to positive impact on revenue (relative to revenue, net negative impact due to tracking rejection). This is because some embodiments of the present invention also allow the administrator to include data attributes in the TDRs that allow the recipient to use conventional tracking techniques and track the TDRs during their existence. Is. Administrators may also include more accurate information than is available via tracking alone to encourage personalization and customization. For example, the administrator may be interested in Data Subjects and/or interested parties that have been augmented with other, more up-to-date information that is useful to both the website and the Data Subject/and/or interested parties, and that has been sent to that website via the Privacy Client. The combination of attributes can also include specific data about past visits on the website.

[250] Referring to FIGS. 1 and 1A, one embodiment of the present invention resides in one or more computing devices 70, or resident in a network device and accessible through the network device. It may also include a computer network 72 where one or more remote privacy clients 60, consisting of computer hardware, firmware and software, send and receive requests and inquiries to one or more computing devices acting as privacy server 50. it can. The computing device 70 of the privacy client enables (i) the request for the service from the privacy server or the sending of the inquiry to the privacy server, (ii) the user interface function, and (iii) the application processing function. And (iv) provide localized storage and memory, program-installed smart devices (wearable, mobile or immobile smart devices), smartphones, tablets, laptops, desktop computers, or others. It is also possible to be composed of the computing device of. The computing device, which is the privacy server 50, responds to (i) requests for services and inquiries from privacy clients, (ii) centrally or decentralized management of the system, and (iii) large processing capacity Yes, and (iv) a large capacity personal computer, minicomputer, mainframe computer, or other computing device with a program installed that provides a large amount of storage and memory. Privacy server 50 may also be configured to perform one or more of the operations or functions described herein. The communication function between the privacy server and the privacy client may consist of either a computer network, the Internet, an intranet, a public or private network, or a communication channel and its assistive technology.

[251] Referring to FIGS. 1 and 1A, in another embodiment of the present invention, one or more computing devices 70 are resident, or network devices are resident and accessible via the network devices. One or more remote privacy clients 60 consisting of computer hardware, firmware, and software that can send requests and inquiries to and from one or more computing devices that function as privacy server 50. It can also include a computer network that receives services and responses. Here, the privacy server 50 includes means for electronically receiving and storing electronic information via the Internet, a plurality of Internets, intranets, and other networks, cards, portable devices, wearable It can also be sent to other devices or other portable devices. Here, the information about data attributes and DDIDs of the card, portable device, wearable device, and other portable device is corrected by the privacy server, and if so, until that time, the data attributes and DDIDs are updated. Including the above information about.

[252] The privacy server and privacy client
Modules may be implemented that include program code for executing one or more steps or actions of the processes or functions described herein. The program code may be stored on a computer readable medium accessible by the processor of the privacy server or privacy client. Computer-readable media are volatile or non-volatile and may be removable or non-removable. Computer readable media include RAM, ROM, solid state memory technology, write/erase ROM (“EPROM”), electronic write/erase ROM (“EEPROM”), CD-ROM, DVD, magnetic cassette, magnetic It can be, but is not limited to, tape, magnetic disk storage, other magnetic or optical storage, or other conventional storage technology or storage.

[253] The privacy server and associated databases may store information about TDRs, time periods/time stamps, DDIDs, attributes, attribute combinations, Data Subjects, interested parties, related profiles, and other related information. it can. The database associated with the privacy server is managed and accessed by an administrator, but in one example, is not maintained by others without the approval of the administrator. In one example, one or more privacy server authentication modules manage access to data via the TDRs. The privacy client will implement the desired response, activity, process or characteristic, and whether the TDRs are authorized to participate in the requested response, activity, process or characteristic at a particular time or place. You can also request the privacy server for the information it needs to contact the server. Also, the privacy client aggregates data about correspondence, activities, processes or characteristics involving TDRs associated with the privacy client, such as tracking data, so that it does not have to go back to the database for data extrapolation. You can also In one example, the insights collected by others can be part of the TDR for that time period.

[254] In one embodiment of the invention, the abstraction module 52 allows an administrator (which is a Data Subject or interested party) to link data about a Data Subject to an attribute, or different data about a Data Subject to various attributes. You can link to attributes that can be divided, combined, rearranged, and added in various attribute combinations. These combinations can include any combination of attributes, or combinations of previously created attributes associated with the Data Subject.

[255] This example for each intended response, activity, process or characteristic, including a privacy server, provides the abstraction module with the required response, activity, process or characteristic, for example, from the attributes. Identify information transmitted or stored by selecting only those and linking those data attributes to one or more attribute combinations, or separating those data attributes into one or more attribute combinations The administrator can limit the degree to be done. The administrator may then use the abstraction module to dynamically create and assign DDIDs to form a TDR for each attribute combination. DDIDs can also be configured to expire in a given delay or queue and may be reused for data related to other responses, activities, processes or characteristics, or to Data Subjects or interested parties. .. This allows you to avoid leaving a detailed trail of relevance outside the privacy server. In one example, before assigning or accepting a DDID so that a TDR is formed, the abstraction module can also verify that the DDID is not in use in another TDR. In order to do this verification, an additional buffer timeout period may be included to address potential outages and system downtime. The greater the number of TDRs associated with the number of data attributes generated for a desired response, activity, process or characteristic, the greater the privacy, anonymity, and security available. In this situation, an unauthorized person seeking access to one of the TDRs will only get access to that information contained in the TDR. In one example, the information contained in one TDR may be part of the attributes required for the desired response, activity, process or characteristic, and to determine other TDRs containing the required attributes. Or does not provide the information necessary to identify the Data Subject or parties that may be associated with the TDRs.

[256] In one example, TDRs according to abstraction modules, together with a particular category of attributes associated with a step, match one or more predetermined steps necessary to describe or perform a different correspondence, activity or process. It may be created by selecting or combining these attributes as required for a process and a particular response, activity, process or characteristic. The process of creating TDRs by the abstraction module may be performed directly by the administrator or indirectly by one or more persons approved by the administrator.

[257] For example, the first database that includes credit card purchase information may include information that the credit card issuer needs to perform big data analysis of the purchase information. However, the database need not include information identifying the credit card user. The information identifying the credit card user is represented in this first database by DDIDs, and the replacement keys (RKs) needed to associate users with DDIDs are accessible to privacy servers and system modules. It may be stored in another secure database. In this way, the information associated with DDIDs is unreadable to unauthorized persons, so if there is an unauthorized intrusion into the first database that contains credit card purchase information. , The system helps protect the identity of credit card users and limits financial losses.

[258] Furthermore, in one example of the present invention, real-time or batch analysis of data from portable/wearable/portable devices is performed without sacrificing privacy or anonymity of the user of the portable/wearable/portable device. It can be done in a way that is beneficial to the recipient, such as a service provider. Each user can be considered not only the device itself or the Data Subject associated with the use of the device, but also the parties involved in the portable/wearable/portable device in question. In exchange for special offers or other interests issued by the recipient, users of portable, wearable, or portable devices may, for example, be within a certain distance from a particular geographic location (e.g., 1 mile, 1000 feet, 20 feet). , Or packaging distance), or recipients and users who are within a given category (e.g., jewelry, clothing, restaurant, bookstore, or other discipline) relative to the location of a portable/wearable/portable device. You can also choose to have unspecified TDRs that are shared anonymously depending on real-time location, real-time activity, or for a specific amount of time. In this way, the recipient can obtain accurate, aggregated information about the distribution of customers in terms of age, gender, income, and other characteristics. These distributions allow recipients to more effectively determine which services, desired inventory and other sales, supply chain, or inventory-related activities they should provide to interested parties. Can be revealed by TDRs, which are shared by users of portable, wearable, and portable devices on the hours of the day. In one example, a Data Subject and interested parties, who may also be users of portable, wearable, or portable devices, (only know that the Data Subject or interested parties have registered which particular information Recipients (who may or may not be related to the Data Subject or interested parties) benefit from special arrangements and offers without disclosing personal information to the recipient unless the Data Subject and interested parties wish to do so.

[259] In an example of implementation of the invention, the authorization module may give the administrator administrative authority over who else is given access or usage rights to the TDR information. The administrator can also use an abstraction module that manages the degree of access rights that others have to certain elements of the information contained in the system. For example, a platform provider of portable/wearable/portable devices as an administrator may reveal the identity of the user, who is the device, the Data Subject or related parties, or the location of the user, who is the device, the Data Subject or related parties. It is also possible to provide performance data to manufacturers of portable, wearable, and portable devices without needing to do so. In addition, the portable/wearable/portable device platform provider can carry/wear the portable/wearable/portable device app provider without having to reveal the identity of the device, the Data Subject or the user who is the related person. • It can also provide the geographic location data needed by portable devices to use maps and other apps. Conversely, portable/wearable/portable device platform providers use the system to provide not only the user of the device as the Data Subject or a party, but also location and identity data about the device to the emergency 911 system. You can also do it. An example of an authorization module implementation may include allowing others authorized by the administrator to delegate authority, requesting the generation of TDRs associated with DDIDs.

[260] According to an example implementation of the invention, the recipient may customize the user experience and location opportunities collected by interested parties without requiring the identification of personally identifiable information. In addition, it is possible to use information about persons involved in portable/wearable/portable devices. For example, a band playing Country Western and Gospel in real-time or near real-time will receive a Data Subject or TDRs associated with the parties coming to the concert, thereby making Decides that he likes gospel and can adjust the song selection for the concert. Similarly, in stores that use video screens to display prizes and special offers, by receiving and analyzing TDRs associated with a Data Subject or stakeholder who is a client of a mobile, wearable, or portable device client, The store manager can know in real time when there are many customers with a specific distribution in the store. At that store, a video aimed at a specific distribution is played, and while communicating with the system of the store via a client of a portable/wearable/portable device, it responds to changes in the Data Subject or related parties, and changes the video throughout the day. be able to. Distributions derived from information in TDRs may include, but are not limited to, the age, sex, and income level of the Data Subject or related parties. Similarly, stores that use real-time geographic location to identify a customer's specific location within the store may be related to the Data Subject or stakeholder's personal or brand preferences, or prize purchasing preferences. By receiving and analyzing TDRs that perform, it is possible to issue special discounts and offers to customers who are Data Subjects or related parties via portable/wearable/portable devices. Here, the TDRs include external information that is added in real time based on the data subject or a product placed in a place in the store where the related person is.

[261] As an example of an implementation of the present invention, the privacy server abstraction module of the privacy server creates the DDIDs while creating the TDRs while the combination of the DDID and the desired attribute is combined, so that the DDIDs can be used as a device, service of the data subject. Assign to a combination of attributes required to respond to requests and inquiries from privacy clients residing on a provider's equipment, accessible cloud networks, or multiple locations including but not limited to the same computing equipment. The privacy client TDR is also free to interact with the recipient for a set time, response, activity, process, or characteristic. In one example, at the end of the interaction with the specified recipient, the Privacy Client returns an augmented TDR with a combination of attributes about the Privacy Client's activity to the privacy server and associated database. Good. Then, the privacy server may not only update and store the attribute combinations of the aggregated data profile of the Data Subject in the secure database, but may also push back the various attribute combinations to the particular Data Subject. .. In one example, at this time, the DDIDs assigned to the attribute combinations may be reassigned for other responses, activities, processes or characteristics, or for the Data Subject to leave the data relationship unknown. Good.

[262] Other embodiments of the invention are described in detail, including various systems and equipment. In one embodiment, a system for improving electronic data security is disclosed. In one example, the system is an abstraction module configured to dynamically associate at least one attribute with at least one Data Subject; generate DDIDs, or act as DDIDs, time-specific and dynamically changing. An abstraction module configured to receive or change a value that is associated with a DDID, and an abstraction module configured to associate a DDID with at least one Data Subject; and to record activity associated with DDIDs, and A maintenance module configured to correlate additional DDIDs, recorded activities, and times DDDDs are used to perform recorded activities using time keys (TKs) or otherwise. But it's okay. In one example, the abstraction module is configured to add or remove attributes associated with at least one Data Subject, and the abstraction module changes the attributes already associated with at least one Data Subject. May be configured as.

[263] In another embodiment, a device for performing secure, private, anonymous activities on a network is disclosed. In one example, the device is a processor configured to execute a program module, the program module including at least one privacy client module; a memory connected to the processor; and data over a network. A receiving communication interface may be included, and the privacy client resident as a privacy server on the device of the data subject, the device of the service provider, the accessible cloud network, or the same computing device is the network from the privacy server. It is configured to receive TDRs containing the DDIDs and associated data attributes needed to carry out the above activities. In one example, the privacy client may be further configured to capture activity performed with the device and associate activity performed with the TDRs. In another example, the privacy client may be configured to send captured activities and TDRs to the privacy server. In one example, the privacy client may reside as a mobile app on a mobile device. In another example, the privacy client may reside as a cloud-based app on an accessible network. In another example, the privacy client may reside on the same computing device on which the privacy server resides as a local app.

[264] In another example, the device may include a geographic location module, wherein the TDRs are modified with information from the geographic location module, and the TDRs are information about the identity of the device. Restrict access to. The device may include a user interface configured to allow a user to modify the TDRs, including an option to modify the DDID, or a data attribute associated with a particular TDR. The user interface may also include selectable options to share the TDRs only with other network devices that are in physical, virtual, or theoretical proximity to the mobile device.

[265] In another example, the device may also receive targeted advertising or sales information depending on the physical, virtual, or theoretical location depending on the TDRs. Here, the TDRs include distribution information related to a user of the device, and further include receiving targeted advertisement or sales information according to the distribution information. In another example, the TDRs may include information regarding purchase transactions with or desirable for use with the device, and further to receive targeted advertising or sales information in response to previous or desired purchase transactions. including.

[266] In another embodiment of the invention, a system for providing privacy and anonymity of electronic data is disclosed. In one example, the system comprises at least one user device having a first privacy client running on a user device; at least one service provider device having a second privacy client running on a service provider device; and , At least one privacy server in conjunction with the network, the privacy server communicating with the first and second privacy clients, the privacy server comprising: It includes an abstraction module that links the Subject to data attributes and attribute combinations and divides the data into data attribute and attribute combinations, the abstraction module associating a DDID with the data attribute and attribute combinations. In one example, the privacy server may include an authorization module that generates one or more of the DDIDs. In another example, the privacy server may include a maintenance module that stores the DDIDs combinations along with their associated data attributes and attribute combinations. In another example, the privacy server may include a validation module that validates data attributes, attribute combinations, and aggregation of DDIDs. In another example, the privacy server includes an access log that collects and stores information related to the DDIDs and data attributes for use in one or more post-mortem analysis in the event of an error. Good. In one example, the DDID becomes invalid after a predetermined time and the abstraction module assigns the DDID to another data attribute or Data Subject.

[267] FIG. 1B shows some examples of how allocation, application, invalidation, and reuse of DDIDs occur. Here, in the implementation of the embodiment of the present invention, DDIDs may exist permanently, but may be reused for multiple Data Subjects, data attributes, attribute combinations, correspondences, activities, processes, and characteristics, Please note that. DDIDs are reused, but two identical DDIDs cannot be used at the same time unless desired and approved by the administrator. Reassignment of DDIDs may be accomplished using existing data collection and analysis functions that reassign DDIDs to similar attribute combinations or Data Subjects or to distinctly different attribute combinations or Data Subjects. This reallocation increases the privacy, anonymity, and security potential of dynamically created and mutable digital DDIDs.

[268] As shown in FIG. 1B, the system may be configured such that any DDID allocation, revocation, or reuse occurs for any one or more of the following: (1) Changes in the purpose for which the DDID (and its associated TDR) was created, for example, the purpose of the property viewing session, Data Subject, transactions, etc.; (2) Physics associated with the DDID (and its associated TDR). Changes in physical location, such as exiting physical location, arriving at general physical location, arriving at specific physical location, entering physical location, or other physical location activity; (3) DDID A change in a virtual location associated with (and associated TDR), such as entering a virtual location, changing a virtual location, exiting a virtual location, arriving at a particular page of a website, to a particular website Or, (4) with respect to changes in time, eg, at random times, at predetermined times, at specified intervals, or on other temporary basis. As will be appreciated, external to the system, DDIDs are irrelevant because there is no discernible relationship between the relevant data and the Data Subject or stakeholder identity, or contextual data associated with different DDIDs or TDRs. , Separate the data from the context. Internally to the system, the relevant information is maintained for use because it has been approved by the Data Subject and trusted parties/agents.

[269] Figure 1C-1 shows a trusted person or a trusted agent (referred to as "trusted agent" in Figure 1C-1 but hereinafter referred to as "trusted agent" or "trusted person". The concept of circle of trust (CoT) from the viewpoint of First, a Data Subject is included in the lower left of the figure. Participation by the Data Subject is generally in the form of a dichotomy of whether or not to agree to the "no-negotiable" online terms of use, using the traditional "announce and agree" model, so the latest data Data Subject is not included in the diagram of the system used. After the initial point, the Data Subject typically loses all privileges that affect what happens to those data, because it's a product, not a customer. It is well known that this is a broken model in the digital era, and rarely effectively limits current or future data usage.

[270] Note that a Data Subject may participate in any number of circles of trust, with more than one credible person working together in association with a circle of trust. Circles of trust can be implemented with a centralized or federated model for higher security. The arrows in FIG. 2 indicate the movement of data. Contains information with different data inputs and outputs.

[271] FIG. 1C-1 shows a data processing flow for two embodiments of the present invention. In the first exemplary embodiment of the present invention, the user (1) participates in a desired action in browsing the web, in this exemplary embodiment, one or more TDRs (each TDR is initially associated with an activity associated with the TDR). Form a DDID with the purpose of collecting and retaining the data attributes that are to be stored, or with a data attribute or combination of attributes retrieved from a Data Subject's aggregated data profile). It may also indicate that the user is interested in using the system to create data input for a particular Data Subject (in this example, the Data Subject). Data related to web browsing involving one or more TDRs is recorded and collected by the system and sent to a trusted person or administrator acting as a trusted agent (3). TDRs that reflect the data collected and recorded in connection with web browsing are those web browsing that an administrator acting as a trusted agent chooses to augment the aggregated data profile of a user or Data Subject. Shows the output of. In the second exemplary embodiment of the present invention, the user (2) uses the system to create a private, anonymous version of a dataset owned by the user and containing personal information about the Data Subject (1). You can also indicate that you are interested in. In this example, the user's dataset containing personal information about the Data Subject may serve as input to the system. The system may also identify and record data values contained in datasets that reflect personal information, and the Data Subject is subject to processing by an administrator acting as a trusted party or trusted agent (3). It is also possible to select the personal information that replaces the DDIDs for which one or more replacement keys (RKs) are needed to re-identify the personal information about. In this example, the resulting modified dataset shows the output from the system containing dynamically changing DDIDs instead of the Data Subject's personal information. In this way, access to personal information regarding any one or more Data Subjects may not be re-identified and the relevant Data Subject has the "right to be forgotten", ie deleting digital records from the Internet. As we can, we can change RKs in the future.

[272] As shown in the box labeled "Privacy Policy" and "Authorization Request" in Figure 1C-1, permissions ("PERMs") managed by trusted parties are represented. In addition, the use of the data can be controlled by the "user". A "user" may also be the Data Subject itself, who is the subject of the data being featured (e.g., user, consumer, patient, etc. for his data, referred to herein as the "target user"), It can also be a third party that is not the target of the data covered (for example, seller, vendor, health care provider, legally authorized government entity, etc., referred to herein as a "non-target user") ..

[273] Also, PERMs related to permitted actions, such as which data is used by whom, for what purpose, for how long, etc., are contexts that provide anonymity to a Data Subject's identity and activity. , When, where, how to use DDIDs, when to use other privacy-enhancing technologies in connection with DDDDs or in place of DDIDs, when to provide certain information that facilitates transactions, etc. You can also specify a desired level of anonymity for.

[274] In the Data Subject implementation of the present invention (ie, DRMI), the target user is interpreted as a fine-grained dynamic authorization, or selected as a "custom" option when specifying more detailed dynamic parameters. Customized PERMS (eg, Gold Silver Bronze. This is just an example, mathematically a set of discrete choices, or between lower and upper bounds, when using data according to a defined policy. Note that it may be represented by a continuous value).

[275]Dynamic Anonymity (DRMD) "managed" implementation allows non-target users to use and access data in accordance with applicable company legal and regulatory data use, privacy and anonymity requirements. You can also establish PERMs for

[276] Within CoT, which is reflected in Figure 1C-1 based on PERMs, business intelligence, data analysis, and other processing is performed on one or more Data Subjects, as shown in Table 3 below. , D, T, X combinations or interpolation may be used.

[277] Figure 1C-2 shows a circle of trust (CoT) from the perspective of the Data Subject.

[278] FIG. 1D illustrates a smartphone app that can record both geographical location and blood pressure levels. With Dynamic Anonymity, such a device splits the data into two streams, both of which are important information protected within the CoT if it is blocked or compromised (stored and inspected). Without adding, each can be hidden so that personal data (PD) is not revealed.

[279] In particular, Figure 1D shows the following:
1. The blood pressure monitor application (A) contacts a reliable person in the trust circle (B) and requests the DDID of the patient who is the data subject.
2. Circle of Trust CoT provides the DDID of the Data Subject.
3. An app run by a trusted person returns two periodically changing sets of information (one is GPS data, the other is blood pressure level). Each set consists of DDIDs, offsets (to hide blood pressure level data and geographic location), and encryption keys updated every time period. (These are stored in the database for later use.)
4. The monitor app sends two encrypted and hidden data streams to the "proxy" app managed by Dynamic Anonymity or to the network appliance (C) of the internal network. (Here, location and level have co-periodically varying offsets applied to them.)
5. The "agent" (C) uses the data stream (D and E) from a trusted party (containing only the decryption key) to transform the transmitted data into "plaintext" .. The agent also hides the incoming IP address and stores the DDIDs and the hidden blood pressure level data (F) or GPS position (G) data flow (including information of multiple Data Subjects) in the corresponding database ( H) and (I).

[280] In Figure 1D, at each point outside the circle of trust (and outside the smartphone itself), patient data is protected. No personal data (PD) is made available or generated.
-Transmissions to and from trusted parties (1 and 2) do not contain personal data that violates privacy or anonymity and is not stored in the trusted party's database.
-Location and blood pressure level (4) means that the data itself does not reveal or contain anything about the true location or blood pressure level of the patient, either directly or indirectly As such, they are sent separately (blocking either one will reveal nothing), locked by DDIDs and hidden.
-Dynamic Anonymity's agent (C) must be connected to a trusted party to decipher the data (prevent man-in-the-middle attacks). Each consolidates multiple streams of data after decryption so that the original IP address is not associated with the decrypted data.
-Once stopped, if you reside in two different databases (H and I), the host company can also draw two relationships, let alone link each set of data to the Data Subject that generated the data. As you can't, blood pressure level and location data have different sets of DDIDs.

[281] FIG. 1E illustrates the use of an embodiment of the invention in which a new clinic supports the task of choosing the location to see patients aged 20 to 30 with sexually transmitted infections (STDs). It is shown. One "cleansed" data set may show the incidence of STDs aggregated from neighbors to protect privacy and anonymity. Another data set may also show how many patients live in each neighborhood. However, even if these are aggregated, it is not possible to know exactly how many STDs are identified in a particular age group.

[282] Dynamic Anonymity alleviates this dilemma by supporting two different modes of analysis.

[283] If the data must be exposed to the outside (ie, outside the CoT), private data elements are hidden, encoded as DDIDs, and stored within the CoT along with their resulting relevance. Furthermore, if necessary, the data (or field) type identifier is hidden in the same way.

[284] Then, after being parsed, the results of the parse can be linked back to the original Data Subject, field type, and value (if allowed).

[285] Alternatively, between different trusted parties within the CoT, between different data stores within the same trusted party, or between trusted parties and app developers whose data stores are outside the CoT, Dynamic Anonymity allows lossless parsing through the use of federated and anonymized queries.

[286] Again, consider the issue of choosing a location for a clinic to see patients aged 20 to 30 with STDs. The Dynamic Anonymity system allows target queries to span multiple datastores and does not know what each participant is for, thus allowing queries to be split so there is no risk of PD leakage. , Improve existing technology.

[287] In this scenario, the number of patients aged 20 to 30 with STDs in multiple (reasonably large) geographical areas is queried to a large number of trusted parties within a circle of trust. This aggregate inquiry is divided into several steps as follows.
1. Look for patients aged 20 to 30 in a large geographical area.
2. Select only patients with STDs.
3. Select only those patients whose privacy and anonymity policy allows this level of analysis.
4. "Bind" these results to the home address of these patients.
5. Aggregate these results by neighborhood area and clarify the number of patients.

[288] The actions necessary to satisfy this inquiry span entirely different data stores, different parties, but of course are protected and facilitated by a circle of trust.

[289] In FIG. 1E, the following process is shown.
1. A future clinic owner will send an inquiry to a trusted person and ask them to find an individual aged 20 to 30 with STDs.
2. Reliable people contact medical data stores and ask them to find individuals aged 20 to 30 with STDs.
3. Look for matching records in the medical data store (judge by DDIDs, not by identifiable key).
4. Matching DDIDs are sent to trusted parties.
5. Reliable persons solve these DDIDs to reveal the identified individuals.
6. Trusted parties filter the list by individuals with privacy and anonymity policies that allow this particular inquiry.
7.CoT aggregates the number of people (or incidence if inquiries are incomplete) by neighborhood area using their address database and produces the desired result.

[290] In this scenario, the companies that run databases related to healthcare need not know (or leak) the identity, location, or other identifiable information of the patient who owns the data they process. Absent. The records they process are locked by the DDID and eventually hidden. As such, no personal data is generated when performing a particular query or sending the results.

[291] Note that the inquirer does not have access to this information. The only involvement with CoT is to query and receive PD-free results that are highly aggregated. The inaccessibility of this information does not affect the quality, accuracy or precision of the results. Therefore, Dynamic Anonymity eliminates personal data that contributes to the end result and weakens privacy and anonymity without any benefit to anyone. By filtering irrelevant data, time-consuming and tedious analysis, Dynamic Anonymity certainly increases the usability and value of the information it receives.

[292] Personal data is only generated temporarily, such as when DDIDs are unraveled, within a circle of trust (where appropriate for such information) managed by a trusted party. Such behavior is transient, leaving no trace other than the result of the intended query, and for higher security it is restricted to certain dedicated servers. The use of DDIDs within the context of circles of trust avoids deficiencies in normal data analysis that can yield discriminatory or identifiable results.

[293] Figure 1F illustrates the use of one embodiment of the present invention in which a shoe maker sends a new line of shoe coupons to people who recently did a web search for running in a city. be able to. Instead of offering a shoe discount, the manufacturer wants to receive the target consumer's email address and address, and send a survey of the satisfaction of the new shoe to those who used the coupon.

[294] Description:
1. Manufacturers outside CoT purchase a list of matching DDIDs from search engines.
2. The DDIDs will be submitted to one or more trusted parties, along with offer letters and policy changes, to allow access to the Data Subject email address and address (if accepted).
3. Each trusted party forwards the offer letter to a Data Subject that matches the DDIDs (if you opt in to receive such offers).
4.When a Data Subject recipient receives an offer, the recipient's policy is (temporarily) updated to allow the address and email address to be published to the shoe maker.
5. For this particular offer and for a limited time only, the shoe manufacturer that became part of CoT will receive a list of addresses and email addresses of those who wish to receive the coupon. This list should be accurate, targeted, and therefore of greatest value to shoe makers. This is exactly what CoT adds to the value of information, with greater privacy and anonymity. Shoemakers are relieved to receive emails and letters in this way to people who are very interested in their offers.

[295] FIG. 1G is based on the example of FIG. 1D, in which a GPS-based blood pressure monitor reliably memorizes the patient's location and blood pressure through Dynamic Anonymity. Dynamic Anonymity is activated as follows.
1. If personal data is not included in the data held, reduce the burden of dealing with HIPAA data by the management involved in the flow of data processing.
2. Access and use of data by physicians will meet HIPAA obligations.

[296] The following scenario assumes that the Data Subject patient and his doctor both have accounts in a circle of trust.

[297] Description:
1. The monitoring app allows patients to update their privacy and anonymity policies so that they can work with a trusted person on the patient and give the doctor access to the patient's blood pressure level (not GPS location data). To do. This permission may be temporary (such as the temporary nature of photos shared in Snapchat, it expires after a certain period of time), or it may be continuous.
2. The doctor browses the blood pressure monitor website (via a web browser), launches a Javascript-based blood pressure level browsing app that runs on the doctor's browser rather than the monitor company's server. (That is, the work that requires the data to be personalized is done through the server of a trusted party that is itself trusted. See steps 4 and 5 below.)
3. The blood pressure level browsing app prompts the doctor to log in via a trusted person (many apps that allow approval using Facebook (registered trademark) or Google (registered trademark) accounts). Similarly, a trusted party receives a session cookie to identify themselves. (Facebook (registered trademark) is a trademark of Facebook Inc.)
4. After selecting a range of hours for the doctor to view, the viewing app requests the trusted party for the patient's corresponding DDIDs and offsets.
5. The trusted party enables doctor access to this information (checking the patient privacy and anonymity policy terms) and returns DDIDs and offsets.
6. The browsing app contacts its company website, requests the blood pressure data corresponding to the DDIDs, receives the result, applies the offset and graphs the blood pressure level.

[298] Here, the image on the doctor's screen becomes the protected PHI data, HIPAA. When the doctor prints the data, the paper becomes HIPAA eligible. When the doctor finishes browsing the graph, he logs out or closes the browser, the application ends, and the data is deleted.

[299] The re-identified, HIPAA-managed data resides only on the doctor's browser. The blood pressure level data stored in the original app provider's database remains untouched and hidden. Reliable data will be similarly unaffected.

[300] Permission to view blood pressure data is only enforced within the circle of trust. Browsing apps alone, or just the app's origin server, cannot enforce it (as is common practice). This means that intruders cannot gain unauthorized access simply by hacking into a blood pressure level viewing app, as the data is not there in any available or identifiable form. Show. Value for supporting data privacy and anonymity, as well as personalized medicine and medical research, through Dynamic Anonymity DDIDs dynamic data hiding capabilities, along with Dynamic Data Privacy and Anonymity management capabilities of the Circle of Trust. Is maximized.

[301] In Figure 1H, the different nodes shown in 1H-A are associated with or re-identifiable to each of the Data Subjects so that they can be tracked, investigated or analyzed by a third party. Shows data elements related to different Data Subjects of. 1H-B simplifies and illustrates elements of the same data that are retained with Dynamic Anonymity without loss of context. The Rights and Privacy Act in Family Education (FERPA) is a federal privacy law that regulates access to and disclosure of student educational records by exposing personally identifiable information (PII). However, according to FERPA, PII is not disclosed. If the PII is removed from the record, the student will be anonymous and the privacy will be protected, resulting in the disclosure of unspecified data. In addition to the legally defined categories (name, address, social security number, mother's maiden name, etc.), FERPA defines PII as follows: “Connect or connect to specific students, singly or in combination, that do not personally know the circumstances of interest, or allow those who are valid in the school community to identify students to a reasonable extent. Information." As shown in 1H-B, Dynamic Anonymity's Anonos-enabled circle of trust allows PII to be managed in a controlled manner, with the ability to obscure the relationship between each Data Subject and each data element. Data relevant to education can be used without disclosure.

[302] FIG. 1I illustrates an example of a process of performing isolation level determination (DLD) and generating anonymity measurement score (AMS), according to one embodiment of the invention. The determination of DLD involves mathematical and empirical evaluation of the uniqueness of the data elements prior to isolation to assess the level of isolation required to reduce the probability of identification and reassociation by an intruder without proper authorization. Analysis is necessarily included. The DLD value is also used as an input to determine the appropriate level of isolation/replacement for different types of data elements.

[303] AMS provides a mathematically determined determinism that sensitive, personally identifiable information can be recognized by third parties, down to the level or category of anonymity. Also used to correlate levels. In other words, the value of AMS can also be used in evaluating the output from the Isolate and Replace activity, which determines the level type of consent required before the data is used.

[304] In step (1) of Figure 1I, the data attributes are evaluated to screen DLDs. That is, data elements should be protected from anonymity, to determine whether it may be possible to directly or indirectly disclose personal, sensitive, identifying information, etc. Be analyzed. In step (2), the data elements are dynamically anonymized, at least in part, based on the determined DLDs, by means of separation. In addition, the data elements also go through the process of replacement. In step (3), after separation/replacement of DDIDs, for example, a mathematical function/algorithm( For example, calculation is performed using a mathematical function/algorithm whose output is reflected in FIG. 1J. Finally, in step (4), the score/rating calculated in step (3) above requires consent/participation by the Data Subject, as in the example of AMS usage reflected in Figure 1K below. The level of consent/engagement required by the Data Subject for the anonymized data attribute with respect to what level of discretion/use is to be exercised by a third party for the anonymized data attribute Used to identify.

[305] Different categories of information include different statistical probabilities that can be re-identified. All data elements are associated with their own level of uniqueness, as well as their level of uniqueness when combined with other data determined by their placement, order, and frequency. For example, when looking at a single data point, the probability of being female or male is approximately 1:1 for each person, so a social security number is more unique than a single data point like gender. , Easier to re-identify. Gender is not as unique as an identifier compared to social security numbers, so gender is rarely used independently to re-identify someone compared to social security numbers.

[306] Anonymity measurement score (AMS) metrics are tied to re-identification statistical probabilities to create multiple assessments, depending on the level or degree of disassociation or substitution applied to the data element. As an example of a single data point, a social security number that has not been disassociated or replaced at all can be an AMS rating of 100 in the sense that its uniqueness classifies it as having a very high risk of reidentification. On the other hand, gender as a single data point identifier without disassociation or replacement can be an AMS rating of 10 because it is classified as having a low risk of re-identification without de-identification measures.

[307] In an example using a social security number as a single data point, the Level 1 implementation retains the originally assigned value, ie the permanent assignment (eg, if the data is used in hardcopy form). However, DDIDs can also be assigned for purposes of disassociation or replacement. For social security numbers, when level 1 is applied to DDIDs, the AMS score is reduced by 10% and the modified AMS score is 90. As a result, the level of risk associated with re-identification is still high, but it is safer than elements that have not been disassociated or replaced.

[308] In the Level 2 implementation example, the social security number retains the initially assigned value until it changes in one direction, that is, variability on the fly, for the purpose of associating or replacing. Has assigned DDIDs. (For example, the value of data can be changed unilaterally by sending new information to a remote card, portable, wearable, or other portable device that includes the ability to receive and store the information electronically.) Social The security number's AMS score is thereby reduced by another 10%, achieving the AMS's AMS score.

[309] In this example, continuing with the Level 3 implementation, the social security number retains the originally assigned value, but has DDIDs assigned for the purposes of disassociation and replacement, but the DDIDs are bidirectional. That is, with dynamic variability. (For example, by dynamically transmitting and receiving data between a client or server and a cloud or corporate device that has the function of receiving specific data and dynamically changing it, the value of the data can be The social security number's AMS score is further reduced by 50% to 40.5.

[310] By using DDIDs and applying de-identification measures to the data points by disassociating and replacing associations, the risk of re-identification is reduced. The AMS score determination is derived from a function of the probability of reidentification of the identifiers that have followed. Combined with multiple processes used to obscure data elements, this process is used to determine various functions such as authorized use, level of authorization required by the user before data use, and other categories. And other types of classification systems. This process can be applied to single or aggregated AMS scores. The aggregated AMS score represents the likelihood of re-identification of multiple data points, expressed as a composite AMS score to represent the level of uniqueness of the combined data points.

[311] As an example of a possible category classification system, AMS scores are divided into categories A, B, and C. Here, Category A is data with a single or aggregated score of 75 or more, and can be used only with the current clear and clear consent of the Data Subject. Category B applies to datasets that have a single or aggregated score of 40 to 74.9 and can be used with (i) current or (ii) prior explicit consent of the Data Subject. Category C is when the single or aggregated score is 39.9 or less and the dataset can be used without the consent of the Data Subject.

[312] In the example shown in Figure 1J, for each identifier other than the social security number discussed above (ie, credit card number, first name, last name, date of birth, age, gender), the associated dissociation is performed. The AMS score with or without replacement is shown in the first column. In the next two columns (i.e.Level 1 and Level 2) the AMS score is reduced by 10% each and in the last column (i.e.Level 3) the AMS score is further reduced by 50% and the permanent allocation (level 1), in-situ variability (level 2), dynamic variability (level 3), the AMS score decreases as the ambiguity possible with DDID increases.

[313] As noted above, FIG. 1J shows an example calculated anonymity measurement score, consistent with one embodiment of the present invention. These AMSs are for illustration purposes only; certain types of personally identifiable information are more likely to expose the true identity of the Data Subject than other types of information, and add additional disassociation or replacement. We will show the fact that the anonymity of the Data Subject can be increased by the anonymization system and system by the level of variability (level 2) and dynamic variability (level 3).

[314] As mentioned above, FIG. 1K, in combination with one embodiment of the present invention, provides a category for the level of consent and involvement required by the Data Subject for the calculated anonymity measurement scores. Is illustrated. The categorization indicates the fact that for purposes of illustration only, some aggregated scores apply to the treatment of different categories. For example, Category A data can only be used with the current clear and unambiguous Data Subject consent, and Category B data can be used only with the current or previous unambiguous Data Subject consent. , Category C data can be used without the consent of the Data Subject. Other schemes may be used to meet the needs of a particular implementation.

[315] FIG. 1L shows an example of an embodiment of the present invention in which DDIDs are used for emergency contact purposes. In step (1) of Figure 1L, to determine the appropriate emergency contact features, for example, whether the house is in a flood zone, people are immobilized, or if specific life-saving devices or medical procedures are needed. At the same time, the data attributes are evaluated. In step (2), the relevant data elements were dynamically anonymized and obscured by trusted parties by association detachment/replacement using DDIDs to protect citizens' privacy and anonymity. The information is sent to the emergency contact database where the DDID has been obscured. In step (3), the information is evaluated by a trusted party to determine if the data element should address a particular emergency. Finally, in step (4), in order to reveal the desired information, or the information represented by the DDIDs only during an emergency and its response, a trusted party has a key associated with the obscured emergency contact database ( AKs) and replacement keys (RKs).

[316] In the example embodiment reflected in FIG. 1L, the required related keys (AKs) and replacement keys (RKs) are added when an appropriate triggering event occurs, so The data resides in the emergency contact database, with the dynamic DDID obscured, in order to prevent its identification from being recognized or re-identified. Triggered actions taken by trusted parties cause time-limited AKs/RKs to be issued for some of the relevant data at a particular level of ambiguity or transparency, depending on the type of event. The information that can be identified is maintained in the emergency contact database, but the dynamic DDID is ambiguous. A trusted person-managed data mapping engine provides correlation information about dynamically changing DDIDs and AKs and RKs that is needed to identify or re-identify the data provided in the event of an emergency. Maintain.

[317] Policies outside the system should ensure that all information is not leaked at once, and that irrelevant but sensitive information is not leaked at any time and at what level of ambiguity. Or whether transparency is appropriate, as well as which information is relevant for what situation and at what stage of the situation. These permissions are coded for easy access as a trigger in an emergency. This method allows two-way communication and verification of location and affected individuals compared to static lists and one-way communication only.

[318] AKs and RKs will be changed for each emergency and re-introduced into the emergency contact database so that information will be maintained and maintained electronically with the DDID obscured. That is, a new trigger is required to allow a part of the data to be read by the new AKs or RKs after the AKs or RKs issued in response to the previous situation. (That is, after resolution of an emergency, previously issued AKs and RKs cannot reveal certain existing information related to dynamically changing DDIDs.) And anonymity are protected, while granting access to the appropriate data for a limited amount of time also protects the public's safety in large-scale emergencies. As an emergency management side, this can reduce the necessity of capturing a large amount of information and adopting a procedure for coping with it in a large-scale emergency.

[319] In addition, new data can be added about an individual during an emergency, such as "missing" or "missing" status designation during evacuation. According to an embodiment of the present invention, this new input becomes part of the profile of the person kept stationary and, if useful for similar or ensuing emergencies, for future approved use. Maintained and maintained.

[320] In the local opt-in example, citizens may also store information that may be needed in an emergency in an emergency database with a DDID obscured. The emergency database may be stored locally or anywhere, but must be interoperable in case of multiple jurisdictions. Once the citizen's data has been entered into the system with the DDID obscured, triggers managed by trusted parties will be required to identify and re-identify the appropriate components of the stored data. No one can view or access the data in a recognizable and re-identifiable state until dynamic and contextual AKs and RKs are issued.

[321] Two examples of embodiments of the invention from an emergency management perspective include:
1. Interactive screens display overlays that correlate Geographic Information Systems (GIS) and other data with location-specific data. That is, clicking on a house will display the information provided by the citizen in addition to the information that the period under jurisdiction possesses about its property, along with the associated risk of disaster. For example, flood alerts are a good example of notifications that give different amounts of information to different citizens depending on their particular location. General flood warnings are issued throughout the area, but specific alerts should be issued directly to flood areas where the risk of flood is higher.
2. Older forms, such as electronic tables, may be augmented to provide non-geographic data.

[322] The above two forms are interoperable, as are the data displayed either on each other or in links.

[323] In the case of forecasts and warnings, the locality of the meteorological phenomenon (determined by weather radar, GIS mapping, etc.) determines the subset of information that may be further published in the database. ..

[324] In another example, suppose a criminal is investigating a particular distribution as a target. In this situation, DDIDs such as contacts and statistics are relevant, in addition to specially obscured location data to create a general perimeter for outgoing messages. Once the relevant data fields and their DDIDs are activated, individuals matching the statistics will be identified and included in the notification of criminal activity.

[325] In emergencies requiring evacuation, this information is triggered to assist evacuation personnel and identify citizens who need further assistance in an emergency, as well as to assist paramedics in more effective staffing. To be done. In other examples, such as Blizzard, paramedics can use GPS information related to the patient's mobile device to inform the exact location of a renal dialysis patient in need of emergency snowplow delivery in the city. The system is triggered. The GPS information is displayed by unrecognized and unspecified DDIDs until AKs or RKs reflecting appropriate correlation information are issued by the trigger.

[326] Just-In-Time-Identity (JITI) enables contextual security and privacy

[327] Here, the terms "run-time identity" and "JITI" are used to refer to the methods and systems of dynamic anonymization that will be described below. Here, the terms “JITI key” and “key” are used to refer to “related key”, “replacement key”, “time key”, “AKs”, “RKs”, “TKs”, and “key”. Be seen.

[328] The general purpose granularity, context, methods and systems for protection of programmed data disclosed in this section include who can access the data (Anonos Just-In-Time-Identity (JITI (Because the data can't be understood without the key), look at who has access to the JITI key and the range of uses possible with each JITI key.

[329] Enforce data privacy and security policies, both technically and programmatically, contextually and flexibly, down to subordinate data elements, or down to the level of each data element By doing so, JITI maximizes the use of authorized data while minimizing the use of unauthorized data. JITI facilitates compliance with established privacy policies and auditability by enabling mathematical, statistical and mathematical measurements and monitoring of data usage. JITI allows the same data store to programmatically support privacy policies that apply to multiple companies, states, regions, countries, industries, etc. at the same time, transforming incomprehensible forms of data from DDIDs By dynamically changing the stored data, the changing requirements of the policy can be adapted in real time.

[330] As detailed herein, data that has been reduced by JITI to the level of the smallest data element (eg, reduced to individual data levels) is labeled as Dynamic De-Identifiers (DDIDs). By replacing, it is dynamically obscured. For example, instead of storing the real name of an individual, that person's name is replaced by the DDID. Importantly, JITI replaces data elements with the data layer, rather than masking the data at the presentation layer. By replacing the data elements with DDIDs, the data lowered to the element level can be dynamically hidden in the data layer, and by breaking the relationship between the data elements, the DDIDs can be understood and “converted” into a form. Without access to the JITI keys required for data, data will be difficult to track, profile, infer, infer, analyze, and directly or indirectly understand and correlate. For the purposes of this application, "transform" means to modify, shorten, compress, code, replace, interpret, operate, translate, encrypt, decrypt, assign, swap, or mechanical, physical, electronic, quantum. It means, but is not limited to, performing mathematical functions/recognition operations on DDIDs by static or other means.

[331] Returning to FIG. 1H, the sphere on the left side of FIG. 1H shows the interrelationship between the top three spheres representing data elements exposed by metadata (ie, data that provides information about other data). , And the data element for the interrelationship between the four spheres below that represent the data element. This allows for tracking, profiling, guessing, estimating, analyzing, understanding and correlating, represented by the dotted lines between the left spheres in Figure 1H. On the right side of FIG. 1H, the different designs on each sphere represent the unique dynamic anonymous child (DDID) used in replacing the data elements represented by the sphere. As a result of using different DDIDs, there is no metadata or association for any of the spheres on the right side of FIG. 1H, which represent the interrelationships between the spheres that represent the data elements. Without access to the JITI key needed to put DDIDs in an understandable form, data elements cannot be replaced with DDIDs, and tracking, profiling, inferring, estimating, analyzing, understanding and between the spheres that represent the data element. It is significantly more difficult to try to establish the correlation of.

[332] Due to front granularity, context, and programmed enforcement, it is easy to audit compliance with rear data protection (eg, security, privacy, anonymity) while protecting the same data. Increasing the responsibility and confidence necessary to accept a wide range of domestic and international data analytics and use it to maximize the value of the data. The same data may be subject to the requirements of different jurisdictions, depending on the source and use of the data. For example, data representing a heart rate reading (eg, 55 beats per minute) is subject to different privacy policies, depending on how the data was captured.

[333] For example, if the data was captured in the United States using a personal health device, the use of the data is subject to the terms and conditions of the device and app used to capture the information. If the data was captured in the United States in the context of healthcare services, the use of the data is subject to the Federal Health Insurance Portability and Accountability Act (HIPAA) and applicable state legislation. If the data were captured in the United States in connection with federally funded research, the use of the data is subject to "common rules", as codified below. Department of Agriculture Federal Rulebook (CFR) Volume 7 Part 1c; Ministry of Energy CFR Volume 10 Part 745; Aerospace Agency CFR Volume 14 Part 1230; Ministry of Commerce National Institute of Standards and Technology CFR Volume 15 Part 27 CFR Vol. 16 Part 1028 by the Consumer Product Safety Commission; CFR Vol. 22 Part 225 by the Agency for International Development (USAID); CFR Vol. 24 Part 60 by the Ministry of Housing and Urban Development; CFR Vol. Volume 28 Part 46; Department of Defense CFR Volume 32 Part 219; Ministry of Education CFR Volume 34 Part 97; Department of Veterans Affairs, Research Directorate, Research and Development Directorate CFR Volume 38 Part 16; Environmental Protection Agency R&D By CFR Volume 40, Part 26; by the Ministry of Health and Human Services (also applicable to the Central Intelligence Agency, Department of Homeland Security, and Social Security Administration) CFR Volume 45, Part 46; National Science Foundation CFR Volume 45, Part 690; and Ministry of Transport By CFR Volume 49 Part 11. As a result, it is extensible and programmatic for general purpose data protection and law, such as to fit the jurisdiction of privacy policies of companies, industries, governments, regulators and other stakeholder groups that are completely different, such as JITI. A regulatory compliance solution is needed.

[334] In one of the preferred embodiments disclosed herein, privacy policy granularity, context, methods and system implementations for programmed enforcement may include unintended access to data that violates the privacy policy. It includes real-time anonymization and anonymization techniques and services that rectify use and can exceed the limits of other data protection efforts. On the other hand, other approaches to data protection (eg improving data security, privacy, anonymity) are generally binary. Either data protection is facilitated at the expense of data values or data values are compromised at the expense of data protection. For example, an encryption effort to improve the security of data protects the data, but it cannot be used in a protected form, and conversely, when it is decrypted in an attempt to use it, the data becomes vulnerable.

[335] In FIG. 1M, the impact of other approaches to data protection (security and privacy) on the protection of data values and the data when the invention, ie JITI or any other invention contained herein, is included. The impact on value protection (extension) is compared. Column 1 of FIG. 1M shows the effect of binary alternatives (eg, encryption). Here, when the data is in protected form, i.e. unusable, the black sphere above shows the value of the original data (unprotected form) and the dotted spheres indicate the loss of data. .. Column 2 of Figure 1M provides anonymity by removing the data from the ecosystem and because of concerns about using the data for purposes other than its original purpose ("data minimization"). Because of the use of traditional static methods of obfuscating the data, a reduction in the value of the data is shown. Column 3 of FIG. 1M shows that with JITI, a 100% data value is retained with JITI. Finally, column 4 of FIG. 1M shows the possibility of positive data fusion by using JITI.

[336] It should also be noted that JITI-based technologies do not have to be used in place of other known technologies for data protection (eg, security and privacy). In fact, JITI can also be used in connection with other technologies. The first advantage of using JITI to convert data to DDIDs is that, in the unlikely event that another method fails, without the access to the JITI key needed to convert the DDIDs to an understandable form, The exposed data has no value or meaning.

[337] FIG. 1N shows two important steps in one of the embodiments of the present invention for JITI. Step 1, the line crossing FIG. 1N, shows the removal of visible links between data elements so that the relationships between the data elements cannot be inferred or inferred. By converting data elements to DDIDs, plaintext source data is dynamically hidden. The data transformed by DDIDs still exists, but from the viewpoint of information theory, the knowledge and context necessary to understand the data are separated from the data by the JITI key. Therefore, DDIDs do not contain information about the underlying data element. Step 2, below the line across Figure 1N, allows selective disclosure of data based on policy management (e.g., purpose, location, time, other specified trigger factors) that is possible with JITI keys. Contains JITI key assignments. In selectively exposed data, the level of detail/clarity provided to each keychain, eg, original plaintext, perturbation values, summary information, etc., is also dynamically managed. In particular, there is no limit to the number of different selective publications that can be done sequentially or in parallel. There is no limit to the number of different authorized users who may have more than one publication. And, there is no limit to the number of restrictions and policies (time, purpose, place, etc. (relationship, relationship, quantity), etc.) for managing disclosure.

[338] Using JITI, data protection (eg, data security, privacy, anonymity) policy granularity, context, program enforcement, probability of data leakage or data re-identification, or ranking of such situations. (Ie non-parameter method) statistical evaluation is supported. From the point of view of information theory, JITI is more efficient than other approaches to data protection, because it can still access the value of the data but not the identified information. In other words, the identified information is leak-free, i.e. there is zero leaked information, while in an aggressive way (which itself can be subject to standard information theoretical optimization) the value of the data is safe. Intentionally "leaked". This means that the value is now available to authorized users.

[339] The granularity, context, and programmed JITI structure underpin the mathematical proof that the probability of data leakage or re-identification is significantly reduced. An example of JITI's mathematical proof of validity was that DDIDs were replaced up to the level of the data elements (where this process is referred to as "Anonosizing" of data). An analysis by data scientists who concludes that respecifying is less likely than speculative. However, unlike other data that is encrypted but not "Anonosized", Anonosized data can be used in its protected form to generate a value from the data. Moreover, (a) different DDIDs can be assigned to the same data element for different times, different locations, different purposes, or other criteria, so that those without JITI keys can track protected data in tracks, Very difficult to profile, guess, guess, analyze, or understand. (b) If it expires for any reason, the same DDID can be assigned to different data elements for different times, different locations, different purposes, or other criteria (although this is not necessary). ). This allows intruders and other "villains" to see these reassigned DDIDs refer to data elements that have no meaningful relationship or correlation, or to which DDIDs were previously assigned. , It makes it very difficult to establish meaningful continuity or audit trails. See Figure 1B for criteria that trigger the assignment, application, revocation, and reuse of DDIDs and JITI keys.

[340] The granularity, context, and programmed enforcement of privacy policies by JITI says that data poses a privacy or security risk when combined with other data, even if the data is not identifiable by itself. Severely lower the "Mosaic Effect" defined by the meaning. For example, Ratanya Sweeney, a professor of government and technology at the Harvard Residences, is credited for disclosing his knowledge of only three discrete identifiers. 87% of the U.S. population (i.e., 216 million of 248 million U.S. citizens) is re-identified personally by (1) postal code, (2) gender, and (3) date of birth To be done. However, for this to be correct, you need to know that the zip code, gender, and date of birth apply to the same person. With JITI, the owner of these data elements hides them by associating each data element with a different (or dynamically changing) DDID rather than associating all three with the same static identifier. To be done. With JITI, it becomes very difficult to know if the postal code, gender, and date of birth apply to one person or to multiple people. Therefore, "Mosaic Effect" is severely lowered.

[341] Implementation of the granularity, context, and programmed data protection methods and systems disclosed herein involves the development of mathematical, statistical, and mathematical models that reduce insurance risk. The granularity, context, and programmed data protection disclosed herein allows mathematical measurements of suitability as needed to develop algorithms that better value prices and protect against risk. Aggregating larger amounts of data in a broader, population-relevant manner that increases the accuracy and value of risk-related data by ensuring the security, privacy and anonymity of data at the individual consumer level. Will be more possible.

[342] In another embodiment of the granularity, contextual, programmed data protection method and system disclosed herein, prior to converting the DDIDs to obtain consent from multiple parties. , Is to require the use of multiple JITI keys. Requiring multiple JITI keys to retrieve data values from DDIDs (i.e., an "m-n" model where all key fragments or a certain percentage of key fragments are needed), each with its own stake By requiring that the JITI key held by a party be used as a trigger to simultaneously transform DDIDs into an understandable form, by multiple stakeholders, or in situations of access and disclosure of sensitive data, It ensures that the interests of various stakeholders are respected.

[343] In another embodiment of the method and system of programmed data protection according to granularity, context, disclosed herein is a high granularity (a ratio of JITI key triggers to data elements is as low as 1:1). (However, it should not be construed as limited to many-to-one, one-to-many, many-to-many mapping of JITI key triggers and data elements, although such embodiments are also envisaged) Encapsulate any, some, or all of the parameters of degree, context, specificity, abstraction, language, and correctness with which access rules and DDIDs are approved and transformed. In this embodiment, one of the access rules is to force the program to ensure that DDIDs are unwound and the original content is revealed only when all explicit access rules are observed and enforced. It is encoded in the above JITI key. JITI provides support for multiple or cascading policies implemented in assigned JITI keys by allowing "overriding" so that only the strictest policy is enforced when multiple policies are applied. provide. Or, alternatively, the aggregation of the most stringent policies is combined statically or dynamically, or in bulk, near-time, real-time scenarios to create a new "maximum" stringent policy.

[344] Figure 1P-1 shows which metadata captured in a financial transaction and populated by a virtual consumer "Scott" (shown in four different purchase transactions by the static anonymous identifier 7abc1a23). Is used to re-identify him. Using JITI, each occurrence of the static anonymous identifier 7abc1a23, shown as “Scott” in FIG. 1P-1, is replaced with a DDID after first being assigned 7abc1a23.

[345] On the other hand, in Figure 1P-2, DDID 7abc1a23 appears only once, and in the other three transaction records where 7abc1a23 previously appeared, DDIDs instead appear as 54&#3216, DeTym321, and HHyargLM. By changing the DDIDs that specify Scott using JITI, Scott is made anonymous for each transaction. In other words, JITI is added to each transaction. As a result, correlating these dynamic anonymous identifiers does not re-identify Scott.

[346] Different JITI keys can "solve" different perspectives or potential values of the same DDID. This provides granularity at the level of detail or ambiguity seen by each user, depending on the context of the user's authorized use of the data (for example, the authorized purpose, location, time, or use of other attributes). To be done. For the purposes of this application, "solving" means decoding, translating, publishing, permanently or transiently visualizing, or providing a unique "slice" of a subset of a larger set of data. To do. Here, such a slice may include no data elements, a single data element, or a combination of any number of data elements. Converting DDIDs to understandable form by JITI key is used for certain JITI key trigger factors (e.g., purpose, location, time, or other specified, used alone or in combination with other trigger factors. Due to the existence of (trigger factors), the DDIDs, including those obscured, are converted in different ways to suit different users, different times, different locations, use of other attributes, all that meet JITI key trigger factors. Is triggered, as is done. As mentioned above, Figure 1B shows various example events that trigger the assignment, application, revocation, and replay of DDIDs for data elements (e.g., data attributes or combinations of data attributes) or JITI keys. ing.

[347] Another example of an embodiment of the invention relates to medical services. In the example of this embodiment, the plaintext value of 55 heartbeats per minute (BPM) is replaced by a DDID with a value of "ABCD". For the purpose of simplifying the description, the examples of DDIDs given in this application are often represented in columns with a small number of characters, but in actual embodiments, DDIDs may be of any finite length. Good. The DDID used in this example, ABCD, the original value that has not changed is "55BPM", the keychain has the following application ("Apply" is the one where the access to the JITI key is shown below, It is programmed to be translated only by JITI keys that meet all the requirements (which means to be based on some or all attributes).
1.) Purpose-based: In this example, either:
a. Authorization of the keychain identity (eg, via password, authorization of multiple factors, or other authorization process): and/or
b. Allowed by an individual keychain's authorization to view data authorized by the JITI key (eg, comparing the authorized identity of the keychain with the identity of the medical personnel designated to care for the patient), or the JITI key Non-indirect authorization of the keychain by inheritance of attributes that allow access to source data (eg, individuals, sets, sets, groups, classes, other configurations)
2.) Physical location based: In this example, either:
a.) Provision of medical care or physical location associated with the patient (eg within a certain distance from the patient's room or from a medical station on the same floor as the patient's room): and/or
b.) Authorized, certified physical location associated with the person (e.g. within a certain distance from a cell phone, a sensor intended to be worn by an authorized and authorized nurse).
3.) Time-based: Verification of the time allowed (eg the current time compared to the time the keychain is supposed to take care of the patient).

[348] In FIG. 1Q, the medical service embodiment described above is illustrated. For example, within the provider's shift, within a certain distance from the patient's room or from the associated medical station, the first JITI key used by an approved medical provider is the original value of the DDID, "ABCD". Is configured to solve and the provider displays "55 BPM". Within the provider's shift, but beyond a certain distance from the patient's room or from the associated medical station, the second JITI key used by the approved healthcare provider is the original value of the DDID, "ABCD Configured to solve a perturbed (eg, modified) version of "," and is displayed to the provider as "50-60 BPM." A third JITI key used by an approved healthcare provider, outside the provider's shift, beyond a certain distance from the patient's room or from the associated medical station, is the original value of the DDID, "ABCD". Is configured to solve the descriptive statement of "," and the provider displays a "normal heartbeat" description, but has no time information about the patient's heartbeat. In the fourth scenario, an authorized healthcare provider (following a successful authentication action) has a fourth JITI key that is not authorized to publish information about the patient's heart rate data, The provider cannot see any information other than the DDID itself. Similarly, if a JITI key is not presented, or is not authorized or authenticated, and tries to use the JITI key, that person cannot see any information other than the DDID itself.

[349] Figure 1R illustrates an embodiment of an architecture that supports the JITI example medical services embodiment above. In this embodiment, what is referred to below as the "Anonos JITI Policy Engine", an "authorization module" is used to verify the user's authorization to retrieve DDIDs. However, the order and application of the various JITI key scenarios will dictate how much source value is exposed and returned to the healthcare provider. Users using the "Contact Interface" are involved with the Policy Engine and are able to find data in the "Anonos Platform" (eg DDIDs, JITI keys, roles and policies that determine when DDIDs are converted, and DDIDs You are accessing DVALs (which provides another level of abstraction) and data in the "information platform" (eg, the original data that was replaced at the data element level along with DDIDs). This embodiment shows that even if the actual user is trusted and properly authorized, owning the DDID himself may not be sufficient to solve the original data element. .. All actions on stored data must work in concert with both DDIDs and an acceptable set of one or more valid JITI keys. In all other cases, the "End Session" step will be "Failed End" (that is, deny access, stop, shut down, terminate app, etc., as appropriate for the particular scenario) and the system is valued. No data is returned.

[350] The following description does not include all possible matters, nor is it intended to define a minimum or maximum range. For example, in the following description, a conventional tabular database structure is used, but it is merely an example of implementation and one embodiment. JITI may be implemented using NoSQL or by any other method, and the method includes, without particular limitation, evolving technologies such as quantum databases, quantum relational databases, graph databases, and triple databases. Stores, including S3DB (relational/how to represent data in the Semantic Web without the rigidity of XML Schema).

[351] Further, such techniques or databases may be used to support the implementation of JITI or other aspects of the invention, similar patents or patent applications described herein, privacy, It may be used to support and enforce clients and privacy servers, and may be aggregated in the creation, implementation and deployment of those privacy clients and servers. Either or both the privacy client and the privacy server are aggregated, managed, and occupied by client-side applications, and in some embodiments, such applications are (i) connected to the Internet. Not running on a silo computer; (ii) mobile devices directly or indirectly connected to the Internet, including devices on the Internet of Things; (iii) any standard Internet browser (e.g. Chrome) , Internet Explorer, Microsoft Edge, Firefox, Opera, Safari, native android browsers, etc.) and/or directly through those applications; and/or (iv) generally related to the Semantic Web Or use components or services that are part of it. Similarly, the various query and record creation/modification events described below in no way limit the embodiments of relational database management system (RDBMS) type designs. Such languages are only used to simplify the characterization of the type of action taken.

[352] Embodiments of the invention described herein using DDIDs and JITI keys include at least a privacy client (and at a maximum, an equal number of both privacy clients and privacy servers, One or more each, and many examples of such clients and servers, may be client-side (eg, part of an application running in a browser, any type of virtual, physical or A logical computing device, where the privacy client is running, and the devices and applications running there are resident directly or indirectly on such browsers). One such implementation using DDIDs and JITI keys is the Semantic Web as a unified computing environment (established by the World Wide Web Consortium (W3C), such as the Resource Description Framework or RDF). It is a harness function of Web expansion according to the standard).

[353] Figure 1S shows a JITI-enabled embodiment of a JITI-enabled system that natively uses W3C standard data management resources, such as NoSQL IndexedDB, that supports an open house platform (OH). Indicates. Here, either or both the privacy client and the privacy server are resident on or logically behind the OH platform. Here, in contrast to Example A of FIG. 1S, in Example B of FIG. 1S, all data and operations including, but not limited to, privacy client and privacy server functions are performed by the data provider or domain consumer. Done, a dedicated computing infrastructure is not needed to support the JITI enabled or other operations. By implementing OH as a JITI-enabled arrangement via the Semantic Web, OH simultaneously maximizes free data values and data protection (both security and privacy) from server-side resource constraints. , Manage and integrate digital assets related to health. Preferably, from a resource perspective, neither the privacy client nor the privacy server consumes resources, thereby enabling and enabling better extensibility.

[354] Unlike conventional DBs, raw data is not recorded in the main DB of the system enabled by JITI (that is, only DDID data is recorded). Instead, there are two databases. A "main DB" (with DDID data) and a "JITI DB" that contains the key to decrypt the main DB for each cell. Each new value in the "Main DB" is, in this example, 8 characters long, and each character is assigned a unique DDID value, which is either az, AZ, or 0-9. To be (Such syntax and structure constraints are arbitrary, so as to comply with the original syntax requirements of the source data field type, inserting random values that are less likely to be , Can be reconfigured to meet your specific use or policy goals, including DDID syntax definitions.) In total, there are 62 possible values for one character (26 lower case letters + 26 upper case letters + 10 upper case letters). Numbers). Therefore, there are 62×8 (about 2.1834×10 ¹⁴ ) possible values (this range is significantly increased by adding more letters to obtain higher entropy). This can easily be converted to BASE64 (or other code) in the future. This choice is only for aesthetics in this example embodiment.

[355] In one embodiment, the values inherent in all DDIDs in the main DB are assigned to a new, unique 8-character DDID. For convenience, the value inherent in the DDID is called "DVAL" in order to distinguish the value inherent in the DDID from the DDID itself. For simplicity, the random 8-character DVAL is sufficiently unique when uniqueness is verified. Random generation may not be sufficient for very large data sets (trillions of records) for future use. If the original raw table order is known (e.g. during a database import) then the sequence value (aaaaaaaa or aaaaaaab) is used because the sequence unique ID is used to launch an inference attack. Not done.

[356] In an embodiment, each raw value is encrypted using AES, which produces unique ciphertexts for the same plaintext due to different initialization vectors. For example, in Table 4 below, a set of "original" values is given as an example.

[357] The DVAL of the values shown in Table 4 may result (due to random generation) in the values shown in Table 5 below.

[358] To reassociate each of the DVALs with the original value, each of the DVALs is as shown in Table 6 below (AES encrypted, using the secret key "demo purpose only"). , Along with the encrypted ciphertext and initialization vector (IV), are listed in the DVAL table.

[359] In another embodiment, a one-way hash function is used to generate a DDID that hides each of the raw values. In yet another embodiment, the DDID is associated with either the DDID, its underlying value, or any other relevant data (e.g., a 15-minute world ZIP coded 8 character random listing). It is generated using various stochastic statistical processes that are also uncorrelated.

Returning to the [360]AES example, the initialization vector (IV) is passed with the ciphertext because the secret key keeps the data secret. One of the advantages of IV is that the same plaintext value can have different ciphertexts. For example, if there are 10 records for the same last name or zip code, the plaintext values are the same for those 10 names or 10 zip codes, but DVAL and ciphertext, IV are all unique. is there.

[361] To query the Anonosized database, the user needs permission with the JITI key. They are intended to be broadly applied to policy management specific to their intended purpose, location, time of use, and other relevant attributes. Furthermore, the JITI key enforces revocation-based constraints, resulting in three means in one of the preferred embodiments. Query constraints, display constraints, time constraints JITI keys are stored in the JITI key DB and provide granular access control. The key also determines how the raw data is displayed (eg, the form of the DDID, converted according to one of the conversion rules, or raw).

[362] How to "Anonosizing" data

[363] As stated above, the terms "anonymize" or "anonymize" are to bring data down to the level of data elements and replace it with DDIDs. More specifically, anonymization, as used herein, is specified under controlled conditions that support the specific use of the data, such as approved by the subject of the data or an authorized third party. Within the context, it refers to the coding and decoding of data.

[364] Implementation of anonymized data allows the data management system to accept the original value (eg, economic, confidential, etc.) and untouched, but eg, by the data subject or an authorized third party. The ability to regenerate the data can be maintained with the utility, allowing the specified level of information to be revealed. In some embodiments, data is published only to the extent necessary to support the use of each designated data. By anonymizing data management, for example through the use of "identifying" and "associating" data elements within a collection or group of individuals, data usage is limited to specific data subjects or authorized third parties. Limited to the uses permitted by. With new approved data usage, all original data values and utilities are retained to support new data usage to the extent approved by the data subject or an approved third party. It However, use that identifies inappropriate or unauthorized information can be prevented.

[365][366]DDIDs By dynamically varying data to Anonosizing, the Mosaic Effect minimizes the ability to re-identify individuals from seemingly non-specific data. A study by Hartan University professor Rattanya Sweeney was cited above as evidence that up to 87% of Americans can be identified by their date of birth, gender, and postal code. However, in order to achieve the re-identification rate of 87%, in order to combine the date of birth with the gender and zip code, it is necessary to know these three pieces of information so that the same person can be reached. As an example of the dynamism obtained using DDIDs, by associating different DDIDs with date of birth, gender, and zip code, respectively, a date of birth, a gender, and a zip code may be related to the same person or different people. I don't know if it's a combination. Due to this lack of knowledge, it cannot be re-specified through the so-called "Mosaic Effect".

[367] Accordingly, anonymization embodiments include the following. 1.) Provide a method to specify a data field containing the first or second "quasi-specific" data element and replace it with R-DDID or A-DDID. Here, these data elements expose information about a person, but not the true identity of the person. 2.) to replace the first or second "quasi-specific" data element with an R-DDID or A-DDID, or, for example, the length of the field or the type of character (eg alphabetic, numeric, alphanumeric, etc.) ), and dynamism requirements that change the R-DDID and A-DDID (e.g., triggers that cause a change, frequency of change, etc.), to identify the format requirements for the R-DDID and A-DDID, Provides a way to establish a non-reference policy.

[368] Data Anonosizing Policy Management and Access Control

[369] Some privacy policies (eg, implementing fuzzy logic, non-deterministic, or similar techniques) indicate which recipients of the data are allowed and disallowed to view the true underlying data. Is deliberately ambiguous, the statement here is to make a distinct "clear line" between what is allowed to see some data and what is not. It is a specific policy that can be enforced. (For example, the original heart rate value of 65 per minute is converted to hidden NADEVs through the use of A-DDIDs.) Specifically, hidden or not hidden by A-DDIDs NADEVs include, but are not limited to: (i) synthetic data, i.e. data applied to a situation, not obtained by direct measurement, but persistently stored and used to carry out a business process (also defined below). (Ii) Derived data, that is, data that is based on a logical extension or modification of the original data; (iii) Generalized data, that is, inferred or selective from the original data, such as classes or groups. A generalized version of the data obtained by extraction; (iv) Aggregation, that is, obtained by applying one or more algorithms to multiple data elements within the same record or from multiple records. In one example, the first NADEV contains the range 61 to 70 per minute and the second NADEV contains simply the textual description "normal". (Each of them is either suppressed or published separately.) In addition, the people or groups (and their purposes) authorized to make or use such views are also individually specified. Also, in addition to location parameters, such policies govern where and where the creation or use of such data is authorized, for example, via location name, GPS coordinates, or other specified method, Time parameters are set to control when they are approved for creation and use.

[370] One particular form of generalized data occurs for unstructured data. According to Wikipedia, "unstructured data (or unstructured information) refers to information that does not have a pre-defined data model or is not organized as pre-defined. Is typically a lot of sentences, but also includes dates, numbers, facts, etc. This means irregularities and anomalies stored in the database field format or annotated in the document (semantic Compared to tagged data, it leads to ambiguities that are difficult to understand using traditional programs.” Unstructured data also includes multimedia data such as photos, audio, and video. What is important is that data is anonymized whether the data is structured data, unstructured data, or a combination thereof.

[371] In 2016, IBM said, “Today, 80 percent of data is undeveloped and unstructured data on the web like images, social media, news, email, journals, blogs, images, voice and video. Also called “dark data,” unstructured data contains key insights that are needed to make faster, more informed decisions, so what about the remaining 20 percent? It's the traditional structured data in the data warehouse, which is also important. It can't be done without structure." IBM's chairman, president and CEO Ginny Rometti said, "First of all, it's a phenomenon of data. Data was invisible, but now, especially 80% or more of "unstructured data" is visible. Natural language, literature, social media, video, audio, images, like books. Coming from the Internet of Things one after another. Computers process unstructured data, Memorable, stored, and moveable, but old programmable computers can't understand unstructured data.Dark data can be obtained through various computer network operations, but not how to derive insights or make decisions. Data is also not available.The ability of a company to collect data has exceeded its ability to parse it. In some cases, the company is also aware that the data is being collected. IBM says that about 90 percent of the data produced by sensors and from analog-to-digital conversions is never used.Technically, dark data is collected by sensors and telematics. The first use and definition of this term was made by Gartner, a consulting firm that retains dark data for many reasons, but most analyze only 1% of them. Often retained for regulatory compliance and record-keeping purposes, some companies may have dark data in the future if they have better analytical methods and business intelligence techniques to process the information. It is believed to be useful because data storage is cheap and easy to store, but storing and storing data usually entails greater outlay (and risk) than the potential return. Along with.” Anonosization can also be applied to such "dark data".

[372] Research firm IDC and data storage leader EMC (now owned by DELL Computers) predict that data will grow 50 times from the beginning of 2010, and will grow to 40 zettabytes by 2020. ing. The computer world says unstructured information will make up 70% to 80% of all company data. Therefore, in order to make unstructured information practically useful by any company, even if it is not definite, by means of protecting the data privacy while increasing the value of the data, unstructured information can be practically used. You will have to process the information.

[373] For example, without limitation, consider electronic medical records (EMRs). EMRs include not only specific data such as red blood cell count, blood pressure, and ICD code, but also, but not exclusively, a "note" field of sentences. Anonosization of a field of such a note will, by default (ie automatic opt-in and change to opt-out) anonymize conversion of that field to an R-DDID. However, what is included in the field of the note may also be an important medical feature of the data subject. Data subjects may be re-identified if only a few, or even just one, of those features is published. For example, “Streptococcal sore throat” is a common condition that is unlikely to be re-identified, but islet cell carcinoma and only a few diseases worldwide per year (or , Or orphan drug use) disclosure is so rare that when combined with itself or other data, the data subject is easily re-identified.

[374] As a solution to this, the first attempt, as already mentioned, does not expose any information in the field of the note by itself, but under controlled conditions, for example, an approved JITI key is used. Then the note field is simply anonymized by replacing it with the R-DDID, which provides a means to retrieve the entire note field. Another option is through the use of A-DDIDs. By A-DDIDs, groups (e.g., patients with pancreatic islet cell cancer, patients with streptococcal pharyngitis, patients with schizophrenia, patients with irritable bowel syndrome, where irritable bowel syndrome is probably associated with intestinal flora) (Which is believed to correlate with mental status for those doing research on), among other things, manually, by the application of machine learning, by the application of artificial intelligence, by the use of quantum computers). , Identified by such A-DDIDs. Thus, A-DDID may be associated with a range (e.g. systolic blood pressure >140 and <160), while A-DDID is associated with a particular condition within the note field in the EMR. May be However, this A-DDID generation may be opt-out by default and may need to be overridden to actually be generated. Further, the values derived from any analysis of the Note field, including but not limited to Bayesian, Markov, and heuristic analysis, can also be used to define the existence of groups. The membership of the group is then validated by the A-DDID assigned to all records belonging to the group. Beyond these applications, for example, as MRI, CT, output of emission tomography, ultrasound scan, as snapshot (for X-ray) or as video (for emission tomography or ultrasound scan) Consider the multimedia form of unstructured data, as represented. The information extracted from such multimedia data is virtually unlimited and can be organized into an unlimited or nearly unlimited number of groups. Therefore, because the group and its associated data values are used independently of the Data Subject's identity, A-DDIDs are derived from information that can be extracted in a manner that is not respecified by the Data Subject, from the current information. It is used to anonymize any of the groups that come from it. In all cases so far, A-DDIDs may themselves be associated with other A-DDIDs, but not with R-DDIDs, and if so, which A-DDIDs For those who need access to the R-DDID, i.e. not authorized, or who need to use the extracted information to re-identify the relevant A-DDIDs, for example, using the JITI key Will be approved. Since R-DDIDs refer only to the Data Subject, researchers need only the medical information obtained by re-specifying A-DDIDs. Here, A-DDIDs anonymize not only structured data but also unstructured data (or structured representation of data inferred/inferred from unstructured data). As a result, the privacy of the data subject is increased or maximized, and the data value to the researcher is increased or maximized as well.

[375] According to some embodiments, privacy-enhancing techniques (PETs), eg, public, after one or more transformations have been performed on the relevant datasets to generate NADEVs or sets of NADEVs. Meet or exceed the requirements of key encryption, k-anonymity, l diversification, "noise" introduction, different privacy, homomorphic encryption, digital rights management, identity management, containment, generalization, etc. In addition, each member (or combination of members) of the resulting set of data is hidden by the use of A-DDIDs, or to the degree desired by the policy author. At the same time, the values of the data measured by one or more factors, such as the mean, congruential mean, marginal mean, variance, correlation, accuracy, precision, etc. It is kept at the maximum or optimum level (compared to the value of the input data, which is given). These techniques provide benefits over existing data hiding methods. At least because existing methods are generally; (i) policy-based only (no technical enforcement); or (ii) when technically enforced, often significantly reduce the value of the data, thereby Prevent the desired analysis, correlation, discovery or leap.

[376] As described in various embodiments disclosed herein, an application of data anonymization policies can programmatically enforce these policies on simple or complex datasets, as described above. Has brought a way to force. The nature of such enforcement is not limited, but by the use of time, purpose, location JITI key/value combinations (or other types of access control-based keys/values), further restrictions or exclusions on the data can be achieved. Consists of generating.

[377] Partial utilities for the use of such data anonymization policies allow data to be "atomically" or "cellularly", that is, a single piece of data, no matter what level it implements. Derived from the ability of the policy to transform data down to the unit level. An atomic unit of data is a data or group of data that is treated as a single entity for purposes such as parsing, associating, computing, anonymizing, etc. As discussed below with reference to FIG. 1U, for example, previous data protection methods protect or encrypt data “row by row” or generalize “column by column” in a two-dimensional dataset. However, the techniques described herein protect or encrypt data by row, column, third order, fourth order, or nth order vector, or a combination thereof. Moreover, the techniques described herein can be applied in the opposite direction. That is, it can be applied to the level of a single cell of a multivariate data set, or to the set or permutation of continuous, discontinuous, discrete cells. These "cell manipulation" features: suppression, generalization, public key encryption, k-anonymity, l diversification, "noise" introduction, different privacy, homomorphic encryption, digital rights management, identity management, Other PETs are made possible by the ability of the anonymization system to tokenize each piece of data or a new group of data.

[378] At the cell level, tokenization of data (ie, anonymization) is built into the hierarchy of NADEVs and other values and the hierarchy of references to other data or groups of data. The generated token is stored in the relation and search database together with access control and authorization information, and the token is also hidden by using A-DDIDs. Implementations of certain policies include (i) protection of data at the initial or cell level; (ii) what information should be disclosed, when or how much, and to whom. And control over what purpose it should be published; (iii) control over the "clarity" when the data is published, for example, one authorized person can Access to the value is given, while only the NADEV representation of the true value of the data is exposed to others who do not need to have access to the level of specificity of the data. Exposing controlled data involves the use of some random, probability, parametric, or non-parametric aspect, but when (i.e., at what time), where (i.e., in which physical or virtual location), and why It also includes the ability to control what (for what purpose) the publication itself takes place.

[379] FIG. 1T illustrates an example system that implements data risk exclusion policy management and access management in accordance with one embodiment of the present invention. First, table 101 represents the original plaintext representation of the source data table. As shown, the table 101 stores non-hidden values in each field of the table, eg, date of record, name, heart rate, address, city, state, country, date of birth. Table 102 represents a data table. Here, the data is transformed by substituting tokens (ie, handle names) at the data element level. For example, the heart rate (bpm) value of 55 in the second row of Table 102 is replaced with the token value “RD-4a7e8d33”, and the birth date of October 28, 1944 in the second row of Table 102 is the token Replaced with the value "RD-4f0b03c0". Table 103 represents the data disclosure in the second row of the original source data table 101. Here, the selected values in the table (eg heart rate field and date of birth field) have been reduced to the data element level, while the rest of the data remains anonymous and pseudonymized. Table 104 is a digitally-hidden, partially-hidden, grained, filtered, or transformed version of the underlying data populated in a data table by one or more policies. Is an example of NADEVs. For example, as shown in Table 104, two NADEVs are populated to correspond to a heart rate value of 55 from the second row of the original source data table 101, and three NADEVs are Date of birth values from Source Data Table 101 are populated corresponding to October 28, 1944. Finally, Table 105 shows an example of the underlying values that are hidden, partially hidden, grained, filtered, converted to NADEVs, and inserted into Table 104. As explained above, only the required levels of identified data are exposed to a recipient under one or more policies. For example, one authorized recipient receives a heart rate of "55" shards, another receives a "51 to 60" NADEV, and another receives a "low" NADEV. Similarly, one authorized recipient will receive a value of "October 28, 1944" as the date of birth, another will receive "October 1944" NADEV, and another will Receive the 1901 to 1950 NADEV. As it may have been better understood so far, NADEV reveals the true intrinsic value of large and small data, either separately or together, depending on the implementation and design of the relevant policies, but for each NADEV. Is accurate for the underlying data.

[380] FIG. 1U illustrates examples of various data risk elimination schemes consistent with embodiments of the present invention. For example, conventional means of data protection (eg, encryption) is shown in scheme 106. Scheme 106 represents a "binary" protection scheme. In other words, such a scheme represents all single data elements (ie white squares) or does not show any data elements (ie black squares). Newer methods of data protection expose or hide data in "two dimensions", as shown in Scheme 107. In other words, the publication of data is row-based or column-based. Finally, scheme 108 illustrates a multi-dimensional or “n-dimensional” protection scheme, as described herein. Here, the data is published (or hidden) at the individual data level (including cell combinations) in two, three, or n dimensions.

[381] Data Anonosizing Policy Virtual Marketplace

[382] FIG. 1V illustrates an example of the marketplace shown in Scheme 110 for various data risk exclusion policies that have become available for purchase in accordance with embodiments of the present invention. The electronic marketplaces described here make it possible to sell or consume any number of different policies, either internally or from a third party policy vendor. Policies may be non-parametric means (ie, rank order) or specific user “user ratings” as well as quantitative and qualitative criteria (eg, “correctness ratings” as shown in Table 110). , "Privacy rating"), is ranked by the parameter means of a policy, the analysis, and the performance attributes of that policy. Further, the ranking and analysis may be based on certain types of privacy or data value challenges (i.e., Table 110 Based on the application of policies to the "target area"). No marketplace provides an objective measure of the quality or relevance of a particular privacy policy, where the policy is technically enforced on the underlying data, based on contextual use and applicable laws and regulations.

[383] Applying artificial intelligence to data Anonosization

[384] As discussed above, in one embodiment of the present invention, digital rights similar to those used by companies that limit the reproduction of personally made music, movies, and other digital content. A technology such as management (DRM) is used, and by anonymizing the data to authorize the use of the data subject's personal data, the data subject or the person the data subject trusts from the company owner of the data. Is shifting authority to. This data protection scheme is referred to herein as "privacy rights management" (PRM) or "Big Privacy". Even in situations where the data subject is not directly involved, PRM technology manages risk by allowing the responsible use of the data, respecting the rights of the data subject.

[385] PRM and Big Privacy are used to replace static, seemingly anonymous identifiers with DDIDs. As mentioned earlier, these dynamic identifiers encapsulate the data and control the re-identification of the entire life cycle of the data down to the element level of the data. Therefore, even for the same data, different people have different meanings depending on technical policies. BigPrivacy's technology may split sensitive or identifying data into segments and dereference these segments. Example: DDID pointer obfuscating the relationship between segmented data element and ID

[386]PRM and BigPrivacy technologies can also impose a common data schema on data collected from different applications and platforms, enabling functional bidirectional operation between heterogeneous datasets. We can support fusion, big data analysis, machine learning, and artificial intelligence (AI). Anonosized data may also be decoded for use under certain conditions under the control of the data subject or an authorized third party ("Trusted Party").

[387] The so-called various "Intelligent Policy Compliance" systems and methods described in this document include AI algorithms that analyze the data schema, metadata, and structure of datasets. It may also include recording a sample of the dataset to determine algorithms for obfuscating, generalizing, or transforming the dataset based on preset policies using R-DDIDs or A-DDIDs. Let's

[388] In some embodiments, the Intelligent Policy Compliance system and method may classify data by analyzing the metadata of the data. For example, if it contains field names such as "Patient ID" or "Prescription ID", it is a healthcare-related dataset. Improve classification accuracy using advanced classification techniques, including algorithms such as remote data retrieval and statistical methods. The accuracy of the classification may be further improved if a sample record of the dataset is available. In some embodiments, Intelligent Policy Compliance systems and methods may be tailored to their industry (such as healthcare) or product or service (such as mobile phone call records). Neural network algorithms allow you to generate cross-disciplinary and industry models and categorize between and among industries. For example, aircraft jet engines are different from hydroelectric turbines, but both have the ability to induce a flow of liquid or gas. Therefore, it is possible to generate a conceptual model to propose rules for flow measurement.

[389] In some embodiments, the Intelligent Policy Compliance system and method may analyze actions for certain categories of data. An example is the one using R-DDIDs and A-DDIDs above. This analysis can be used to generate a set of actions that are applied to modify the dataset in a particular way. An example is the one using R-DDID or A-DDID above. For example, generalizing a person's phone number to the area code using the A-DDID to comply with a particular privacy policy completely obscures the relationship between an individual's name and the R-DDID. You might. Many of these processes are analyzed by the Intelligent Policy Compliance system and its methods to produce the right combination of processes for the dataset. The combinations may embody a single “best” combination, multiple combinations selectable by a user, or any other set of combinations.

[390] Users can modify or apply raw data to the Intelligent Policy Compliance system and the processes spawned by it through a user interface. Once a user makes such a decision, it is saved for later as part of a feedback loop, effectively using machine learning to enable the Intelligent Policy Compliance system and its methods to learn from successes and failures. ..

[391] Figure 1W-1 shows an example of an Intelligent Policy Compliance engine, according to one embodiment of the invention. As shown, the user interface allows the user to interact with the Intelligent Policy Compliance engine. This engine consists of software that performs classification and analysis services. As mentioned above, the classification service uses AI-related techniques, including machine learning, to determine which category of data is stored in the dataset of interest. Similarly, analytics services may analyze the determined categories and suggest multiple privacy policies appropriate to the type of data. The Intelligent Policy Compliance system uses machine learning or other methods to determine which data privacy and anonymization policies are most effective (or which users prefer) for a particular type of dataset. You can "learn" and save and update potential data categories and their associated policies.

[392] Figure 1W-2 shows an example flow diagram 130 for use of the Intelligent Policy Compliance engine in a working example of the invention. Beginning on the left side of the flow diagram 130, a user may provide a data set (including associated metadata) via a user interface to a data privacy system classification service. The Classification Service retrieves information about commonly used data field names and data types, and their associations with specific categories of data that you store. Utilizing this stored historical information, AI classifies the incoming dataset provided by the user by the classification service. The determined data classification may then be provided to the analytics service of the data privacy system. Similarly, analytics services may retrieve information from storage about the data anonymization process that was previously applied to similar datasets. Based on the analysis of the returned information, the analytics service makes various policy decisions and assigns various processes to the dataset to anonymize the data. The determined actions and policies can be reviewed by the user through the user interface, modified as needed, and then the anonymization policy applied to the dataset. Because the user's changes are saved to the data store, the policy is updated and the final policy is presented to the user for approval. You will always be able to use this dataset.

[393] Application of synthetic data to Anonosization and application of Anonosization to synthetic data

[394] According to Wikipedia, synthetic data is "production data that is not directly measured and can be applied under certain conditions," and Craig S, a specialist in data management in the McGraw-Hill Technical Dictionary. ． Mullins defines production data as "information that professionals constantly accumulate and utilize for their business." In other words, synthetic data is not a symbol of actual measurements of real-world data, even if it is created using various modeling, statistical analysis, Bayes method, Markov analysis, etc. .. Rather, synthetic data is a model of real-world data. The real-world data is ultimately tied to the actual data subject, and the concealed real-world data, when re-identified, has those data and the quasi-identifiers associated with the data subject. Be careful that it becomes obvious. In contrast, synthetic data, whether in plaintext or in a re-identified form, refers to that model rather than real-world data. Therefore, synthetic data may contain abstract statistical properties of real-world data, but unless the application generating the synthetic data remains connected or has continuous access, it indirectly references the synthetic data. You cannot then generate real-world data. In this case, real-world data is accessible to authorized (or potentially unauthorized) users of the application.

[395] “Privacy Policy” as mentioned above includes, but is not limited to, the use of synthetic data. This is because synthetic data is not based on the data subject (individual) that exists in the actual data, and data that is not directly related to the actual data subject protects the privacy of the data subject in principle. However, this is not always true in practice, as explained elsewhere in this book.

[396] Therefore, the following can be said about the privacy policy: (i) The privacy policy details the use of synthetic data. (Ii) The privacy policy details the anonymization of synthetic data. This is because, in principle, you can reverse engineer synthetic data to get a model of real-world data, and this model can be used to show a high degree of association with real-world data. The Mosaic Effect ensures that anonymized synthetic data is only available to authorized users. This will prevent unauthorized exploitation of this potential flaw. (Iii) In the privacy policy, the creator of the synthetic data has the right to access the real-world data for a certain period of time, but after the end of that period, the right is invalidated by the JITI deadline, location information, and a key restricted by the purpose. Clearly be done. (Iv) In order to separate not only the anonymized synthetic data but also the application that generates the synthetic data from the real world data and related data subjects after the generation ends, the above (ii) and (iii) Combine the contents of. This depends on what the purpose was and where it was generated. (V) Support what is written above about real-world and synthetic data.

[397]BigPrivacy may enforce privacy policies that specify the use of some, most, or synthetic data only.

[398] In other cases, access to synthetic data is limited by time, place, and purpose, and anonymization of some, most, or only synthetic data is BigPrivacy so that it is available only to authorized parties. May apply.

[399] In other cases, whether or not they eventually contain some, most, or all of the total data, only the time needed, the specific location, and the purpose needed to generate the synthetic data, Allows BigPrivacy to restrict access to real-world data and related data subjects.

[400] In other cases, BigPrivacy may also support some, most or all of the datasets that make up the above combinations of synthetic data.

[401]BigPrivacy's technology can be employed to facilitate compliance with regulations and contractual restrictions in ways that help maximize the use of your data, as described in this document. For example, you can extend the use of your data while ensuring its security and privacy.

[402] For example, Big Privacy helps businesses adapt to new data protection regulations. It is a new regulation for data subjects in the EU and will address cases such as the GDPR, which will be subject to significant fines and penalties for non-compliant data controllers from spring 2018. The GDPR applies to companies around the world who process data, including personal information of EU citizens, and at the present time its content includes fines of up to 4% of worldwide sales, class actions, data controllers. And responsibility for both data processing vendors and obligations of data breach notification.

[403] For GDPR, previous legal grounds for data analysis, artificial intelligence, and machine learning are void. While consent under the GDPR remains grounded, the definition of consent is strictly defined by the GDPR. "Freedom, with clear and detailed explanations, the data subject agrees that the data of the principal is to be processed" is the current definition of consent. As is often the case in the fields of data analysis, artificial intelligence, and machine learning (eg big data analysis), vague explanations or ambiguities about data processing are not consents that meet GDPR compliance. Will be considered. Strictly compliant consent under the GDPR puts the data controller and processor at risk, not the individual data subject. Prior to the enactment of the GDPR, the risks associated with not fully understanding the widespread consent were borne by individual data subjects. Under the GDPR, broad consent no longer provides a full legal basis for big data. Therefore, data controllers and processors that manage information in EU data subjects must meet a different legal basis for big data processing. Satisfying the GDPR's "legitimate interest" requirements allows companies to add new legal grounds for big data analytics. This requires two technical requirements to be met: "Pseudonymisation" and "Data protection by default". These are described in detail below.

[404] GDPR Article 4(5) defines "pseudonymization" as the need to separate the informative value of data from the means by which it is linked to individuals. The GDPR says there is a need to technically and organizationally separate the data itself and the way in which it connects people with data. Traditional approaches such as permanent identifiers and data masking do not meet this requirement, as the correlation between data elements is possible without the need to access individually protected means of connecting the data to the individual. .. The fact that data can be linked to an individual is called "correlation effect", "re-identification by linkage attack", or "Mosaic Effect". This is because anyone who has the data can be tied to a particular individual.

[405] Article 25 of the GDPR imposes a new “default data protection” obligation and states that data must be basically protected, and that if data is used, this step must be taken. is. (This is in contrast to the pre-GDPR idea that data is available, but if you do, you have to take steps to protect it.) Also, use only the data you need, regardless of time or user However, the use of unauthorized users is prohibited.

[406] BigPrivacy can support pseudonymization by separating the informative value of the data from the personality of the data, satisfying the GDPR default data protection requirements, and Publish only the data you need for a specific purpose, a specific user, and reprotect your data. BigPrivacy enforces requirements by replacing “restricted data elements” (eg “personal information” in the GDPR, “protected healthcare information” in HIPAA, contractual protection information, etc.) with pseudonymized data. Meet At first glance, the pseudonymized data matches the original data. (This replacement with pseudonymized data has been described as R-DDIDs in this document because pseudonymized tokens are used for re-identification and re-identifiers are used to replace data elements.) R-DDIDs With, the dataset is finely pseudonymized with tokens that are not required for personal identification or "linkage attacks". In addition, BigPrivacy may provide more accurate data as alternative technologies tend to be more commonly applied to PETs. Conversely, not knowing what data is used for what purpose diminishes its value.

[407] As mentioned above, BigPrivacy may involve using the R-DDID in the first place to replace common occurrences of the same data element with different pseudonym tokens. The second step should include the "cohort", "scope", "class" to which the data element belongs, without providing any means to link the data to an individual (that is, without providing an identifying element). Includes inserting NADEVs. An example of NADEV would be to replace an individual's age with a digital representation of an age range. In such an example, data subjects with an age within a certain age range are assigned the same digital representation (that is, NADEV), reflecting that they are within the "class" of age. A-DDIDs can also be used to insert alternate data models (related or derived data values) for NADEVs that occur infrequently into protected data fields. Common A-DDIDs that protect or hide NADE values are assigned to all identical data values (ie NADEVs) within the same cohort or class. This is because these NADEVs do not need to be converted for processing. In this way, cohort tokenization is performed. (I) The cohort value, the NADEV itself, is the primary identifier for the data. That is, NADEV basically functions as an A-DDID. Because no NADEV protection or obfuscation steps are needed, irrelevant and not selected. Or (ii) If additional data protection is required, the A-DDID that hides NADEV becomes the primary identifier for the data. In the current scheme, such anonymization is not possible because the personal identity serves as the primary identifier for the data.

[408] Figure 1X-1 shows a general approach for an application that provides BigPrivacy (140). In particular, incoming data can be "shim" applications (for example, a small library that transparently intercepts API calls, modifies passed arguments, handles the operation itself, or redirects the operation elsewhere. ), will be sent to the system each time it is accessed. A sim can also be used to run a program on a different software platform than the one originally developed. BigPrivacy implementations may utilize a randomized lookup table that correlates the R-DDID or A-DDID with the underlying data values mathematically, rather than randomly. The three parties cannot re-identify the underlying data without official access to the key.

[409] As shown in Figure 1X-2, browsers, devices, and sensors can be impacted over the network by enforcing de-identification and re-specification policies as data enters and leaves the system. Anonymization can also be done by using the giving system (350).

[410] Figure 1Y-1 illustrates a cloud-based platform and application that provides Big Privacy services to de-identify data (160). Users, automated processes, Internet-connected devices, or other entities (users) can send "raw" data (data that exists prior to de-identification) to the BigPrivacy cloud platform processor along with metadata that specify the properties of the data. I will. (step 1). Data can be specified as individual data elements, records, entire datasets, or any combination thereof. The system can analyze the provided metadata and, through another interface, look up the anonymization policy to determine how to process that data (step 2). Policies under the anonymization policy interface can be stored in the Intelligent Policy Compliance engine in a relational database as files on the server's file system or by other means (step 3). When deciding which policies apply to user-supplied data, the system may de-identify that data on a per-policy basis. When a user configures the system to store unidentified data in a data store, message bus, Map Reduce system, or other endpoint, the system can send unidentified data to its destination (step 4 ). Non-exclusive from previous options for unidentified data storage, configure the system so that the user maintains a mapping between unidentified values (R-DDIDs) and NADEVs as "raw" data elements. If identified by de-identifying A-DDIDs, or related A-DDIDs, the system can establish a persistent mapping in data storage for future use (step 5). The user can retrieve the identifier for future reference to the de-identified dataset or R-DDIDs and/or NADEVs, A-DDIDs and/or mappings (step 6).

[411] The constitutive mapping described in step 5 of Figure 1Y-1 above is for the possibility of restoring R-DDIDs, NADEVs, A-DDIDs of de-identified, system-generated datasets. It may be used in the future to generate some respecification keys (eg JITI keys) manually or by some method such as an automatic key generation service.

[412] Figure 1Y-2 illustrates a cloud-based platform and application that provides Big Privacy so that data de-identified by the Big Privacy de-identification phase described above with reference to Figure 1Y-1, for example, can be re-identified. (170). Users, automated processes, internet-connected devices, or other entities (users) can request re-identification of elements of data. The user may provide information about the re-identifying data by referencing the unique identifier returned to the user during the de-identification phase, by explicitly specifying the re-identifying data, or by other means. Become. The user may also specify the JITI key containing the mapping between the specified de-identified data and its re-identified one, such as by specifying a unique identifier returned to the user during the de-identification phase, etc. Provide the data (step 1). The system uses the JITI Key Management Service (step 2) to authenticate the user and authorize the user's request before processing it so that only the appropriate users can access the re-identified data ( Step 3). As previously described in Figure 1Y-1, the system can also establish a persistent mapping in data storage for future use (step 4). The system then accesses the user-specified non-identifying data and the JITI key, reverses the non-identifying mapping for each data contained in the JITI key, and finally the requested re-identifying data to the user or configured authorization. It may be sent back to the destination already sent (step 5).

[413] Multiple users can re-identify different sets of R-DDIDs and A-DDIDs based on their access rights to the underlying data elements. Through the ID (that is, if the user has the JITI key, the user can see all the data in it), access requests to authentication and authorization services (such as LDAP), location information, temporary parameters, etc. Permission validation is done through or through any combination of these and other methods. In this way, different people, services, and other users can view different "views" of the underlying raw data, based on their access permissions to that data.

[414]BigPrivacy may generate NADEVs during the de-identification stage (may also be obscured by A-DDIDs). This necessitates the re-identification (“cohort tokenization”) of a dataset of synthetic data before the re-identified data is used in analytics or other applications. This represents an improvement in factors such as speed of re-identification, server power usage, multi-tenancy capabilities, etc. for systems that need to perform such operations during the re-identification phase.

[415] Figure 1Y-3 shows a Big Privacy application that integrates with Extract, Transform, and Loading (ETL) applications (180). ETL applications allow users to adjust, transform, etc. data and perform de-identification tasks with BigPrivacy plugins (“add-ons”, modular features that can be added or removed by software). (step 1). The ETL application allows users to store non-identifying and master re-identifying data on local computers, corporate data centers, BigPrivacy platforms and other authorized locations (step 2). The connection between your ETL application and the Big Privacy platform can be achieved with industry standard security by using protocols and services such as Transport Layer Security (TLS), Virtual Private Network (VPN), and other methods. The system imports the non-identifying data and re-identifying key data specified by the user and saves the data (step 3). In the future, another user with access to a re-identified version of unidentified data may interact with BigPrivacy and request re-identification of a data element that was originally de-identified by the ETL application (step 4 ).

[416] As explained above, anonymizing the data avoids the risk of data loss and litigation. Examples: (i) Article 33, 34 of the GDPR in the EU; (ii) In the United States (a) HIPAA Leakage Notification Rule 45 CFR §§ 164.400-414 Federal law (b) 47 State law; Below, the District of Columbia, Guam, Puerto Rico and the Virgin Islands require that individuals or government agencies notify individuals of security breaches of information, including personally identifiable information; (iii) Other laws as well. The notification duty of is imposed. In other words, if anonymized data is compromised, the data controller does not have to notify the data subject of the violation. This is because the data remains protected from the perspective of re-identification. It can also make it more difficult to access the master table with a stolen key, leveraging the established capabilities of the key management system. “Heartbeat” certificates, multi-key requests, GPS requests, etc. may be used to manage keys for a particular system. In addition, the level of information value provided by such a combination of controls may be individually limited.

[417] All types of BigPrivacy provide full performance analysis and processing using their NADEVs without the need for data transformations, non-identification/re-identification policy engines, API calls or references to "sims". Assists NADEVs with enabling anonymization. Specifically, A-DDIDs can be processed directly and a "call" is issued to get the NADEV only if the desired result is achieved at that anonymized abstraction level. In such cases, NADEV can only be retrieved for a small number of users (for example, 50 users from the data table) whose A-DDID represents the cohort or class associated with the query. On the other hand, the majority of users whose A-DDID does not match the cohort or class associated with the query (the remaining 500,000 users in the data table) do not need to get their own data. Notwithstanding the above, Big Privacy does not require NADEV to be concealed by an A-DDID. Because BigPrivacy only provides that method and device, NADEV effectively acts as A-DDID when NADEV is not hidden by A-DDID.

[418]BigPrivacy can also support different levels of abstraction. In addition to supporting primary and secondary levels or tables, higher levels or tables, including NADEVs, are not "true" values for persons, companies or attributes revealed by referencing the primary table. It can represent R-DDIDs or A-DDIDs that associate data with fictitious people, companies or attributes. This prevents revealing the identity of the "true" person, company or attribute with which NADEVs, R-DDIDs or A-DDIDs are associated, but NADEVs, R-DDIDs or A-DDIDs are common. We will know if it is related to an (unidentified) individual, company or attribute. Because different types of data controllers may require different levels of identifying data, different types of data controllers will not be exposed to higher levels of personal information only when necessary to meet specific authorization requirements. Can provide access to different tables, levels and JITI keys.

[419]BigPrivacy can be used to implement the data subject's "right to be forgotten" in the processing of data (when required by Article 17 of the GDPR). For example, you can "delete" the keys needed to associate your anonymization policy engine with your personal information, so that your personal data can be erased without having to delete the data itself. Rather, only the link between the data and the true personal information of the data subject needs to be removed from the lookup table or database.

[420] Applications of anonymization to quantum computers, quantum computing, quantum cryptography, quantum privacy

[421] We distinguish between old computers (CC) and quantum computers (QC) as follows. The information is a binary number (or bit, 0 or 1). QC as used here refers to a quantum machine where the smallest piece of information that can be represented is a qubit (or qubit). Qubits can be 0 or 1 (or both). A qubit is usually an atom or a photon, but in principle it is a small enough particle, that is, a particle to which the quantum mechanical principle is applied. This quantum mechanical property is called superposition. In addition, QC qubits are entangled. So if one qubit changes, the other qubits will be affected as well. (By contrast, in CC, the bits are independent, and changing one does not necessarily change the other.)

[422] Due to these features (superposition and entanglement), QC can perform a large amount of operations in parallel (CC does serial computations, not only does it increase the number of bytes for parallel computations) More processor required). For example, CC solves a problem that takes as many astronomical numbers as a problem, and QC can solve problems that are virtually unsolvable in seconds.

[423] Current cryptosystems include public key cryptography and elliptic curve cryptography, among others, but the first cryptography was the prime factor (p1 * p2) of a very large composite number (ie p1 * p2). And p2) can only be deciphered. Public-key cryptography with a large number of bits cannot be broken even by the fastest computers on earth (eg 512, 1024, 2048-bit encryption). On the other hand, QC does all possible calculations and decrypts (breAK) in a matter of seconds.

[424] De-identification outside BigPrivacy often involves so-called one-way hash functions. This is because, in principle, the initial value cannot be determined "backward," from the hash to the re-identified original string. Again, QC can quickly determine the original string from a one-way hash, but CC has to perform a brute force attack (unless the underlying hash algorithm is exploited) to decode the hash. There is. This will take many years to complete. In general, the same flaw exists with other forms of anonymization, including other privacy-enhancing technologies (PETs) described elsewhere in this document.

[425] Encoding the original information in some way is a fundamental problem with all encryption methods. Theoretically, at least in QC, the data subject and all of its quasi-identifiers are recoverable to some degree deeper, or re-identifiable from their encoded form, in ways that QC cannot easily decipher. BigPrivacy does not require implementations to prevent encoding, and BigPrivacy does not rely on encoding, but regardless of whether it produces R-DDIDs or A-DDIDs, the behavior of irrelevant strings of the original data. Subject to static replacement. Even though the string is basically random and suitable for QC ideals, there is no way to re-identify any type of DDID for properties where other methods exist. The DDID is an arbitrary string, not the encoding of the original data. Moreover, the same data is represented by different DDIDs, so there is no relationship between DDIDs. In other words, DDIDs are maximally entropy and, from an information theoretical point of view, do not contain useful information about the data subject or the original data. Therefore, QC cannot determine the original content based on DDIDs that do not contain any information about that content. For this reason, DDIDs, among other things, provide technologies that protect the privacy of individuals and prevent re-identification of anonymized data, even in the world of quantum computing.

[426] Therefore, BigPrivacy addresses not only the goal of maximizing privacy, but also of maximizing the value of your data. In contrast, other PETs improve privacy at the expense of reducing the value of the data. Or, conversely, you cannot protect your privacy as a result of increasing or maximizing the value of your data. So even if the QC protects your privacy, the value of your data will be compromised. This is because parallel computing is possible and fast, but it does not add value or validate the data. Instead, even if QC has become the standard for all computing, Big Privacy alone (in combination with QC) can maximize data privacy and data value.

[427]BigPrivacy can also be applied to encrypted forms, including QC encrypted forms. In other words, Big Privacy is computationally independent of the fundamental nature of computers. This is to break the link between the original data (whether encrypted or not) and the data anonymized by Big Privacy.

[428]BigPrivacy can also take advantage of basic quantum mechanical properties. For example, QC lends itself to generating truly random numbers. However, if you use a true random number as input to a computable function, there is a correlation between the original data and the randomization of that data, making the anonymization meaningless. However, with BigPrivacy, as mentioned above, a true random number is used only as a DDID. Random numbers are independent and have no correlation (or relationship) with the underlying data. In this way, BigPrivacy actually leverages the properties of QC, and in some cases there is no (or almost no) correlation between the DDID (either R-DDID or A-DDID) and the underlying data. Can be confirmed).

[429] Implementation of centralized Big Privacy control in distributed systems

[430] The BigPrivacy Technology described above is a distributed network or platform (including systems that do not require authorization or Allows for centralized privacy and security controls to be established, enforced, validated, and modified by and over controllers (including non-centralized technologies).

[431] In one case of the invention, it applies to distributed networks built on blockchain-based technology. Blockchain is the underlying technology behind many of today's popular cryptocurrency platforms. Blockchain is best known for its enablement of cryptocurrencies and cryptocurrency transactions, but also for medical data storage, supply chain management, financial transaction management and verification, so-called "smart contracts" and enabling and implementing SNS. There are a wide range of applications such as.

[432] There is no single definition for the term "blockchain", but it generally means one of two things: (I) A P2P network of distributed computers with a distributed ledger that is digitized to record a particular method or process. (Ii) describes the underlying data structure (or block) used to represent the transaction itself, that is, a chain of blocks of data, where each block is linked (or "chained") to a previous block. Specific algorithm/programming method. As used in this document, blockchain can have either meaning or both meanings contextually. When the term "blockchain" is used, its meaning is explained in detail. Regardless of which client or node participating in the Blockchain network started the transaction, it is recorded in the network in the form of "blocks" of data, time stamped and linked to the previous block in the blockchain. Linking each block to the previous block ensures the integrity of the chain of transactions. That is, it goes back to the first block in the blockchain. The inability to link each block to the previous block may indicate tampering (changes of any kind of data stored in the block in the blockchain), fraud, etc., and its integrity cannot be verified. I mean. The information in the block is encrypted and protected by an encryption method.

[433]Blockchain is stored throughout the distributed network. That is, there is no centralized "official copy" of the data stored in the block. Instead, there may be multiple identical copies of the blockchain. All instantiations of a blockchain at a particular node in the network are identical (if the node does not have the latest version of the blockchain, this Is considered to have left). The decentralized nature of this storage is an essential aspect of the blockchain itself. The process of adding transactions to the blockchain is done by mining "nodes". Mining is essentially an algorithmic process that can be used (in the case of cryptocurrencies) to generate a particular virtual currency. You can also verify transactions within the blockchain.

[434] As mentioned above, the EU GDPR refers to a data "manager" (ie, an individual or legal entity, public institution, agency or other entity that determines the purpose and means of processing personal data, alone or in combination with others). We have certain obligations to the data “processor” (that is, an individual or legal entity, public agency, institution, or other body that processes personal data on behalf of the controller) and the data “processor”. In addition to introducing penalties to data processors, the GDPR imposes stricter obligations on data privacy controllers and significantly increases the potential penalties for breaches.

[435] Article 17 of the GDPR states that "the right to be erased/forgotten", that is, the right to delete or request deletion of personal data when there is no justifiable reason for continued data management. It codifies the rights to provide to the subject.

[436] An important feature of blockchain is its integrity (that is, that the users of the network can trust the accuracy of the data stored in the blocks of the chain) and is guaranteed by its immutability. Once a block has been validated and added to the chain, it is usually not deleted, edited, or updated. In fact, blockchain is designed so that modifying the data stored in any one block "corrupts" (invalidates) all the downstream blocks in the chain. In most cases, blockchain data is protected by encryption or static tokenization, but you have been asked to remove the data from the blockchain in accordance with the GDPR (or other similar regulation that provides such rights) and "erasure". You may want to exercise your right to do/forget. On public blockchain platforms, such requests cannot be fulfilled without breaking the integrity of the entire chain.

[437] The UK Financial Conduct Authority (FCA) warns companies developing blockchain technology to be aware of immutability and GDPR incompatibility. Several solutions to this problem have been suggested, including allowing the administrator to edit the blockchain as needed. However, as mentioned above, editing the blockchain breaks the concept of blockchain. This is because the blockchain becomes mutable and the guarantor regarding the integrity of the blockchain is deleted.

[438] The GDPR was designed assuming that the data custodian is the traditional centralized player. GDPR did not consider decentralized systems such as blockchain. The Big Privacy technology described here adds significant functionality to the underlying blockchain technology for several reasons. For example, BigPrivacy allows the blockchain to remain immutable with the data while at the same time allowing the data to comply with the GDPR's Right to Erase/Forget Right criteria. The Big Privacy techniques described here (for example, using DDIDs) can also be applied to newer forms of distributed storage systems (the novelty, for example, is that GDPR itself uses immutable distributed ledgers to store user data. Proof that it will affect the implementation of that requirement). BigPrivacy further enables the use of blockchain to fulfill other obligations of data controllers and processors under the GDPR. This is explained in more detail below.

[439] Right to Erase/Right to Forget

[440] In FIG. 1Z-1, a case of an exemplary distributed network built on a blockchain-based technique in which anonymized privacy control may be employed is shown. The top part (185) of Figure 1Z-1 shows a situation where the data subject's name is replaced with an encryption (using the desired encryption algorithm, for example) or a static token before being stored in the blockchain. .. In this example, the acronym "ABCD" is used as an exemplary representation of the result of such an encryption or tokenization process. By accessing the appropriate key, we can determine that the encrypted/tokenized value of "ABCD" was "John Smith". This is immutable and is inconsistent with the GDPR requirement that users be given the "Right to Erase/Forget" mentioned above. This is because "John Smith" is included in the blockchain 185 itself even though it is stored in encrypted form.

[441] In the lower part of Figure 1Z-1 (187), the dynamic non-identifier (DDID), which is "DDID652" in this example, is used in the blockchain, "instead of the ABCD encrypted/tokenized value." It shows that you can do it. As described in this document, a DDID (“DDID652”) is a data subject unless the data subject exercises its “right to be erased/forgotten” and the DDID now points to a “null” entry. Serves as a "pointer" to the underlying name "John Smith". In this way, you can provide the flexibility to allow data subjects to exercise their "rights to erase/forget" while maintaining the immutable nature and referential integrity of blockchain. It's also important that the DDID can point to other locations that contain other values you want, not just "John Smith" or "null" or the value 0. In the Big Privacy-enabled example (187), the value of "John Smith" is not actually included in the blockchain itself, compared to the traditional blockchain example (185). Rather, the DDID ("DDID652") that temporarily points to the location containing the value "John Smith" is contained within the blockchain. The DDID value remains unchanged on the blockchain 187, but the value pointed to by the DDID can be changed without changing the blockchain itself.

[442] In another example, BigPrivacy "eliminates" in the case of a "smart contract" met by both parties (that is, at least one of many independent provisions is agreed by both parties). Right to do / right to be forgotten". The reason BigPrivacy can provide this level of privacy/anonymity is that when both parties fulfill the contract, the other party's records are no longer needed (ie, their obligations to the other party are already met). In one example, this request to erase/forget personal information of the person involved in the smart contract may occur during the trading or exchange of financial instruments.

[443] Mike Hats, Chief Security Architect at RedHat, notes that confidentiality, integrity, and availability of smart contract performance are key issues: “Once a contract (smart contract) is over and you move to a blockchain or distributed ledger, it's almost immutable by definition. But what about before the contract ends? A simple contract of the type described at the beginning of this post is indivisible. In other words, it is "indivisible and irreducible". In most cases, they happen instantaneously.
The same applies to "smart contracts". Because smart contracts require processing, they will exist over time. This means that during processing, the vulnerability could be subject to any attack. [Two related elements] Standard list [includes]:
Confidentiality: The state of "smart contracts" can be subject to snooping, which can lead to asymmetric knowledge and disclosure to unauthorized parties.
Integrity: This is a nightmare for many "smart contracts." If a user can change the internal state of code that executes a smart contract (whether intentionally or not), whether or not the user is a party to the underlying contract, the results of that "smart contract" will change. .. In this case, the parties to the contract will be challenged. In addition, the suspicion of deficiency, not the deficiency of integrity, is the basis for integrity. Runtime integration, let alone displaying defects, is very difficult to implement. ]

[444]BigPrivacy's technology eliminates the above-mentioned snooping problems in, for example, protecting information and contract details of parties involved in smart contracts. In other words, BigPrivacy assumes that snooping can occur by any means, but the data obtained by such snooping is certainly not worth it to the snooper. The reason is that the data is just a DDID, and the "real" value data snoopers need. Regarding integrity, BigPrivacy ensures that the parties themselves do not modify their code, either intentionally or unintentionally, by making the contract itself (including the smart contract participant's ID) unavailable to snoopers. I will. Changes to the code will produce completely random results.

[445] Designed for data protection

[446] Article 25 of the GDPR requires data controllers to implement appropriate safeguards "both at the time of processing decision and at the processing itself." According to Article 25, this is one method of "personal data pseudonymization".

[447] Designing for data protection should be done as soon as possible. Therefore, by default, data usage is limited to the minimum scope and time required to support the specific usage authorized by the data subject. With today's standards, data is available and the effort and effort it takes to protect it. The GDPR mandates that this current standard needs to change. Regardless of pseudonymization, items specifically mentioned in Article 25 of the GDPR, or other means, the GDPR shows protection at the earliest point and is limited to uses specifically authorized by the data subject. Need to.

[448]Details of GDPR Section 78 is as follows. "For the protection of individual rights and freedoms, the processing of personal information must take appropriate technical and organizational measures to meet the requirements of this regulation. Demonstration of compliance with this regulation To do so, data managers must adopt internal policies and implement measures that meet the principles of data protection and default data protection, especially from the design stage. Is included.”

[449] GDPR Article 4(5) defines "pseudonymization" as requiring that the informative value of data be separated from the risk of re-identification. This separation is necessary to benefit from the GDPR statutory/regulatory incentives and rewards for pseudonymization. Replacing multiple occurrences of the same personal data element (such as the name of a data subject) with "static" (or persistent) tokens reidentifies the information value of the data to reidentify correlations and linkage attacks. Inseparable from risk (aka "mosaic effect"). This is possible because "static" (or persistent) identifiers are used instead of dynamic identifiers.

[450] As mentioned earlier, the "static" tokenization approach to protecting data uses persistent identifiers. By searching for a specific tokenized string that is repeated within or between databases, a malicious attacker or intruder can gain enough information to reveal the identity of the data subject. I will. This is an increasing scope issue for analytics and other processes that combine and blend internal and external data sources. In contrast, if a data element is replaced every time it is stored with a different pseudonymous DDID, each DDID has no algorithmic relationship with the other DDID, so the same malicious intruder belongs to the DDIDs. , Or you will not be able to determine that it is related. It goes without saying that we cannot reveal the names of data subjects and other identifying information.

[451] Referring now to Figure 1Z-2, there is shown, according to one example, another exemplary distributed network built on blockchain-based technology. Figure 1Z-2 shows a situation where the name of the data subject is encrypted (using an encryption algorithm, for example) or replaced with a static token. For these purposes, the acronym "ABCD" is again used as an exemplary representation of the result of such an encryption or tokenization process. The same encrypted/tokenized value of "ABCD" is used to reference "John Smith" in multiple blockchains. This is shown in Figure 1Z-2 as block #1 (190) and block #2 (192), each block of data "ABCD". As mentioned earlier, the persistent (or static) use of the same encrypted/tokenized value ("ABCD" in this example) is to It could eventually lead to John Smith's re-identification without requiring access. Failure to protect John Smith's identity information is likely to be a breach of the data controller's obligations pursuant to Section 25 and Section 78 of the GDPR above.

[452] Referring now to FIG. 1Z-3, in one example, yet another exemplary distributed network built on blockchain-based technology in which anonymized privacy controls may be employed is shown. Figure 1Z-3 shows how to use different DDIDs on different blockchains (in this example, block #1 (195) uses "DDID652" and block #2 (196) uses "DDID971". The DDID acts as a "pointer" to the value of the name "John Smith". In this way, the immutable nature of the blockchain and referential integrity while providing the requirements for pseudonymization in GDPR Article 4(5) and the dynamism necessary to meet the default data protection in the design phase of GDPR Article 25. You can maintain sex.

[453] Therefore, BigPrivacy does not need to change the underlying blockchain algorithm for verification. Rather, Anonos BigPrivacy relies on the fact that the currently implemented blockchain cannot: (I) compliance with key elements of the GDPR (the GDPR imposes technical requirements to protect the privacy of individual data subjects) and (ii) that the data remains unchanged. The technical requirements (such as forgetting rights and data protection by design and defaults) and blockchain's requirements for immutability cannot be met unless this invention applies to the implementation of blockchain. In addition, BigPrivacy can be used to protect the identity of the original trading partner for the "smart contract" before, during, and after such "smart contract" execution.

Technologies such as [454]blockchain track copyright registration certification, digital use and payments to content creators of copyrighted content, including wireless users, musicians, artists, photographers, writers, and more. .. You can also track high-value parts as they move through your supply chain. It also allows you to protect spectrum sharing on your wireless network and vote online. It also enables the activation of "managed qualifications", the implementation of information systems for medical records, the identification and verification of ownership of digital art, and the acquisition of ownership of game assets (digital assets). Enables new sales methods for the insurance industry, including peer-to-peer insurance, parametric insurance and micro insurance. It also enables collaborative work in areas such as the sharing economy and the Internet of Things (IoT).

[455] Figure 2 is an example of the invention and illustrates an example of process operations or steps that may be performed by an abstraction module of a privacy server, such as the abstraction module 52 shown in Figures 1 and 1A. In one example, in step 1, party ZZ (shown as "RP ZZ") submits a request through the privacy client. Alternatively, it resides on the privacy server on the same computing device as the privacy server for the desired action, activity, process, or characteristic. Request initiation can be configured to be predictable, random, automatic, or manually initiated. For example, stakeholder RP ZZ sends a request for web browsing.

[456] In step 2, for example, the privacy server abstraction module determines the combination of attributes needed to perform on the desired action, activity, process or characteristic and sets them to the combination A ("AC A )) from the database. In the example implementation of this system, the privacy server abstraction module is configured to add or remove attributes, get a combination of attributes, and modify the attributes within any combination.

[457] In the example of an e-commerce site that sells sports equipment, a privacy server abstraction module is used because attributes related to an individual's height, weight, and budget perform on a desired action, activity, process, or characteristic. May be determined to be necessary. The height, weight, and budget attributes of the specified data subject may be retrieved from the database to form a combination of attributes that consist of them. In the example of a doctor submitting a request for blood pressure information, the privacy server abstraction module determines that the attribute consisting of the most recent recorded systolic and diastolic blood pressure values is to perform for the desired action, activity, process or characteristic. I think it is necessary to do. Therefore, you can get the latest systolic and diastolic blood pressure values for a given individual and form a combination of attributes that consist of them. Another example involves users visiting an online store for running shoes. Online retailers may not know who you are or whether you have visited the site in the past. Users may want to know that they are shopping for running shoes at a site they have visited, or they may want to know what shoes they have seen on other sites in the past few weeks. Users can notify their privacy servers to only release recent purchases and information set by other users to the visited site. As a result, in this example, the privacy server can choose the following attributes: Shoe size = 9, shoes recently visited on other websites = Nike X, Asics Y, New Balance Z, average price of shoes viewed = $109, customer zip code = 80302, customer gender = male, shopping Customer weight = 185 pounds. The privacy server either collects these attributes and either generates a unique DDID or accepts or modifies a temporarily unique, dynamically changing value to act as a DDID, assign a DDID to the attribute and visit it. Send as TDR to website. When a user views Saucony model 123, the website adds this attribute to the information related to the shoe-related attribute displayed and sends this information to the privacy server as part of the enhanced TDR.

[458] In yet another example, a bank clerk is working with a client who wants to add a savings account to the accounts they hold with the bank. The bank employee does not need to know all the information about the client, only the information needed to open an account. Using the present invention, a banker can contact a bank's privacy server via a privacy client to request the customer to open a new savings account. The bank's privacy server may determine the source of the request and data authorization restrictions for the desired action. Bank privacy servers may collect the following attributes about customers: Name = Jane Doe, Current Account Number = 12345678, Current Account Type = Confirmation, Customer Address = 123 Main Street, Boulder, CO 80302, Other Signer Accounts = Bill Doe, Signer-Customer = Husband Relationship .. After the bank's privacy server collects these attributes, it assigns a DDID to these attributes and sends the information to the bank clerk as an extended TDR through the privacy client.

[459] Data managers can choose to include data attributes in attribute combination A, in one example. This allows the recipient of the TDR to use existing tracking techniques to anonymously track the party ZZ while the resulting TDR exists. Data managers may also include data that is more accurate than that available through existing tracking technology to facilitate personalization and customization of proposals to interested parties ZZ.

[460] In step 3, in one example, a DDID request is made to the privacy server ("PS"). This includes generating a unique DDID or temporarily unique, which acts as the DDID used by the system for a particular level of abstraction request and a particular activity, requested action, process, or characteristic. It may include a request to accept or change a dynamically changing value. Before assigning a DDID, the PS verifies that the DDID value is not being actively used by another TDR. It may include a buffer period to handle potential outages and system downtime.

[461] In step 4, in one example, the PS abstraction module assigns and stores a DDID in response to a request for an action, activity, process, or characteristic. Step 4 may further include the act of assigning DDID X to the web browsing requested by party ZZ.

[462] In step 5, in one example, the PS abstraction module creates a TDR by assigning a DDID X with the combination of applicable attributes retrieved. While the TDR itself may not contain information about the actual identity of the party ZZ, the privacy server maintenance module may contain the information necessary to reassociate the TDR with the party ZZ. Step 5 may also include a secure database that associates the attribute combination request with the data subject associated with the combination. This allows related parties ZZ to be given a combination A that they deem necessary to perform with regard to the intended action, activity, process or characteristic of a particular attribute.

[463] Figure 3 illustrates an example of additional steps that may be taken by the privacy server abstraction module in the present invention. In step 6, in one example, the TDR created for the party ZZ's web browsing request is a data-centric device, a service provider device, a cloud client accessible via the cloud network, or an applicable service provider, vendor, or Transmitted through a privacy client inside the same computing device as the privacy server to the merchant. Privacy clients may also obtain data related to desirable browsing activities with service providers, vendors, or merchants.

[464] Once the purpose of the TDR is reached or a given time limit is reached, in one example, the TDR can be sent to the privacy server via the privacy client. In step 7, add to the returning TDR a new attribute combination for each desired action, activity, process, or characteristic for which the TDR was created. In the example shown in Figure 3, the related party ZZ performs the desired web browsing in connection with the service provider, merchant, or vendor, and the combination of attributes that reflects the combination of attributes associated with the desired web browsing performed. Q (“AC Q”) is generated. Once the web browsing is complete or the TDR's temporary limit expires, a privacy client with a TDR enriched with a combination of attributes Q that reflects the data related to web browsing can send data to a service provider, vendor, or Transfer from the merchant to the privacy server. When the data is received at the privacy server, a time key (TKs) or other method and a combination of related attributes returned by the service provider, vendor, or merchant will associate a timestamp with the TDR in one example, or , The combination may be updated and stored in a secure database within the data subject's aggregate data profile.

[465] FIG. 4 illustrates an example of additional steps that may be performed following the operation of FIG. 3 according to an example of the present invention. As each extended TDR is received by the privacy server, the privacy server maintenance module associates the source data by associating a time stamp (TK) or other, DDID, and time stamp with the appropriate attribute in combination with the data subject. I will update. As shown in the example in Figure 4, the privacy server records the time stamp (TK) or otherwise, and records the DDID, attribute combination A, and attribute combination Q in the secure database. Associate with ZZ. Relationship information between time stamps, DDIDs, attribute combinations, data subjects, and related profiles can be saved, updated, or deleted as appropriate in the privacy server maintenance module. This includes, in one example, storing or updating all time stamps, DDIDs, attribute combinations, data subjects, and all relationship information between profiles in a secure database within the data subject's aggregate data profile. .. Once the new data associated with the desired action, activity, process, or characteristic from the combination of attributes is complete, in one example the DDIDs are reallocated for use in the new TDR in the same manner as above.

[466] Figure 5 highlights the differences between the exemplary single-tier abstraction implementation of the system as compared to the exemplary multi-tier abstraction implementation of the system in certain examples of the invention. Example 1, shown in Figure 5, shows an example of a system with a single layer of abstraction, as described earlier in the discussion of Figures 2-4 for Web browsing activities. Example 1 in Figure 5 shows an example of the final disposition that results from the Web browsing activity in Figure 2-4. Here, the secure database is updated with a record that associates a time stamp, such as the time key (TK) attribute combination A, Q, and DDIDX associated with the requesting associated party ZZ. Regarding Example 1, it is important to note that non-system parties do not have access to attribute combinations or identifying information about data subjects. However, within the system, the user of the replacement key (RK) described here shows the relationship between the related party ZZ, attribute combination A, attribute combination Q, and timestamp and DDID X.

[467] Example 2 of Figure 5 is an example and reflects one potential implementation of a multi-layer abstraction implementation of the system. The function of abstraction is not a disjoint one, but a function of multiple applications in the system. The dynamic nature of TDRs allows you to use the same baseline principles between levels of abstraction while still providing interaction with data on demand. In this example, a user who has been granted access to Privacy Server A and its associated secure database will be assigned a DDID X, DDID P, DDID TS, DDID YY association, and a timestamp associated with the associated attribute combination and DDIDs. You can access each of the. However, in one example, the user does not have access to the disclosed information about the association between different DDIDs. A second level abstraction of the DDID X and DDID relationship and the DDID TS and DDID YY relationship is only revealed if you access Privacy Server B and the associated secure database. This second level of abstraction is the relationship between subject DD and DDID X and P, and subject CV and DDID TS and YY, as shown in Figure 5.

[468] Example 2 reflects one potential implementation of the system's two-tier abstraction implementation, where subject CV and subject DD reflect the identity of the data subject in question. However, if the subject CV and subject DD values are each assigned a dynamically modifiable DDID, Example 2 reflects one potential implementation of the system's three-tier abstraction implementation. All elements of the system can be abstracted at multiple levels to achieve the desired level of security and privacy/anonymity.

[469] In the system use case, both Example 1 and Example 2 of FIG. 5 allow the privacy server validation module to validate and validate the combination of attributes and DDIDs embodied in the TDR or data profile. It may represent a certified data structure at any point in time with methodologies such as cyclic redundancy check (CRC), message authentication code, watermarking, and link-based timestamp methodology. These methods allow you to determine the state and composition of data at different times by checking the composition of each data subject, attributes, attribute combinations, aggregated data profiles, and other elements contained in the privacy server at different times. You can verify.

[470] In addition, in another use case, both Use Case 1 and Use Case 2 of Figure 5 require an access log module that allows for post-mortem legal analysis in the event of a system-related error or misuse. May contain different data.

[471] FIG. 6 illustrates an example process for providing data security and data privacy and anonymity in an example use case. Figure 6 shows an example process that can be implemented by an administrator or system. The operations outlined in Figure 6-10 are known programming techniques such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST) Application Programming Interfaces (API), or Service Oriented Architecture (SOA), and even healthcare. Smooth with standard industry standard data models such as HL7 for mobile, SID for mobile operators, ARTS for retail, ACORD for insurance, M3 for multi-commodity models, OAGIS for manufacturing and supply chains, PPDM for oil & gas/utilities, etc. It will be possible to do so.

[472] In step 1 of Figure 6, data attributes are received or created as input to the system. As described above for the purposes of this disclosure, data attributes may be, individually or with other data elements, to identify a data subject such as an individual, place, thing, or related action, behavior, process or characteristic. A data element that can be used in combination. An address consisting of 1777 6th Street, Boulder, Colorado 80302 is one example of a data attribute.

[473] In step 2 of Figure 6, a data attribute is associated with the subject of interest. In the example above, the data attribute address is associated with the Colorado City Court.

[474] In Step 3 of FIG. 6, the data attributes consisting of the applicable categories, values, and classifications and the determinants are associated with the respective data elements, and the attributes are utilized in relation to the action, action, process, or record that the user wants to perform. Easy to do. For example, the element associated with the address in the data attribute above could be: (A) Classified as an address (b) Value: 1; 7; 7; 7; 6th; S; t; r; e; e; t; B; o; u; l; d; e; r; C O; l; o; r; a; d; o; 8; 0; 3; 0; 2; or a combination of these values (c) The building is stationary and in nature. Another example of a data attribute associated with a target building that is considered part is building status (a) classified as building status (b) having a value indicating good status (c) building status Another example of a data attribute related to the building of interest that is inherently classified as a variable because is likely to improve or degrade over time is (a) classified as an organization with offices within the building. (B) Classified as a value for the Boulder Alternative Sentencing Program (CASP) in Colorado (c) CASP has the potential to change office locations in the future, so information from external factors that are classified essentially as variables Note that may include attributes associated with the data subject. For example, in the building above, the Boulder Colorado Alternative Sentencing Program (CASP) has an office in the Colorado City Court Building, John Smith works at CASP, and weekday John Smith appears on 6th Avenue 1777 in Boulder. Knowing that, the original person can use the information from this external factor to identify the address of the Colorado City Courthouse in Boulder. Therefore, the fact that John Smith works for CASP could be an attribute of the data subject and could reveal the data subject, the building of the address.

[475] In step 4 of Figure 6, each data attribute entered into the system is added to the data subject's aggregate data profile (see, for example, Figures 1 and 1A). In the example above, the above data attributes would be added to the Colorado City Court aggregate data profile.

[476] In step 5, the attribute combination is identified and formed to provide support for the desired activity, action, process, or characteristic. This step may involve creating or loading a template that specifies the required attributes for a particular action, activity, process, or characteristic. For e-commerce actions, for example, the template can request information about the data subject's age, gender, size, and preferred color as attributes. In another example of using the travel booking feature, the template might request information about data-based air travel by economy class, business class, or first class as attributes. The privacy server can load or access multiple such templates to support different actions, activities, processes or characteristics. In addition, the Privacy Server can be configured to facilitate the creation of new templates for new actions, activities, processes or characteristics required or manual overrides of existing templates as required by the controller. Such a manual override can be done, for example, by the GUI of the privacy client running on the data subject's mobile device. For example, a data subject may use the GUI to request information about a Data Subject's preferred means of travel by Economy Class, Business Class, or First Class because the Data Subject may be traveling on a cruise ship. Can be overridden. So a Data Subject can similarly specify whether it wants a suite, balcony, stateroom, outer stateroom, or inner stateroom as an attribute. In this example, the GUI allows the data subject to select the minimal attributes to send from the data subject's aggregate data profile.

[477] In step 6, the privacy server is accessible through the data-based device, the service provider device, the cloud network, and resides on the same computing device as the privacy network for the particular action, activity, process, or characteristic. Receives a request from a potential privacy client. The nature and nature of the requests that the privacy server may receive from the privacy client include whether the system is implemented as DRMI, DRMD, etc. The nature may vary depending on various factors, such as whether they are involved.

[478] In step 7, a decision is made about the level of abstraction that is appropriate for security, anonymity, privacy, and relevance for a particular action, activity, process, or characteristic. For example, a system can introduce an initial layer of abstraction by linking related data attributes and segregating related data attributes into TDRs that are deemed desirable for a particular action, activity, process, or characteristic. By replacing individual attributes, combinations of attributes, or both with DDIDs that are incomprehensible without access to the replacement keys (RKs), you can not only separate data attributes into TDRs, but also introduce an additional layer of abstraction. .. The privacy, anonymity, and security of attributes included or referenced within the TDR can be further improved or enhanced by using known protection techniques such as encryption, tokenization, pseudonymization, and deletion, and additional DDIDs You can introduce an additional layer of abstraction by using to reference networks, the Internet, intranets, and third-party computers that can integrate or communicate with implementations of the invention.

[479] In step 8, the desired combination of attributes is selected by the controller from the privacy server based on the attributes associated with the applicable template that may be required for the desired action, activity, process or characteristic. I will. The abstraction module can determine the appropriate attributes that may be controlled by the controller or delegated to another user as an authorized party. Authorized users can use abstraction modules to select attributes based on a default template and select attributes on the fly, or, among other methods, successfully detect the appropriate input. I will.

[480] In the example in step 8 of an e-commerce site that sells sports equipment, an Internet browser provider acting as a controller uses a privacy server abstraction module to control the height, weight, and budget of data subjects. Determine the information. This information is needed by the receiving website to provide the appropriate sports equipment options such as kayaks and paddles.

[481] In step 9, the privacy server abstraction module either generates unique DDIDs or receives or modifies dynamically changing values that are unique in time to act as DDIDs, and the DDIDs in step 8 Assign to a combination of attributes to form TDRs. These DDIDs can provide various functions such as replacement or simple association. For example, if an Internet browser provider acting as a controller tells the abstraction module to create a TDR with a single layer of abstraction, it can access other TDRs of the same data subject without accessing the association keys (AKs). You may assign DDIDs that are not visually associated. As another example, if an internet browser provider acting as a controller instructs the abstraction module to create a TDR with a two-layer abstraction, (i) assign DDIDs associated with the data attributes of the TDR's duration, (Ii) Furthermore, the data attributes are further abstracted by assigning the Abd DDID to the data subject's weight, the 67h DDID to the data subject's height, and the Gw2 DDID to the data subject's budget. Step 9 also includes retrieving attributes from the database, these attributes being associated with the data subject. The DDIDs used in step 9 can be selected from previously unused DDIDs that are no longer in use.

[482] In step 10, the TDRs consisting of the combination of attributes and DDIDs are used by the privacy server for privacy by the recipient in relation to the desired action, activity, process, or characteristic associated with the recipient. It is sent to the recipient via the client. For example, in the above example, an Internet browser provider acting as a controller would send a TDR consisting of a DDID and a second level abstract data attribute consisting of Ab5, 67h, and Gw2 to the e-commerce site as a recipient. Can be delivered.

[483] In step 11, TDRs, which may consist of a combination of attributes and DDIDs for the action, activity, process, or characteristic you want to perform, are received by the recipient using the privacy client. Receiving a TDR may be the last step if your system is intended to produce big data analytics output. (For example, a possible use example of the present invention described in FIG. Z that provides anonymized/anonymized data for big data analysis so that the “right to be forgotten” is guaranteed for the applicable Data Subject(s). However, more interactive exploitation of TDRs includes steps 12 to 17 as an option.

[484] In step 12, optional TDRs, which consist of a combination of desired online actions, activities, processes, or attributes of attributes and DDIDs, are interpreted by the privacy client by the recipient and used for AKs or RKs. Provides access to. This is necessary to understand the content of TDRs. For example, in the above example, the e-commerce site as the recipient accesses the RK information, and the data subject's weight is the value caused by Ab5, the height is the value caused by 67h, and the value is the value caused by Gw2. Get budget information.

[485] In optional step 13, the privacy client can retrieve new data attributes associated with online actions, activities, processes, or characteristics that augment the original TDR data attributes as new information in TDR format.

[486] In optional step 14, the privacy client extends the original TDR data attributes as new information in the TDR format, creating new information associated with the offline activity associated with the desired online action, activity, process, or characteristic. Get the data attributes.

[487] In optional step 15, the privacy client sends a TDR to the privacy server, which consists of a combination of DDIDs and attributes associated with the online/offline session.

[488] In the context of steps 14 and 15, TDRs are sent via the privacy client to the privacy server without AKs or RKs, so they are sent in a decomposed and anonymized form. Therefore, if someone intercepts the TDRs, it will not reveal any information about the data subject such as the desired action, activity, process, or characteristic.

[489] In step 16 of optional step, in one example, reaggregation of attribute combinations is performed by the application by the maintenance module for the relationship information between the DDID and attribute combinations with the association keys (AKs) and (DKs) present in the privacy server. Run through. In this example, the original or modified TDRs could be returned to the privacy server and modified or added new information about recommended kayAKs and paddles to the data subject's aggregate data profile.

[490] Once the re-aggregation of the above re-data for desired actions, activities, processes, or characteristics from a combination of attributes is complete, in this example the DDID is considered to have expired and optional step 17, other users An attribute, combination of attributes, data subject, action, activity, process, characteristic, or data is reintroduced into the system for reassignment and use. At the same time, new TDRs are formed in the same way as above.

[491] For example, the DDIDs Ab5, 67h, and Gw2 assigned to the attribute in Step 9 above are assigned to data attributes associated with other data subjects, for example, in a similar case-hop or remote case sleep scheme. For example, in the case of a case hop, a reassociation of Ab5 with a second data subject with a similar weight to the initial data subject, or reassociation of some or all of the data about the weight but with the same number but not associated with the same data subject. May include associations. On the other hand, remote case sleep requires reassigning Ab5 to extraneous data attributes waiting for DDID.

[492] In the second example in Figure 6, a doctor can request blood pressure information about a patient's data subject collected offline by a nurse and entered online in a data subject's aggregated data profile. Due to this request, as part of step 8 above, the privacy server abstraction module may extract a combination of attributes consisting of the most recent systolic and diastolic blood pressure values of the data subject. As part of step 9, instead of specifying the identity of the data subject, the privacy server may combine the combination of these attributes with the DDID assigned by the privacy server to form the TDR. As part of step 10, assigned through a privacy client that is accessible through the subject device, service provider device, cloud network and that resides in the cloud network or resides on the same computing device as the privacy server You can tell your doctor your blood pressure attributes along with your DDID. At this point, the combination of blood pressure DDID and attribute combinations make up the TDR. As part of step 12, the doctor as a recipient reads the blood pressure values via RKs and as part of steps 13 and 14 the blood pressure measurement as a new attribute, online and offline observations, recommendations regarding this. Record matters or comments. As part of step 15, the TDR augmented with online/offline information is returned to the privacy server via the privacy client. As part of step 16, the privacy server can use this information to update the aggregate data profile for the data subject. In this way, the unintended recipient of the TDR will not be able to correlate the data subject's ID, and only a DDID that can be reassigned to another data subject in a similar case-hop or remote case sleep method after use by the doctor. It shows.

[493] Figure 6A shows an example of a process that provides data security, data privacy, and anonymity for a use case involving interaction with an external database. Figure 6A illustrates process steps that may be implemented by a controller or system in one example.

[494] In step 1 of Figure 6A, a third-party data source sends as input to the system data that includes data attributes related to the data subject. In Figure 6A, before submitting data that includes data attributes related to data subject input into the system, an aggregated data profile (eg Figure 1A) for each data subject held by a third party data source in the database, either directly or indirectly. Note that we have already created it.

[495] In step 2, the privacy server is accessible through the data-based device, the service provider device, the cloud network, and resides on the same computing device as the privacy network for the particular action, activity, process, or characteristic. Receives a request from a potential privacy client. The nature and content of the request received by the privacy server from the privacy client depends on whether the system is implemented as DRMI, DRMD, etc., the request is related to medical, educational, mobile, financial, web, internet of things, and other applications. It may vary depending on various factors such as whether or not to do it.

[496] The privacy, anonymity, and security of attributes contained or referenced within the TDR can be further improved or enhanced by using known protection techniques such as encryption, tokenization, pseudonymization, and deletion, An additional layer of abstraction can be introduced by referencing networks, the Internet, intranets, and third party computers that can integrate or communicate with implementations of the present invention using additional DDIDs,

[497] In step 3, a decision is made about the level of abstraction that is appropriate for the security, anonymity, privacy, and relevance of a particular action, activity, process, or characteristic. For example, a system can introduce abstraction by abstracting individual attributes, a combination of attributes, or both by representing them with DDIDs that cannot be understood without access to replacement keys (RKs). The privacy, anonymity, and security of attributes included or referenced within the TDR can be further improved or enhanced by using known protection techniques such as encryption, tokenization, pseudonymization, and deletion, and additional DDIDs You can introduce an additional layer of abstraction by using to reference networks, the Internet, intranets, and third-party computers that can integrate or communicate with implementations of the invention.

[498] In step 4, the desired combination of attributes is selected by the controller from the privacy server based on the attributes associated with the applicable template that may be required for the desired action, activity, process or characteristic. I will. The abstraction module can determine the appropriate attributes that may be controlled by the controller or delegated to another user as an authorized party. Authorized users can use abstraction modules to select attributes based on a default template and select attributes on the fly, or, among other methods, successfully detect the appropriate input. I will.

[499] In one example of step 4, in a healthcare research study, a hospital acting as a controller uses the privacy server abstraction module to send data subjects before sending information to the research facility. Obfuscates information about your height, weight, and name.

[500] In step 5, the privacy server abstraction module assigns a DDID to each attribute combination in step 4 to form TDRs. These DDIDs can provide various functions such as replacement or simple association. As an example, if a hospital acting as a controller instructs the abstraction module to create a TDR with two layers of abstraction, the DDID of Ab5 is the weight of the data subject and the DDID of 67h is the height of the data subject and the data. It abstracts the data attributes by assigning the subject's name to the Gw2's DDID, which is incomprehensible without access to the replacement keys (RKs). Step 9 also includes retrieving attributes from the database, these attributes being associated with the data subject. The DDIDs used in step 5 can be selected from previously unused DDIDs that are no longer in use.

[501] In step 6, the TDRs consisting of the combination of attributes and DDIDs are used by the privacy server for privacy by the recipient in relation to the desired action, activity, process, or characteristic associated with the recipient. It is sent to the recipient via the client. For example, in the example above, a hospital acting as an administrator could deliver a TDR consisting of an abstract data attribute consisting of Ab5, 67h, and Gw2 to a recipient research facility.

[502] In step 7, TDRs, which may consist of a combination of attributes and DDIDs for the action, activity, process, or characteristic you want to perform, are received by the recipient using the privacy client. For example, in the example above, the recipient research facility receives the information for analysis, but does not reveal any personally identifiable information about weight or height. Rather, the research facility receives Ab5, 67h, and Gw2 that cannot be deciphered unless authorized to access the relevant RK information. As long as the goal is big data analytics, receiving TDRs may be the last step, but more interactive use of TDRs may include optional steps 8-13.

[503] In optional step 8, TDRs (composed of DDIDs and combinations of desired action, activity, process, or property attributes) are interpreted by the privacy client by the recipient and used for AKs or RKs. Provides access. This is necessary to understand the content of TDRs.

[504] In optional step 9, the privacy client can retrieve new data attributes associated with online actions, activities, processes, or characteristics that augment the original TDR data attributes as new information in TDR format.

[505] In optional step 10, the privacy client extends the original TDR data attributes as new information in the TDR format, creating new information associated with the offline activity associated with the desired online action, activity, process, or characteristic. Get the data attributes.

[506] In step 11 of the optional privacy client sends a TDR consisting of a combination of DDIDs and attributes associated with the online/offline session to the privacy server. TDRs are sent to the privacy server via the privacy client without AKs or RKs, so they are sent in a decomposed and anonymized form. Therefore, if someone intercepts the TDRs, it will not reveal any information about the data subject such as the desired action, activity, process, or characteristic.

[507] In optional step 12, in one example, re-aggregation of attribute combinations is performed by a maintenance module for the relationship information between the DDID and attribute combinations with association keys (AKs) and replacement keys (RKs) that exist on the privacy server. It runs through the application. In this example, the original or modified TDRs could be returned to the privacy server and modified or added new information about recommended kayAKs and paddles to the data subject's aggregate data profile.

[508] Once the above re-data re-aggregation for the desired action, activity, process, or characteristic from the attribute combination is complete, the DDID is considered expired in this example, and optional step 13, other users An attribute, combination of attributes, data subject, action, activity, process, characteristic, or data is reintroduced into the system for reassignment and use. At the same time, new TDRs are formed in the same way as above.

[509] Figure 6B illustrates how to provide dynamic anonymity to data elements contained in the database for use cases that are considered sensitive and cannot be exposed in a way that is identifiable outside the organization ( The database may be internal to the system as shown in Figure 1A or external as shown in Figure 1B). Data subject or sensitive action, activity, data that directly identifies a process or characteristic (direct identifier), or data that indirectly identifies the data Target or sensitive action when combined with other data (quasi-identifier) , Activities, processes and characteristics are examples of such data elements. The system may dynamically hide sensitive data when exposed outside the organization by replacing the data with DDIDs. The keys needed to understand the association of DDIDs with obscure sensitive data are kept secure in the Circle of Trust (CoT) and are only available to authorized parties. By "designing" DDIDs (that is, planning your data hiding strategy as such), you enable different levels of data usage and analysis of DDIDs that are consistent with the PERM established by the data subject or trusted party. I will. The Confidential Data represented by DDIDs may not be disclosed until the data subject or a trusted party requests a key from a party authorized to receive or use the underlying Confidential Data.

[510] In a use case, the obfuscation of sensitive data described above involves intercepting a request for sensitive data from a database at the presentation layer of the computer application described above, and replacing the sensitive data with a DDID as described above. Only done for certain computer applications that request data from the database. Other possible implementation examples are as follows. By intercepting requests for sensitive data at the database connection level or replacing sensitive data with the above DDIDs, it is possible to obfuscate sensitive data for computer applications that request data from the target database.

[511] Figure 6B illustrates, in one example, a process that an administrator or system can implement to anonymize sensitive information.

[512] In step 1 of FIG. 6B, the privacy server receives a request from a privacy client that is accessible through a data subject device, a service provider device, a cloud network, and resides on the same computing device as the privacy server. I will. This request is a data element contained in a database that is considered sensitive and cannot be exposed in a way that is identifiable outside the organization (as shown in Figure 1B even though the database is internal to the system as shown in Figure 1A). (Even outside). Data subject or sensitive action, activity, data that directly identifies a process or characteristic (direct identifier), or data that indirectly identifies the data Target or sensitive action when combined with other data (quasi-identifier) , Activities, processes and characteristics are examples of such data elements. The nature and nature of the requests that the privacy server may receive from the privacy client include whether the system is implemented as DRMI, DRMD, etc. The nature may vary depending on various factors, such as whether they are involved.

[513] In step 2, the abstraction module determines the level of abstraction required for security, privacy, anonymity, and association of sensitive information elements. DDID association strategies with data subjects or relying parties have been developed for sensitive data elements that are consistent with the scope of data use/analysis permitted by PERMS.

[514] In step 3, the DDID determined by the abstraction module to dynamically hide sensitive data elements is sent to the privacy client.

[515] In step 4, sensitive data elements are dynamically hidden by replacing the data elements with DDIDs determined by the abstraction module, and the resulting DDIDs are used to secure the confidentiality of data communicated outside the organization. The data element is replaced. Here is an example from step 3: The presentation intercepts requests for sensitive data from the database and replaces the sensitive data with DDIDs, as determined by the layers of computer application and abstraction modules above, to identify specific requests for data from the target database. Obfuscation of sensitive data elements occurs only for computer applications. Here is an example from step 3: The presentation intercepts requests for sensitive data from the database and replaces the sensitive data with DDIDs, as determined by the layers of computer application and abstraction modules above, to identify specific requests for data from the target database. Obfuscation of sensitive data elements occurs for computer applications.

[516] In step 5, the keys needed to understand the association between DDIDs and obscure sensitive data elements are securely stored in the Circle of Trust (CoT).

[517] In Step 6, the keys needed to understand the association of DDIDs with obscure sensitive data elements securely stored in the Circle of Trust (CoT) are available only to authorized parties. To be able to. Confidential data represented by DDIDs will not be disclosed until the data subject or a trusted party requests a key from a party authorized to receive or use the underlying sensitive data.

[518] Figure 7 illustrates example process steps that may be performed by a recipient in the examples of this disclosure.

[519] In step 1, a TDR consisting of a combination of attributes selected by the controller combined with a DDID associated with a data attribute during the TDR is received by the privacy client on the device of the data subject by the recipient. It is received by the client. Indicates a request for an action, activity, process, or characteristic of interest on a service provider device, accessible via the cloud network, resident within the cloud network, or on the same computing device as the privacy server. In our kayak example, an e-commerce site recipient might receive a data subject TDR request for a desired action, activity, process, or characteristic.

[520] In step 2, TDRs, which may consist of DDIDs and combinations of desired online actions, activities, processes, or attributes of attributes, are used by privacy clients that provide access to the use of AKs or RKs. Interpreted by the recipient. This is necessary to understand the content of TDRs. For example, in the example above, the e-commerce site has access to information in the RK that is data-centric device, service provider device, accessible through the cloud network, within the cloud network, or on the same computing device as the privacy server. Then, get the information of the weight of the data subject, which is the value caused by Ab5, the height, which is the value caused by 67h, and the budget, which is the value caused by Gw2.

[521] In Step 3, in one example, the recipient can use the received TDR information to customize the response to the sent attributes of the data subject. In the kayak example, this allows the e-commerce site to use the information to provide data-oriented suggestions for the kayak and paddle to buy.

[522] In step 4, the privacy client, in one example, retrieves data of online activities performed by the recipient associated with the attribute combination through access to the privacy client residing on the data subject device, the service provider device. To get The privacy client is accessible via the cloud network and either resides on the cloud network or resides on the same computing device as the privacy server.

[523] In step 5, in one example, the recipient retrieves offline activity data associated with the attribute combination and converts it into online data. In the case of a kayak, for example, the data subject is also a loyalty reward member of a physical store operated by an e-commerce site. You can increase more.

[524] In step 5, in one example, the privacy client sends data related to attribute combinations and DDIDs associated online sessions and offline activities to the privacy server in a disaggregated and anonymized format.

[525] In Step 6, the DDID component of the TDRs is reintroduced into the system and used with other attributes, attribute combinations, data subjects, actions, activities, processes, characteristics, or data, and new TDRs in the same manner as above. Is formed. The same DDID may exist later, but this DDID may not be able to connect to other TDRs associated with the data subject or previously associated TDRs. For example, later in the day or later in the week, the same DDID may reappear on an e-commerce site, but with different information attached to a completely different data subject.

[526] In the second example of Figure 7, the physician requesting blood pressure information, as part of step 1, passes the last recorded systolic and diastolic blood pressure values via the privacy client and the data by the privacy server. Receives a TDR consisting of the DDID assigned to the principal. As part of steps 2 and 3, your doctor can read your blood pressure information. As part of steps 4 and 5, doctors can add blood pressure observations, recommendations, or comments. This will be sent to the privacy server through the privacy client residing on the data subject's device as part of step 6. It is accessible on the service provider device through the cloud network and is either in the cloud network or on the same computing device as the privacy server.

[527] Figure 8 shows an example process for verifying the entitlement to progress for an action, activity, process, or characteristic at a particular time or place in an example deployment.

[528] In step 1, as an example, the recipient is sending a request to a privacy server. It is accessible via data-centric devices, service provider devices, and privacy clients residing on cloud networks. This request verifies that private data subjects and related parties associated with the TDR are authorized to join. For example, if after searching for recommended kayAKs and paddles on an e-commerce site and it is ready to purchase, the e-commerce site will query the privacy server's authentication module to allow the parties involved to complete the requested transaction. Is allowed.

[529] In step 2, in one example, the privacy server's authentication module compares the DDIDs contained in the TDR with the list of authorized DDIDs contained in the database and authorizes the data subject or related parties for a specified time. And decisions about activities, processes or characteristics at a location. In the kayak example, the privacy server's authentication module verifies that the DDID used is still active and authorized, thereby ensuring that the data subject or party is authorized to complete the intended transaction. Indicates.

[530] optionally, in step 3, in one example, the privacy server resides on a data subject device, on a service provider device, on the cloud network and accessible via the cloud network, or on the privacy server (in this case e Make sure that the same computing device as the commerce site) is allowed to participate in the desired transaction.

[531] If the optional step 3 is called, in one example, check whether the party controlling the privacy client was confirmed in step 4 to be authorized. For example, in order to avoid attempts to impersonate a trusted user for usernames, passwords, credit card details, and other information (also known as "phishing"), step 4 involves kayaking equipment with known authorization techniques. You may need to be verified by an e-commerce site that is an authorized reseller of.

[532] In step 5, in one example, if verification is obtained, the authentication module of the privacy server sends authorization status information to the party under control of the privacy client.

[533] Step 6, in one example, uses the grant status information to allow or deny the action, activity, process, or characteristic that you are looking for.

[534] In step 7, after the authentication function is performed and the optional additional verification steps are completed, the privacy server sends through the privacy client the AK or RK information needed to interpret the TDR content. .. Products and transactions are processed by the recipient. The recipient is an e-commerce site in the above example.

[535] In the second example in Figure 8, the doctor sends a TDR through the privacy client to the privacy server to see if the patient data subject is allowed to participate in the exploratory study. This allows the privacy server's authentication module to compare the data subject's DDID in the TDR with the list of allowed DDIDs contained in the database to determine whether the data subject is allowed to participate in the survey, as part of step 2. Judge Optionally, in step 3, the privacy server's authentication module can request a physician to confirm that the data subject has the authority to require that they be participants in an exploratory study. When optional step 3 is called, step 4 checks if the doctor has been approved by a known authorization method such as password verification or multi-factor authentication. If the verification is successful in step 5, the privacy server's authentication module sends the approval status information through the privacy client and uses the approval status in step 6 to allow or deny the data subject's request to join. .. Exploratory research and step 7 provides access to the AK and RK key information needed to interpret and continue the TDR content.

[536] Figure 9 shows an example of a process for refraining from disclosure unless the replacement key (RK) or association key (AK) information or other protected information is validated for the deployment example. As shown in step 1, in one example, the party controlling the privacy client, including the TDR, uses the AK, RK, and/or the encryption module to the authentication module of the privacy server through the data-based device, the service provider device, and the accessible privacy client. Submits a request for the key needed to unlock a TDR data attribute that is protected using techniques such as digitization, tokenization, and pseudonymization. It is sent over the cloud network or through a data subject device that is on the same computing device as the privacy server.

[537] In the kayak example, the data can be sent using various additional steps to protect the data in transit, but at the recipient's e-commerce site, the height that the privacy client originally sent, You may need a key to unlock and associate the three pieces of information: weight and budget. In step 2, in one example, the Privacy Server authentication module compares the TDR recipient attribute combination with the correct recipient attribute combination to determine if the TDR recipient is the correct recipient. If the authentication module of the privacy server determines that the TDR recipient attribute combination matches the allowed recipient attribute combination, then through the privacy client as part of step 3, the TDR locks in one example. Send the key needed to unlock to the TDR recipient.

[538] In the second example of FIG. 8, in step 1, the doctor who received the encrypted, tokenized, or deleted TDR containing the requested blood pressure information is sent to the doctor via the privacy client by the privacy server's authentication module. You are authorized to send a TDR to and see the information requested by your doctor. In step 2, the privacy server's authentication module compares the doctor's TDR information with the correct combination of recipient attributes to determine if the doctor is an authorized recipient. If the privacy server authentication module determines that the doctor's TDR information matches the approved combination of recipient attributes, then the privacy server authentication module will encrypt, tokenize, or omit some of the blood pressure. The key required to unlock the TDR containing the information is sent to the doctor.

[539] Figure 10 shows an introductory example of anonymous interest analysis of interested parties. In step 1, in one example, a stakeholder (RP) selects a combination of attributes (AC) to share with a seller/service provider via a privacy client on a mobile or wearable device. For example, instead of using an e-commerce site, the parties can go to a physical sports outlet and share the same height, weight, and budget information via mobile or wearable devices.

[540] In step 2, the privacy server, in one example, can assign a DDID to a combination of attributes to form a TDR on a privacy client residing on a mobile/wearable/portable device.

[541] In Step 3, in one example, the TDR is sent to the merchant/service provider recipient via a privacy client that resides on the mobile/wearable/portable device. Taking the example of kayAKs, a store can receive three separate TDR-enabled data attributes from data-centric mobile/wearable/portable devices via in-store devices, beacons, etc.

[542] In step 4, in one example, the merchant/service provider recipient is identified by the attributes and sent to the merchant/service provider recipient by a privacy client resident on the mobile/wearable/portable device. You can see the combinations. For example, a store might display customer height, weight, and budget.

[543] In step 5, in one example, the merchant/service provider recipient can anonymously make suggestions to the data subject or customer without knowing who the data subject or parties are.

[544] In step 6, in one example, the data subject or customer may also respond to the merchant/service provider recipient's offer to find a product that is perfect for the customer.

[545] The systems and methods described in this document may provide related parties with a way to achieve greater anonymity and privacy/anonymity of data and improved security while leveraging communication networks. Without these systems and methods, a third party could be involved in the data subject or relationship based on the activities of parties involved on and between networks, through technology providers who have associated identifying information with the activities of network services and data subjects. You may be able to obtain the true identity of the parties

[546] Here we disclose various other ways to provide data security and data privacy/anonymity. The example has the following stages: Receiving an electronic data element at a computing device, identifying the data attribute of the electronic data element, selecting a DDID via the computing device, associating the selected DDID with the data attribute, the selected unique DDID and data attribute Create a TDR from

[547] In one example, the step of selecting a data element either generates a unique DDID or, in another example, accepts or changes a dynamically changing value that acts as a DDID. In one example, this method can also expire the association between the selected DDID and the data attribute. Another example would be to store information about how long the selected unique DDID was associated with different data attributes or combinations of attributes in a database accessible to the computing device. In another embodiment, the method may re-associate the selected unique DDID with the data attribute following expiration of the association between the DDID and the data attribute. In one example, DDID expiration is set at a given time and after the completion of a given event or activity. In another example, TDRs are only licensed for a specified period of time or in place. Another example can include changing the unique DDID assigned to a data attribute, which can be changed randomly or on a schedule basis, or after the completion of a given activity or event. There is a way to do it.

[548] Here, we provide another way to facilitate transactions over the network. I will explain the flow of an example. There is the step of receiving a request at the privacy server from the client device to carry out the activity over the network. Determines which of the multiple data attributes in the database are needed to complete the requested activity and creates the DDID. Create a combined TDR by associating the DDID with the determined data attributes. Makes the combined TDR accessible to at least one network device to perform or initiate the requested activity. Receives a modified TDR that contains additional information related to the performed activity. Save the modified TDR to the memory database. As an example of the introduction of another method, we will explain how to perform controlled delivery of electronic information. This method receives a request for the privacy control module to perform an activity over the network. Select the attribute of the data subject in the database that is accessible to the privacy control module that is determined to be needed to satisfy the request. Other attributes of the data subject that are determined not to be needed here will not be selected. Apply the DDID to selected attributes and data subjects using the privacy control module abstraction module. DDID does not show unselected attributes. Records the time when a unique DDID was assigned. When the requested activity is complete, you will receive a unique DDID, the determined attributes, and the data subject applied by the privacy control module. The attributes are modified to include information about the activity performed. The privacy control module receives the time when the activities performed were completed, the unique DDIDs and the determined attributes, and the data subjects to which they apply.

[549] Alternatively, you can assign additional DDIDs to one or more of the selected attributes or data subjects. Another example would be to use the recorded time to reassociate the unique DDID and data attributes with the true identity of the data subject. This method reassigns the unique DDID to other data attributes and records the time when the unique DDID was reassigned.

[550] Here we describe another way to improve data security. This method associates the data subject with some attribute. Create a TDR by associating a DDID with at least one attribute. The TDR restricts access to the data subject's attributes to only those attributes required to perform a particular action. Another method assigns an association key (AK) or replacement key (RK) to the TDR, and authorized access to the TDR requires access to the AK or RK. Yet another method is to expire the association between the DDID and the attribute at a specific time or after the completion of a given event or activity. In another embodiment, the DDID can be re-associated with a different attribute after the association between the DDID and the attribute has expired. This method saves information in the database about the time period for which DDIDs were associated with different data attributes or attribute combinations.

[551] There are various possible ways to associate DDIDs with different attribute combinations to form TDRs. DDIDs have a particular variable length and can be composed of various constituent codes such as number, property, truth or property. As an example, only authorized parties that are managed by the maintenance module and can connect to federation keys (AKs) or replacement keys (RKs) needed to reintegrate dissociated attribute combinations in different ways. However, it has a function to determine which combination of attributes is correctly linked with other combination of attributes, Data Subjects, related parties, and integrated data profile. However, the site may track and utilize the combination of attributes contained within the TDRs in real time, and the site is temporarily present, and the associated DDIDs are associated with other actions, activities, actions, characteristics, It is understood that attribute combinations can be reused later on by Data Subjects and related parties.

[552] The combination of attributes sent may include one or more explicit data, personally identifiable information (PII), behavior-related data-derived data, rich data, or any other combination of data. There is a possibility.

[553] Example A

[554] In the first example, the related party is in control and the other party's combination of attributes is configured to be authorized with the intended recipient. Example A is a related party (Party X or “RP X”) operating in four types of online sessions provided by two service providers (“SP”s) in communication networks (“CN”s) in three different industries. ) Shows how the system handles the information generated by. Figures 11 to 20 illustrate this example and show how the information is processed under various stages and situations as one example of an embodiment of the present invention. It should be understood that FIGS. 11 to 20 are presented as examples only, and the present invention can be implemented in various ways other than the examples of FIGS. 11 to 20.

[555] Figure 11 shows that the relevant party X has an attribute combination A (explicit data) to a web service provider, such as Pandora Radio (“SP1”), to the online Internet (“Communication Network 1” or This is an example of transmission via CN1″). Attribute combination A has been assigned a temporary IDDD 1 identification code by the privacy server (“PS”) abstract module. The identification code, together with the attribute combination A, is transmitted to the SPI via CN1 and the security client. In FIG. 11, the combination A of DDID 1 and the attribute temporarily represents the TDR on behalf of the related party X.

[556] FIG. 12 shows that when exchanging information with SP1, related party X generated activity information (information related to behavior) that was transmitted to privacy client as attribute combination A1 and detected by SP1. , The privacy client may be resident on the Data Subject device, the service provider device, accessible or resident via the cloud network, or back to the privacy server and on the same computer device as the privacy server. The privacy server's maintenance module holds information about attribute combinations and various DDID codes, and like CN and SP associated with each attribute, the code is different for each attribute combination at different points in time. It is allocated in. In FIG. 12, the combination of DDID1, the combination of attributes A, and the combination of attributes A1 temporarily represent the TDR as a substitute for the party X only for the cooperation period of DDID 1, the combination of attributes A, and the combination of attributes A1. DDID 1 may be reassigned for use in a new TDR upon completing the coordination of new data regarding processing from the desired action, activity or combination of attributes. The combinations of DDIDs and attributes shown in FIGS. 13 to 20 also represent TDRs during the period in which the combinations of DDIDs and attributes are temporarily linked.

[557] FIG. 13 illustrates an example where related party X sends another attribute combination E (explicit data) to Pandora Radio ("SP1") via an online Internet connection ("CN1"). The attribute combination E is temporarily assigned the DDID 4 identification code by the privacy server (“PS”). The identification code is integrated with the attribute combination E and sent to the SPI via CN1 and the security client. Transmitted.

[558] FIG. 14 shows that when exchanging information with SP1 in this example, the related party X is sent back as a combination of attributes E1 via the privacy client to the abstract module of the privacy server and detected by SP1. The privacy client is either a Data Subject device, a service provider device, accessible or resident via a cloud network, or the same computer device as the privacy server. Can exist in.

[559] Figure 15 shows that the related party X transfers the attribute combination Q (explicit data) to another version of SP1 Pandora Radio in a mobile application format (“Communication Network 2” or “CN2”). It shows an example of transmitting via. The privacy server has temporarily assigned the DDID 9 identification code to the attribute combination Q, and the identification code is transmitted as a TDR to the CN2 and SP1 via the security client together with the attribute combination Q. ..

[560] FIG. 16 shows that when exchanging information with SP1, the related party X sends activity information (behavior detected by SP1 as a combination of attributes Q1 traced back to the abstract module of the privacy server via the privacy client. Relevant information), the privacy client is resident on the Data Subject device, the service provider device, accessible or resident via the cloud network, or on the same computer device as the privacy server. sell.

[561] Figure 17 shows an example where a related party X sends a combination of attributes P (explicit data) through a privacy client, which may be a Data Subject device, a service provider device internal or a cloud. To a service provider (“SP2”) that provides monitoring services related to exercise activities that are accessible or internal to the network or via wearable device communications such as FitBit (“Communication Network 3” or “CN3”) As a privacy provider for it, it can reside on the same computer device as the privacy server. The attribute combination P is temporarily assigned the identification code of DDID 7 by the PS, and the identification code is transmitted together with the attribute combination P as TDR to CN3 and SP2 via the security client.

[562] Figure 18 shows that when exchanging information with SP2 in this environment, SP2 calculates the percentage of desired daily calorie consumption (derived data) achieved by related party X, and that information is the privacy client. The privacy client is internal to the Data Subject device, the service provider device, accessible or internal through the cloud network, or traces back to the private server as a combination of attributes P1. It can reside on the same computing device as the server.

[563] Figure 19 shows an example of a combination of attributes that can be connected to each SP and retransmitted via a privacy client, which may be internal to the Data Subject device, the service provider device, or the cloud network. May be accessible via or internal to, or may be present on the same computing device as the privacy server, back to the private server. Figure 19 shows that the usage sessions within or between SPs can be between sessions or a small group of sessions, and as an example, SPs can be used between attribute combinations without access to the security federation key held by the maintenance module. He emphasizes that he does not have the information necessary to determine coordination. However, as an example, the SP has access to the combination of attributes created during each transient period, determined by the changing DDIDs. For example, SP1 associates DDID 1 and DDID 9 both with a related party X who has access through two different versions of the website held in SP1, two online Internet connections and two mobile device connections. I do not recognize that

[564] FIG. 20 shows an example of data accessible to a related party X, including all information sent to and re-transmitted from the SP. FIG. 19 shows an example of an entity controlled by the related party X by accessing the security linkage key held by the maintenance module, and the aggregation SP links linkage between attribute combinations for the purpose of aggregation and standardization. It emphasizes that you can have the information you need to make a decision. In addition, the related party X may retain information for use, or maintenance for utilization for the data facilitator, analysis and data processing under the protected environment. The new attribute combination Z is DDID 1, DDID 9, DDID 4, to predict what other music choices the related party X prefers to help achieve the desired calorie consumption for the day. Comparing all the data related to DDID 7 represents the new data ("rich data") generated by the maintenance module for the request of related party X. Attribute combination Z may contain a list of other musical choices made by this conjecture, as well as data associated with many other types of DDIDs. Attribute combination Z does not communicate with other parties (SP1, SP2, etc.) until requested by related party X acting as a control entity. When a related party X requests sharing with an attribute combination Z, as an example, it is assigned a DDID code prior to being communicated to the recipient designated by the related party X. This new set of attributes becomes more global and fluid when assigned to a receiving entity determined by related party X.

[565] Example B

[566] In the second example shown in Figure 21-22, the service provider (“SP3”) is the control entity authorized to determine to which party the combination of attributes associated with SP3 is released. The example shows that the system is configured to be a system. SP3 may use the system to improve the protection of client specificity, privacy and anonymity. This includes potentially reducing privacy and anonymity and reducing the likelihood of consumer or municipal repulsion as a result of market penetration and increased availability and use of SP3. There is. It is understood that FIGS. 21 to 22 are presented as examples only, and the present invention can be implemented in various ways other than the examples of FIGS. 21 to 22.

[567] Figures 21 and 22 show Input Technology Providers (“ITV”), Process Technology Providers (“PTV”), such as Online Electronic Payment Processing, to help capture other information such as website companies, and This is an example of SP3 providing each of the output technology providers (“OTV”) who deliver the electronically selected product to the consumer only the combination of attributes required to provide the service to which each is assigned. .. No provider has access to personally identifiable information (“PII”) that discloses the specificity of the SP3 client.

[568] Figure 23 illustrates an implementation of dynamically formed, mutable, reassignable DDIDs in Internet behavior-related ad delivery. Without the benefit of some implementations of the present invention, ad serving originally related to Internet behavior was ad network based, placing cookies in the user's web browser and placing ads on the same ad network. We build a profile by tracking the visitors of our site.

[569] Typically, when a user first visits the website in Figure 23 (“Website1”), the aforementioned website delivers (i) content from the website to the user's browser (ii) a cookie to the user's browser. (Iii) direct advertising content from the user's browser to the web address for activation of the advertising content from the advertising network (“Ad Network 1”) on the website. The cookie transmitted in (ii) above is called a "first party cookie" because it is linked to the website selected by the user. First party cookies can also be of benefit to users as they help keep "status" information such as login status, shopping cart items and other relevant information that enhances the user's experience. In part (iii) above, when the user's browser requests advertisement information from the advertising network 1, the advertising network 1 sends the advertisement to the user's browser and is displayed as part of the website 1. If the user's browser has never requested advertising content from ad network 1 in the past, ad network 1 also sends a cookie. This cookie is called a third-party cookie because it was not sent from a web page that the user intentionally visited. If the ad network 1 has not tracked users in the past, then the ad network 1 acts as an ad based on conventional ad delivery technology. When a user repeatedly visits a website that has an ad on Ad Network 1 (for example, the nature of the content on Website 1 is sent), Ad Network 1 (third party sent from Ad Network 1 to your browser) (Via cookies) builds a profile of that user's behavioral data based on the pages visited, time spent on each page, and other indeterminate factors such as the user's social media and online/offline purchasing behavior. It combines psychology and demographics with user information collected from the behavior of advertising network 1 or integrated information obtained from third party data providers. Based on the user's profile generated and managed by the ad network 1, the ad network 1 can display ads targeted to that user according to what the user has determined to be most interested.

[570] User tracking between sites and pages by this conventional third-party advertising network raises privacy and anonymity issues. In response, cross-disciplinary regulators, centered on the World Wide Web Consortium (W3C), an international organization that seeks to standardize the Web by unifying members' groups, full-time employees, and public activities The Tracking Denied Function (DNT) has begun to be adopted by civilian organizations and commercial organizations. Most major browsers (eg Internet Explorer, Chrome, Firefox, Safari) currently have a preference for DNT, but there is no agreement on how the recipient's website will support DNT.

[571] Nevertheless, providers are aware that DNT applies to tracking third-party websites rather than first-party websites. According to the draft W3C standard, when a first party receives a DNT:1 signal, the first party will perform normal information collection and data usage. This means that content, services and advertising can be customized in the context of the First Party Experience. Under the recommendation, first parties should not share network correlation data with third parties that could not collect the data themselves. However, the processed data may be shared by providers operating under the first party.

[572] In a non-tracking environment, when a user also visits a website (“Website 1”), the user's browser sends a notification to Website 1 that the user does not want to be tracked. Website 1 then sends the user's browser a first-party cookie and content, an address requesting that the browser display an advertisement on Website 1 from Ad Network 1 (“Ad Network 1”). The ad network 1 receives the request as not tracking and sends the ad content to the user's browser, but no third party cookie is placed on the user's browser. Advertisements are provided to users in a conventional targeting manner and include, but are not limited to, advertisements for page content. (Example: Content targeting) As described above, there is almost no consensus restriction on the first party depending on how the tracking refusal function is performed. (Except that the first party should not share DNT user network interactions with third parties who were unable to collect the data themselves)

[573] In contrast, the practice of the present invention is to protect the privacy and anonymity of related party users while delivering content and targeted advertising to maintain the original revenue model of the Internet. It is possible to execute the tracking refusal function. FIG. 23 illustrates a number of potential uses of the present invention in advertising distribution.

[574] In step 1 of Figure 23, by way of example, a Data Subject or related party is visiting Website 1 for the first time, and the browser is sending a deny tracking header to Website 1. If the Data Subject or related parties wish, the browser can send a TDR to Website 1, thus hiding the "status" information and improving the Data Subject or related party experience. I can. Website 1 sends content to the Data Subject or related party browsers.

[575] In step 2, by way of example, the Data Subject or related party browsers are requesting advertisements from Website 1 (with or without TDR) to Website 1. When no TDR is sent, the Data Subject or related party browser receives a conventional targeted advertisement based on the content of the page from Ad Network 1. When the TDR is sent, the advertising network 1 may send a high-dimensional targeting ad to the Data Subject or related party's browser based on content relevant to the Data Subject or related party. In this regard, TDR-based advertising by Ad Network 1 is a collection of profile information related to behavior collected by Ad Network 1 from traditional ads or Data Subjects or related parties (and therefore generally more reasoning). It is more relevant to the Data Subject or related parties.

[576] In step 3, by way of example, a process similar to steps 1 and 2 occurs when a Data Subject or related party visits a new website ("Website N"). If TDRs are included, website content and advertising content are targeted at a high level. However, at least Ad Network 1 cannot collect or track information from the Data Subject or related parties. In addition, through a privacy client or other mechanism within the browser, the TDR may hold the information sent to the website or advertising network 1.

[577] In summary, existing targeting advertising technology allows users to be tracked from anywhere online, and makes ads based on aggregated data that makes inferences about specific user preferences. In other words, there is no privacy or anonymity of users, only low/medium advertising relevance. The combination of the present invention and the elements of the tracking refusal function allow the user to select what kind of information is sent to which website or advertising network. This not only enhances privacy and anonymity, but also relevance of advertisements (for users), and at the same time improves actual sales volume and investment returns for sellers.

[578] Figures 24 and 25 illustrate potential advantages of embodiments of the present invention in the healthcare area. FIG. 24 shows a temporary execution example of one embodiment of the present invention for protecting confidentiality, privacy, and anonymity of users and patients such as personal identification information (PII) and personal insurance information (PHI) in a healthcare information system. It emphasizes the use of unique and purposeful data representations (TDRs). By utilizing the present invention, healthcare systems can generate real-time TDRs that do not reveal sensitive PII, PHI without losing the context or access to those information. In step 1.0, the information is received by the system as an input containing PII, PHI related to the registration process. In order to protect the privacy and anonymity of PII and PHI information, the output of the registration process is such that the user information [A] of PII and PHI is dynamically changed without revealing the information of PII and PHI. It consists of re-assignable DDIDs and PII, PHI information), so sensitive PII, PHI data will not be disclosed. This user data (including TDRs instead of PII, PHI information) is used as input to create, augment or replace the user data file at D1 without disclosing PII, PHI information [B]. Similarly, the PII and PHI information output from the reservation process in step 2.0 consists of TDRs (dynamically re-assignable DDIDs and PII and PHI information without revealing the PII and PHI information. Therefore, confidential PII and PHI data will not be disclosed. This medical data (including TDRs instead of PII, PHI information) is used as input to generate, augment or replace the medical data file at D2 without disclosing PII, PHI information [C]. The medical data from D2 (after going through the medical information retrieval process of step 3.0) is combined with the user data file from D1 as input in step 4.0 of the user profile retrieval. At this time, PII and PHI information will not be disclosed by connecting and using only temporary unique and limited purpose data representations (TDRs). The PII and PHI user information that constitutes the elements of the output generated in the user profile search in step 4.0 can be obtained from TDRs (dynamically changing and reassignable DDIDs and PII and PHI information without disclosing PII and PHI information). Configured) and therefore sensitive PII, PHI data will not be disclosed. Finally, at D1, user data (including TDRs instead of PII, PHI information) is used as input in step 5.0 of the Scheduled Record Browse process. At this time, PII and PHI information will not be disclosed by connecting and using only temporary unique and limited purpose data representations (TDRs). Confidential PII, PHI related to applicable TDRs and DDIDs, when access to detailed information from user data files, medical data files is required for purposes of authorized healthcare or unsolicited services. Related keys (AKs) and replacement keys (RKs) are used to identify the data.

[579] Figure 25 shows that dynamically reassignable TDRs (consisting of dynamically changing and reassignable DDIDs and PII, PHI information) are included in the patient's medical record for PII, PHI. It shows examples used to protect privacy and anonymity. FIG. 25 shows how the present invention can be implemented with multiple levels of abstraction, providing a “privacy ring” only at the level of the personally identifiable information required to provide the desired service or authorized functionality. Has been shown to be done. In this example, each provider at the local, national level receives the relevant combination suitable for their respective permitted purposes. Temporary, unique and limited data representations (TDRs) can be used to protect the privacy, privacy and anonymity of users, patients' personally identifiable information (PII) and personal insurance information (PHI). By utilizing the present invention, healthcare-related information can use TDRs that do not reveal sensitive PII, PHI, and never lose the context or access to those information. At each successive level (from the lower provider level to the upper national level) PII, PHI information is replaced with TDRs (consisting of dynamically changing and reassignable DDIDs and PII, PHI information) However, PII and PHI information will not be disclosed because it is represented by temporary unique and limited data representations (TDRs). At a particular stage, when access to PII, PHI information is required for authorized use, the relevant key must be used to identify sensitive PII, PHI data associated with applicable TDRs and DDIDs. (AKs) and replacement keys (RKs) are used. In addition, because DDIDs change over time and the information associated with new DDIDs can reflect additional information without disclosing the Data Subject or patient specificity, DDIDs can be used for horizontal learning. Self-regulation can be assisted to improve This is possible by using DDIDs to separate “context” and “meta” from the data needed to perform the analysis. There are multiple players in the healthcare area, many using different data structures. Dynamic Anonymity dynamically allocates, reallocates and tracks DDIDs to enable effective investigation and analysis without disclosing specific information, collecting disparate data in different formats from different sources, Standardize information into a common structure and help separate “context” and “meta”. Using this methodology, it is not possible to identify an individual from this process, so it is possible to concatenate Data Subjects or single data about a patient from different sources without having to worry about getting consensus. Become. Only within the circle of credit (“CoT”) shown in FIG. 1C-1, personal identification information is accessible by access to a mapping engine that associates the information with the individual. With proper management and regulation, trusted parties, proxies, can offer control via a circle of credit (“CoT”) to match the differences between personally identifiable information and functionality information. For example, in the current health care and life sciences research areas, there is a "minimization of data" attempt to ensure that only minimal personally identifiable information is used for research, because of the risk of reidentification of individuals. Has been done. Dynamic Anonymity can significantly reduce the regulatory burden of strengthening legislation, the corporate burden of review and development associated with privacy and anonymity. At the same time, it will enable access to a more complete data set for healthcare related research and development. HIPAA uses a fourth methodology to anonymize personal insurance information (PHI). Once anonymized, PHI can be used for any purpose without being restricted by HIPAA. However, existing HIPAA anonymization methodologies have concerns, lack of legal reliance on reauthorization of unauthorized anonymous data, and lack of public transparency in the use of anonymous data. Can be mentioned. Furthermore, the final rules of the US HIPAA and HITECH Act, which became effective as of September 22, 2014, have made the business partners directly responsible for HIPAA compliance in addition to the applicable entities. The present invention provides a means for ensuring the anonymity of information subject to HIPAA without compromising the value of the information. By utilizing the present invention, most data can be made to comply with HIPAA compliance.

[580] Figure 26 illustrates potential advantages of embodiments of the present invention in mobile, wearable, portable device communications of the present invention. The mobile, wearable, and portable system-executed applications shown here can provide a control entity that manages the timing and level of participation of the application depending on location and time. The control entity may use the capabilities of the privacy server's abstract module to control the degree to which attribute combinations are shared with third parties, which in turn may provide some degree of anonymity or personality. .. For example, the static identifiers associated with mobile, wearable, and portable devices in existing systems include attribute combination data that accompanies the use of mobile, wearable, and portable devices, mobile, wearable, portable application providers, and other third parties. Allows you to aggregate. Utilization of the present invention may prevent application providers and other third parties from aggregating attribute combinations that accompany mobile, wearable, and portable device use. In addition, by using TDRs and DDIDs rather than static identifiers, mobile, wearable, and portable devices can access geographic information (eg, directions and maps) without identifying the mobile, wearable, or portable device or user. It may also be possible to use mobile applications that require applications).

[581] FIG. 27 is an example of a simplified functional block diagram depicting a programmable device 2700 in accordance with the performance of one or more processes, methods, steps, features or elements described herein. Programmable device 2700 may include one or more electrical circuit communications 2710, memory 2720, storage device 2730, processor 2740, control-based interface 2750, display 2760 and communication bus 2770. Processor 2740 is a suitable programmable control device or other processing unit and is believed to manage the operation of many functions performed by programmable device 2700. Processor 2740 is believed to display display 2760 and receive control-based input from control-based interface 2750. The embedded processor provides a versatile and stable programmable control device that can be utilized to implement the techniques according to the present invention.

[582] Storage device 2730 may store a combination of attributes, software (eg, for performing various functions on device 2700), selection information, device profile information, and other suitable data. The storage device 2730 holds one or more recording media for tangibly recorded data and program instructions, such as a hard drive, solid state memory, permanent memory such as ROM, semi-permanent memory such as RAM, or cache. Think of it. The program instructions may consist of executing software encoded in a preferred computer programming language.

[583] The memory 2720 includes one or more different types of recording modules used to perform the functions of the device. For example, memory 2720 includes cache, ROM, and RAM. The communication bus 2770 provides a data transfer path for transferring data between at least the memory 2720, the storage device 2730, and the processor 2740.

[584] Although referred to as a bus, the communication bus 2770 is not limited to a particular data transfer technology. The control subject interface 2750 enables communication between the control subject and the programmable device 2700. For example, the control-based interface 2750 can take various forms such as buttons, keypads, dials, click wheels, mice, touch screens and voice command screens, other output formats and user interfaces.

[585] As one example, programmable device 2700 can also be a programmable device capable of processing data. For example, the programmable device 2600 is an identifiable device (excluding smartphones, tablets, notebooks, desktop computers) that can communicate with and embed sensors, an identification device or a machine-readable device (“smart device”), a smartphone. , Tablets, notebooks, desktop computers and other personal devices.

[586] Figure 28 is an example of a block diagram depicting a network device system 2800 in accordance with implementations of one or more processes, methods, steps, features or elements described herein. The privacy client described above may be implemented, for example, on a smart device (eg, wearable, mobile, stationary smart device) 2810, smartphone 2820, tablet 2830, notebook 2840, desktop computer 2850. Each of these devices is connected to the privacy server 2870 by one or more networks 2860, which may include time keys (TKs) or association keys (AKs), replacement keys (RKs), and information about their associated attribute combinations. Concatenated with database 2880 to store information, TDRs, Data Subjects, aggregated Data Subject profiles, timestamps. Database 2880 is a structured database, any preferred form of record data, including unstructured flat files. The Privacy Server 2870 also provides information about attribute combinations, TDRs, Data Subjects, aggregated Data Subject profiles, and remote storage for time stamps, which are Time Keys (TKs) or Federation Keys (AKs). , Replacement keys (RKs), and their associated devices, on device 2810, 2820, 2830, 2840, 2850, and also on database 2880 or on a suitable device in another database (not shown). It is done by the information being sent to the privacy client.

[587] Although FIG. 28 shows a single network 2860, the network 2860 can also be multiple interconnected networks, and the privacy server 2870 is for privacy clients on devices 2810, 2820, 2830, 2840, 2850, Alternatively, it may be connected via another network 2860 to privacy clients on other suitable devices. Network 2860 can be any type of network, from local areas to wide area or global Internet.

[588] By implementing the present invention, privacy and security applications are not limited to various industries, environments and technologies, but also online processing, healthcare, education, card payment and processing, information security, transportation, supply chain management. It can also be provided in manufacturing source planning, location information, mobile or cellular systems, energy and smart grid technologies, the Internet, defense and intelligence technologies or programs.

[589] When used in an online processing environment, the practice of the present invention allows a consumer to control the collection of his or her own data, allowing the controller of the data to be accessible to third parties involved in data communication and diffusion. It is possible to make sure that only the information necessary to provide a particular function is received. The resulting increased consumer confidence continues to be satisfied with the benefits of the “Internet of Things” and, as noted above, does not revoke the rights of the target or related parties and keeps the operator under regulation. Can be kept.

[590] In the healthcare area, embodiments of the present invention may maintain the effectiveness of existing healthcare regulations by improving anonymity. In addition, embodiments of the present invention improve the likelihood that patients may be concerned about a survey resulting from increased data confidentiality protection, allowing consumers and society to work together in healthcare. Enjoy the benefits of big data analytics.

[591] As another illustration, when used in an educational setting, embodiments of the present invention provide educators and administrators with tools to access categorical data related to students, and to provide students with privacy and anonymity. The system of students as individuals and schools as a group can benefit from more sophisticated data analysis without infringing on their rights.

[592] In an example of the present invention in the setting of national security, a national security organization of the government may record a limited number of calls aggregated by each telecommunications user without obtaining personally identifiable information. Can be analyzed. For example, the calling time,'outgoing' receiving' number, calling time,'outgoing' receiving' postal code can be obtained without disclosing the calling or receiving telephone number and the personal information associated with it. is there. In this example, the security organization analyzes the limited call logs to issue certificates and other judicial approvals at any point to gain additional detailed call logs in the event of suspicious activity. You can decide whether to do it. In this way, the embodiment of the present invention is effective for the interest of national security, and at the same time, the privacy and anonymity of the caller can be ensured until the judicial decision requires additional detailed disclosure.

[593] Example

[594] The following example is a description relating to further embodiments. Example 1 is a system with the following configurations: A communication interface for transmitting data over a network, an embedded memory having computer program code, and one or more process units connected to the memory and configured to execute instructions of the computer program code. The program code causes one or more process units to generate a dynamically changing temporary unique identifier to network the first request generated by the first client for specific information related to the first data object. Generates data for the first time unit, which consists of information defining the first time unit, while the first generated identifier is used to identify the first data object, and the memory The first generated identifier and the data of the first time unit are stored in and the first generated identifier is transmitted to the first client through the network.

[595] Example 2 encompasses the subject matter of Example 1, where computer program code instructions associate one or more process units with one or more data attributes with an initially generated identifier.

[596] Example 3 encompasses the subject matter of Example 2, where at least one of the one or more data attributes associated with the initially generated identifier is at least one of the action, the process, the purpose, and the first. It is related to the characteristics of the data object.

[597] Example 4 encompasses the subject matter of Example 3, with the instructions of the computer program code causing one or more process units to perform the following operations. During the first time unit, a second request for at least one of the one or more data attributes associated with the first generated identifier was received from the second client on the network and the second request was received. And granting the right on the network to allow the second client to determine the requested one or more data attributes associated with the identifier originally generated during the first time period.

[598] Example 5 encompasses the subject matter of Example 1, where one or more process units, at the direction of computer program code, may assign one or more data attributes during a first or second time period. Correlate with the second data subject.

[599] Example 6 encompasses the subject matter of the examples, where one or more process units perform the following operations, under the direction of computer program code. In response to the first request, in conjunction with the second generated identifier with the first data subject, while the second generated identifier is used to define the first data subject, the second Create a second time unit data composed of the second time unit data including information defining the time zone of, and store the second generated identifier and the second time unit data in the memory, Then, the second generated identifier is transmitted to the first client through the network.

[600] Example 7 embraces the subject matter of Example 6 in which, under the direction of computer program code, one or more process units associate one or more data attributes with a second generated identifier, where At least one of the one or more data attributes associated with the second generated identifier is associated with the behavior, process, purpose, and characteristics of the first data object.

[601] Example 8 encompasses the subject matter of Example 7, where at least one of the one or more data attributes associated with the first generated identifier is the one associated with the second generated identifier. It differs from at least one of the above data attributes.

[602] Example 9 encompasses the subject matter of Example 3 and, at the direction of the computer program code, causes one or more process units to generate a second identifier for the first generated identifier during a second time period. At least one of the one or more data attributes associated with the data subject, where the first generated identifier in the first time zone, is associated with the first generated identifier in the second time zone. Similar to at least one of one or more data attributes.

[603] Example 10 encompasses the subject matter of Example 1, with the instructions of the computer program code causing one or more process units to perform the following operations. To receive the second identifier associated with the second data subject from the second client on the network, associate the second identifier with the second data subject, and the second identifier defines the second data subject. While being used to create a second time unit data consisting of second time unit data containing information defining the second time zone, the second identifier and the second time in memory. Save unit data.

[604] Example 11 encompasses the subject matter of Example 4, where the computer program code causes one or more process units to associate with one or more identifiers originally generated during the requested second time zone. Revokes on the network the right that the second client determines the data attribute of.

[605] Example 12 is a permanent computer-readable medium comprised of computer-executable stored instructions in which one or more process units perform the following operations. Generates a dynamically changing temporary unique identifier, receives the first request from the first client for the generated identifier associated with the first data object on the network, and in response to the first request, first Associated with the first generated identifier with the data subject of the first, and the first generated specific identifier is used to define the first data subject, while containing the information defining the first time zone. Create the first hourly data consisting of the hourly data, store the first generated identifier and the first hourly data in memory, and send the first generated identifier to the first client through the network To do.

[606] Example 13 encompasses the subject matter of Example 12, with the instructions of the computer program code causing one or more process units to associate one or more data attributes with an initial identifier.

[607] Example 14 covers the subject matter of Example 13, where at least one of the one or more data attributes associated with the first identifier relates to a behavior, operation, purpose, or characteristic of the first data object. doing.

[608] Example 15 encompasses the subject matter of Example 14, with the instructions of the computer program code causing one or more process units to perform the following operations. During the first time unit, a second request for at least one of the one or more data attributes associated with the first generated identifier was received from the second client on the network and the second request was received. And granting the right on the network to allow the second client to determine the requested one or more data attributes associated with the identifier originally generated during the first time period.

[609] Example 16 encompasses the subject matter of Example 12 and, at the direction of the computer program code, causes the one or more process units to initially generate an identifier as a second data subject at a second time of day. Associate.

[610] Example 17 encompasses the subject matter of Example 12, where one or more process units associates a first generated identifier with a second data subject at a first time of the day, as directed by the computer program code. ..

[611] Example 18 encompasses the subject matter of Example 12, where one or more process units perform the following operations, under the direction of computer program code: In response to the first request, in conjunction with the second generated identifier with the first data subject, while the second generated identifier is used to define the first data subject, the second Create a second time unit data composed of the second time unit data including information defining the time zone of, and store the second generated identifier and the second time unit data in the memory, Then, the second generated identifier is transmitted to the first client through the network.

[612] Example 19 encompasses the subject matter of Example 18, where the first time zone and the second time zone do not overlap.

[613] Example 20 encompasses the subject matter of Example 18, where the first and second time zones partially overlap.

[614] Example 21 encompasses the subject matter of Example 18, in which one or more process units associates one or more data attributes with a second identifier at the direction of computer program code, where At least one of the one or more data attributes associated with the second identifier is associated with the operation, the process, the purpose, and the characteristics of the first data object.

[615] Example 22 encompasses the subject matter of Example 21, where at least one of the one or more data attributes associated with the first generated identifier is the one associated with the second generated identifier. It differs from at least one of the above data attributes.

[616] Example 23 encompasses the subject matter of Example 14, in which, at the instruction of the computer program code, one or more process units at the second time of day assign a second identifier to the first generated identifier. Associated with the data subject, wherein at least one of the one or more data attributes associated with the identifier originally generated during the first time zone is associated with the identifier initially generated during the second time zone. The same as at least one of the one or more data attributes.

[617] Example 24 encompasses the subject matter of Example 12, with the instructions of the computer program code causing one or more process units to perform the following operations. To receive the second identifier associated with the second data subject from the second client on the network, associate the second identifier with the second data subject, and the second identifier defines the second data subject. While being used to create a second time unit data consisting of second time unit data containing information defining the second time zone, the second identifier and the second time in memory. Save unit data.

[618] Example 25 encompasses the subject matter of Example 24, with the second identifier encompassing the HTT cookie.

[619] Example 26 encompasses the subject matter of Example 12, with the instructions of the computer program code causing one or more process units to perform the following operations. For the identification of the first data subject associated with the first generated identifier in the first time zone, a second request is received on the network from a second client, deciding that the second request is authorized, The second client grants the right to determine the identity of the first data subject on the network during the first time period.

[620] Example 27 encompasses the subject matter of Example 26, in which computer program code allows one or more process units to establish the right of a second client to determine the identification of the first data subject on a network during a first time period. Cancel with.

[621] Example 28 encompasses the subject matter of Example 15, where the instructions in the computer program code cause one or more process units to be associated with an identifier originally generated in a second time zone, as requested. Revokes the right of a second client to determine one or more data attributes on the network.

[622] Example 29 encompasses the subject matter of Example 13, in which the first generated identifier is not mathematically derived from one or more data attributes associated with the first generated identifier. Absent.

[623] Example 30 encompasses the subject matter of Example 12, where the first generated identifier includes the primary identifier because of the second data subject.

[624] Example 31 is a system and includes the following configuration. A communication interface for transmitting data over a network, an embedded memory having computer program code, and one or more process units connected to the memory and configured to execute instructions of the computer program code. The program code causes one or more process units to generate a dynamically changing temporary unique identifier, associate the first temporary unique identifier with the first data subject, and set one or more data attributes. In conjunction with the first temporary unique identifier, the first temporary unique identifier is used to identify the first data object, and the first time while searching for one or more relevant data attributes. Generates the first hourly data consisting of information defining the unit, stores the first temporary unique identifier, one or more data attributes, the first hourly data in memory, and the first temporary A unique unique identifier over the network to the first client.

[625] Example 32 encompasses the subject matter of Example 31, wherein the instruction to generate the first temporary unique identifier is performed based on at least one of time, purpose, and location.

[626] Example 33 encompasses the subject matter of Example 31, in which one or more process units, at the direction of computer program code, identifies that the first temporary unique identifier identifies the first data subject. Ends the search for one or more data attributes.

[627] Example 34 encompasses the subject matter of Example 33, where an indication that the first temporary unique identifier identifies the first data subject and terminates the search for one or more associated data attributes. Is performed based on at least one of time, purpose and position.

[628] Example 35 encompasses the subject matter of Example 31, where at least one of the one or more data attributes associated with the first temporary unique identifier is the action, process, purpose, or first data object. Related to the characteristics of.

[629] Example 36 encompasses the subject matter of Example 31, where one or more process units, at the second time of day, direct the first temporary unique identifier to the second data at the direction of the computer program code. Coordinate with the subject.

[630] Example 37 encompasses the subject matter of Example 31, where one or more process units, at the first time of day, directs the first temporary unique identifier to the second data subject, as directed by the computer program code. To work with.

[631] Example 38 encompasses the subject matter of Example 31, where, at the direction of the computer program code, the identification of the first data subject associated with the first temporary unique identifier at the first time of day, The first request is received on the network from a second client, decides that the first request is authorized, and the second client grants the right on the network to determine the identification of the first data subject during the first time period. To do.

[632] Example 39 encompasses the subject matter of Example 38, where computer program code allows one or more process units the right of a second client to determine the identification of the first data subject in a first time zone. , Cancel on the network.

[633] Example 40 encompasses the subject matter of Example 31, where one or more data attributes associated with the first temporary unique identifier at the first time zone, as directed by the computer program code, Received the first request on the network from a second client, determined that the first request was authorized, and the second client was associated with the first temporary unique identifier requested during the first time period. Grants the right to determine the identity of one or more data attributes on the network.

[634] Example 41 encompasses the subject matter of Example 40 where computer program code causes one or more process units to request the first temporary unique identifier during the first time period. Revokes the right on the network that the second client determines the identification of one or more data attributes associated with.

[635] Example 42 encompasses the subject matter of Example 31, where the first temporary unique identifier is mathematically derived from one or more data attributes associated with the first temporary unique identifier. Not a thing.

[636] Example 43 encompasses the subject matter of Example 31, where the first temporary unique identifier comprises the primary identifier for identification of the first data subject.

[637] Example 44 is a permanent, computer-readable medium comprised of computer-executable stored instructions in which one or more process units perform the following operations. Generate a temporary unique identifier, associate the first temporary unique identifier with the first data subject, associate one or more data attributes with the first temporary unique identifier, and generate the first hourly data To do. There, the first temporary unique identifier is used to identify the first data subject, and the first time unit data identifies the first time zone while searching for one or more related data attributes. Construct the first time unit data that contains the defining information, store the first temporary unique identifier and one or more data attributes in memory, and the first time unit data, and store the first temporary unique identifier. Send one or more data attributes over the network to the first client.

[638] Example 45 encompasses the subject matter of Example 44, in which the instructions to generate the first temporary unique identifier are performed based on at least one factor of time, purpose, and location. It

[639] Example 46 encompasses the subject matter of Example 44, in which one or more process units, at the direction of computer program code, identifies that the first temporary unique identifier identifies the first data subject. Ends the search for one or more data attributes.

[640] Example 47 encompasses the subject matter of Example 46, where an indication that the first temporary unique identifier identifies the first data subject and terminates the search for one or more associated data attributes. Is performed based on at least one of time, purpose and position.

[641] Example 48 encompasses the subject matter of Example 44, where at least one of the one or more data attributes associated with the first temporary unique identifier is an action, a process, a purpose, and a first data object. Related to the characteristics of.

[642] Example 49 encompasses the subject matter of Example 44, where one or more process units, at the direction of a computer program code, causes the first temporary unique identifier to be duplicated during the second time period. Link to the second data subject.

[643] Example 50 encompasses the subject matter of Example 44, in which one or more process units, at the direction of the second time zone, assigns the first temporary unique identifier to the second data subject. To work with.

[644] Example 51 encompasses the subject matter of Example 44, where one or more process units perform the following operations, under the direction of computer program code: During the first time period, for the identification of the first data subject associated with the first temporary unique identifier, the first request is received from the second client on the network and it is determined that the first request is authorized, The second client grants the right over the network to determine the identification of the first data subject during the first time period.

[645] Example 52 encompasses the subject matter of Example 51, in which computer program code allows one or more process units to move during a first time zone and a second client to move during a first time zone. Revokes the right to determine the identity of the original data subject on the network.

[646] Example 53 encompasses the subject matter of Example 44, where one or more process units perform the following operations, as dictated by computer program code. During the first hour, the first request is received from a second client over the network to identify one or more data attributes associated with the first temporary unique identifier, and the first request is determined to be authorized. Then, the second client grants the right during the first time period on the network to determine the identification of one or more data attributes associated with the first temporary unique identifier requested.

[647] Example 54 encompasses the subject matter of Example 53, in which computer program code causes one or more process units to move during a first time zone and a second client to move during a first time zone. , Revokes the right to determine the identification of one or more data attributes associated with the requested first temporary unique identifier on the network.

[648] Example 55 encompasses the subject matter of Example 44, where the first temporary unique identifier is mathematically derived from one or more data attributes associated with the first temporary unique identifier. Not a thing.

[649] Example 56 encompasses the subject matter of Example 44, where the first temporary unique identifier comprises the primary identifier for the first data subject.

[650] Example 57 is a device and includes the following configurations. A communication interface for transmitting data over a network, an embedded memory having computer program code, and one or more process units connected to the memory and configured to execute instructions of the computer program code. The program code causes one or more process units to request a temporary unique identifier on the network from a privacy server and to coordinate the first temporary unique identifier with the first data subject that is the user of the device. Combine one or more data attributes with the first temporary unique identifier to generate the first hourly data. There, the first temporary unique identifier is used to identify the first data object, and while searching for one or more related data attributes, the first time unit data identifies the first time unit. Configure the information to define, store in memory the first temporary unique identifier, one or more data attributes, the data for the first time unit, and respond to the determination that the first condition was met. And sends the first temporary unique identifier, the first time unit data, and one or more data attributes to the first client over the network.

[651] Example 58 encompasses the subject matter of Example 57, where the determination that the first condition was met includes at least one of the following: A predetermined amount of time has passed, a flexible amount of time has passed, the purpose of the first temporary unique identifier has been defeated, or the location of the first data subject has changed.

[652] Example 59 encompasses the subject matter of Example 57, where one or more process units, at the direction of computer program code, determines that one or more data attributes associated with the first temporary unique identifier. Fix it.

[653] Example 60 encompasses the subject matter of Example 57, where one or more process units track the use of temporary unique identifiers, as directed by computer program code.

[654] Example 61 encompasses the subject matter of Example 57, where one or more process units, under the direction of computer program code, determine that a temporary unique identifier determines the identification of the first data subject. Revokes the right to retrieve one or more of the above related data attributes on the network.

[655] Example 62 encompasses the subject matter of Example 57, where the device resides on the same computing device as the privacy server.

[656] Example 63 encompasses the subject matter of Example 57, in which computer program code directs one or more process units to respond to a change in a temporary unique identifier with the first time unit data. Or, one or more data attributes, or at least one of the first temporary unique identifier, the first hourly data, and one or more data attributes registered on the network to sync with the device to the First Privacy Server. Send to one or more client devices.

[657] Example 64 encompasses the subject matter of Example 57, where the first temporary unique identifier, the first hourly data, and one or more data attributes are sent to the first privacy server on the network for the HTTP cookie. Sent in the format.

[658] Example 65 encompasses the subject matter of Example 57, where the first temporary unique identifier is mathematically derived from one or more data attributes associated with the first temporary unique identifier. Not a thing.

[659] Example 66 encompasses the subject matter of Example 57, where the temporary unique identifier comprises the primary identifier for the first data subject.

[660] Example 67 is a permanent, computer-readable medium comprised of computer-executable stored instructions in which one or more process units perform the following operations. Request a temporary unique identifier from the privacy server on the network, associate the first temporary unique identifier with the first data subject that is the user of the first client device, and add one or more data attributes to the first temporary unique identifier. Generates data for the first time unit in cooperation with the unique identifier. There, the first temporary unique identifier is used to identify the first data object, and while searching for one or more related data attributes, the first time unit data identifies the first time unit. Constructs the defining information, stores the first temporary unique identifier, one or more data attributes, the first hourly data in the memory of the first client device, and it is determined that the first condition is met. Correspondingly, the first temporary unique identifier, the first time unit data, and one or more data attributes are sent to the Firth Privacy Server over the network.

[661] Example 68 encompasses the subject matter of Example 67, where the determination that the first condition was met includes at least one of the following: A predetermined amount of time has passed, a flexible amount of time has passed, the purpose of the first temporary unique identifier has been defeated, or the location of the first data subject has changed.

[662] Example 69 encompasses the subject matter of Example 67, where one or more process units, at the direction of computer program code, determines one or more data attributes associated with the first temporary unique identifier. Fix it.

[663] Example 70 encompasses the subject matter of Example 67, in which computer program code directs one or more process units to track the use of an initial temporary unique identifier.

[664] Example 71 encompasses the subject matter of Example 67, where one or more process units, under the direction of computer program code, determine that a temporary unique identifier determines the identification of the first data subject. Revokes the right to retrieve one or more of the relevant data attributes above.

[665] Example 72 encompasses the subject matter of Example 67, where the first client device resides on the same computing device as the privacy server.

[666] Example 73 encompasses the subject matter of Example 67, in which one or more process units, at the direction of computer program code, is subject to a change in the first hourly data in response to a temporary unique identifier change. Or, one or more data attributes, or at least one of the first temporary unique identifier, the first hourly data, and one or more data attributes registered on the network to sync with the device to the First Privacy Server. Send to one or more client devices. .

[667] Example 74 encompasses the subject matter of Example 67, where the first temporary unique identifier, the first hourly data, and one or more data attributes are sent to the first privacy server on the network for the HTTP cookie. Sent in the format.

[668] Example 75 encompasses the subject matter of Example 67, where the first temporary unique identifier is mathematically derived from one or more data attributes associated with the first temporary unique identifier. Not a thing.

[669] Example 76 encompasses the subject matter of Example 67, where the temporary unique identifier includes the primary identifier for the first data subject.

[670] Example 77 is a device, which includes the following configurations. A communication interface for transmitting data over a network, an embedded memory having computer program code, and one or more process units connected to the memory and configured to execute instructions of the computer program code. Depending on its program code, one or more process units take the following actions: Obtaining the first temporary unique identifier from the First Privacy Server on the network, where the first temporary unique identifier is the first data subject on the First Privacy Server that is the user of the device at the first privacy server. It is linked. Next, one or more data attributes are associated with the first temporary unique identifier to generate the first hourly data. There, the first temporary unique identifier is used to identify the first data object, and while searching for one or more related data attributes, the first time unit data identifies the first time unit. Configure the information you define. The first temporary unique identifier, one or more data attributes, and the first time unit data are stored in the memory, and the first temporary unique identifier, the first time unit data, and one or more data attributes are networked. Send to First Privacy Server above. Then, a second temporary unique identifier is received on the network from the first privacy server, where the second temporary unique identifier is the first data subject at the first privacy server at the second time zone, Associated with one or more data attributes.

[671] Example 78 encompasses the subject matter of Example 77, where instructions for computer program code cause one or more process units to receive a second temporary unique identifier from a First Privacy Server on the network. Is executed according to the determination that the first condition is satisfied.

[672] Example 79 encompasses the subject matter of Example 78 and the determination that the first condition was met includes at least one of the following: A predetermined amount of time has passed, a flexible amount of time has passed, the purpose of the first temporary unique identifier has been defeated, or the location of the first data subject has been compromised.

[673] Example 80 encompasses the subject matter of Example 77, where computer program code directs one or more process units to identify one or more data attributes associated with the first temporary unique identifier. Fix it.

[674] Example 81 encompasses the subject matter of Example 77, in which computer program code directs one or more process units to track the use of the first temporary unique identifier.

[675] Example 82 encompasses the subject matter of Example 77, where one or more process units, under the direction of computer program code, determine that a temporary unique identifier determines the identity of the first data subject. Revokes the right to retrieve one or more of the relevant data attributes above.

[676] Example 83 encompasses the subject matter of Example 77, in which one or more process units are instructed by the computer program code to retrieve the first data subject or one or more data attributes from the first privacy server. Upon receiving approval that the First Privacy Server may disclose the identity of the first data subject or one or more data attributes to the first requester, requesting approval as to whether the identity will be revealed to the first requester. Accordingly, the identification of the first data subject or one or more data attributes is sent to the first requestor.

[677] Example 84 encompasses the subject matter of Example 83, in which the authorization request is also the first data subject or one or more data attributes for a particular action, activity, process or characteristic. Includes the required approval that the identity of the may be disclosed to the original requester.

[678] Example 85 encompasses the subject matter of Example 83, wherein the authorization request further discloses the identification of the first data subject or one or more data attributes to the first requestor at a particular time or location. It includes the required approval to do so.

[679] Example 86 encompasses the subject matter of Example 84, where the authorization request further identifies the first data subject or identification of one or more data attributes for a particular action, activity, process, or customization. Includes the required approval to be disclosed to the requester of the.

[680] Example 87 is a system and includes the following configuration. A communication interface for transmitting data over a network, an embedded memory having computer program code, and one or more process units connected to the memory and configured to execute instructions of the computer program code. The program code causes one or more process units to generate a dynamically changing temporary unique identifier, such that the generated dynamically changing temporary unique identifier is associated with the attribute of the first data subject. In addition, the first request from the first data subject is received on the network and, in response to the first request, the first dynamically generated temporary unique identifier is associated with the attributes of the first data subject. , Convert the value of a dynamically changing temporary unique identifier into the first unreadable form. In this regard, the first key is used to revert the first unreadable form back to the first view of the initially generated dynamically changing temporary unique identifier, and the second key is the first unreadable form. Used to transform the format into a second view of the first dynamically generated temporary unique identifier generated, where the first key is different from the second key and the first view is different from the second view Is. It then stores the first dynamically generated temporary unique identifier generated in memory, the first key, the second key, the first unreadable form, and through the first unreadable network to the first data subject. Send.

[681] Example 88 encompasses the subject matter of Example 87, where First View provides more detail than Second View.

[682] Example 89 encompasses the subject matter of Example 87, where the unreadable form includes encrypted text.

[683] Example 90 encompasses the subject matter of Example 87, in which one or more process units, at the direction of computer program code, is responsible for generating a dynamically generated, temporary, unique identifier. It also links with the second data subject.

[684] Example 91 encompasses the subject matter of Example 90, in which one or more process units, at the direction of computer program code, is responsible for generating a dynamically generated, temporary, unique identifier. Instructions of the computer program code to be associated with the second data subject attribute are implemented in at least one of the following situations. The first generated dynamically changing temporary unique identifier is associated with the attribute of the first data subject, which is at a different time than when the dynamically changing temporary unique identifier was associated with the first data subject. It is a real or virtual point that is different from the time when it was created, or the purpose is that the dynamically generated temporary unique identifier that was initially created is associated with the original data subject.

[685] Example 92 encompasses the subject matter of Example 87, in which one or more process units, at the direction of computer program code, is generated by a second, dynamically changing, temporary unique identifier. To the first data subject attribute.

[686] Example 93 encompasses the subject matter of Example 92, in which one or more process units have a second, dynamically changing, temporary unique identifier for the first data subject's attribute. The instructions of the computer program code to be linked with are executed in at least one of the following situations. The first generated dynamically changing temporary unique identifier is the attribute of the first data subject, at a time different from the time when the dynamically changing temporary unique identifier is associated with the attribute of the first data subject. It is a different real or virtual point than when it was associated with, or the first dynamically generated temporary unique identifier is for a different purpose than the one associated with the first data subject attribute.

[687] Example 94 is a permanent computer-readable medium comprised of computer-executable stored instructions in which one or more process units perform the following operations. One or more process units generate a dynamically changing temporary unique identifier, so that the generated dynamically changing temporary unique identifier is associated with the attribute of the first data subject. Receives the first request from the principal on the network and, in response to the first request, dynamically changes the temporary unique unique identifier generated first by coordinating with the attributes of the first data subject. Convert the value of the temporary unique identifier to the first unreadable form. In this regard, the first key is used to revert the first unreadable form back to the first view of the initially generated dynamically changing temporary unique identifier, and the second key is the first unreadable form. Used to transform the format into a second view of the first dynamically generated temporary unique identifier generated, where the first key is different from the second key and the first view is different from the second view Is. It then stores the first dynamically generated temporary unique identifier generated in memory, the first key, the second key, the first unreadable form, and through the first unreadable network to the first data subject. Send.

[688] Example 95 encompasses the subject matter of Example 94, where first view provides more detail than second view.

[689] Example 96 encompasses the subject matter of Example 94, with the unreadable form containing plaintext.

[690] Example 97 encompasses the subject matter of Example 94, in which the instructions further include a dynamically generated temporary unique identifier that was initially generated by one or more process units and a second data item. It contains instructions for linking with the subject's attributes.

[691] Example 98 encompasses the subject matter of Example 97, where one or more process units are responsible for generating a dynamically generated temporary unique identifier for the first attribute of a second data subject. The instructions of the computer program code to be linked with are executed in at least one of the following situations. The first generated dynamically changing temporary unique identifier is associated with the attribute of the first data subject, which is at a different time than when the dynamically changing temporary unique identifier was associated with the first data subject. It is a real or virtual point that is different from the time when it was created, or the purpose is that the dynamically generated temporary unique identifier that was initially created is associated with the original data subject.

[692] Example 99 encompasses the subject matter of Example 94, where the instructions further include a second generated dynamically changing temporary unique identifier for the first data in one or more process units. It contains instructions for linking with the subject's attributes.

[693] Example 100 encompasses the subject matter of Example 99, where one or more process units have a second, dynamically changing, temporary, unique identifier for the first data subject attribute. The instructions of the computer program code to be linked with are executed in at least one of the following situations. The first generated dynamically changing temporary unique identifier is at a time different from the time when the first data subject was associated with the first data subject, and the first generated dynamically changing temporary unique identifier is the first data. It is a real or virtual point that is different from when it is associated with the subject's attribute, or the dynamically generated temporary unique identifier that was originally created has a different purpose from that associated with the first data subject.

[694] Example 101 is a configuration of a computer-implemented approach that generates one or more dynamically changing temporary unique identifiers, the generated dynamically changing temporary unique identifier being the first. As associated with the data subject's attributes, the first request from the first data subject is received on the network, and in response to the first request, the first generated dynamically changing temporary unique identifier is first sent. Converts the value of a dynamically changing temporary unique identifier into the first unreadable form in cooperation with the data-based attributes of. In this regard, the first key is used to revert the first unreadable form back to the first view of the initially generated dynamically changing temporary unique identifier, and the second key is the first unreadable form. Used to transform the format into a second view of the first dynamically generated temporary unique identifier generated, where the first key is different from the second key and the first view is different from the second view Is. It then stores the first dynamically generated temporary unique identifier generated in memory, the first key, the second key, the first unreadable form, and through the first unreadable network to the first data subject. Send.

[695] Example 102 encompasses the subject matter of Example 101, where the first view provides more detail than the second view.

[696] Example 103 encompasses the subject matter of Example 101, where the instructions further associate the first generated dynamically varying temporary unique identifier with the attribute of the second data subject. Contains instructions.

[697] Example 104 Covers the subject matter of Rei 103, where the act of associating a first generated, dynamically changing, temporary unique identifier with an attribute of a second data subject is at least Will be implemented in either situation. The first generated dynamically changing temporary unique identifier is at a time different from the time when the first data subject was associated with the first data subject. The first generated dynamically changing temporary unique identifier is the first data. It is a real or virtual point that is different from when it is associated with the attribute of the subject, or the dynamically generated temporary unique identifier that is initially generated has a different purpose from that associated with the first data subject.

[698] Example 105 encompasses the subject matter of Example 101 and further includes associating a second generated dynamically changing temporary unique identifier with the first data subject.

[699] Example 106 encompasses the subject matter of Example 105, in which the act of associating a second generated, dynamically changing, temporary unique identifier with an attribute of the first data subject is at least Will be implemented in either situation. The first generated dynamically changing temporary unique identifier is at a time different from the time when the first data subject was associated with the first data subject, and the first generated dynamically changing temporary unique identifier is the first data. It is a real or virtual point that is different from when it is associated with the subject's attribute, or the dynamically generated temporary unique identifier that was originally created has a different purpose from that associated with the first data subject.

[700] Example 107 is a system and includes the following configurations. A communication interface for sending data over a network, an embedded memory with computer program code, one or more data sources, and one or more process units connected to the memory and configured to execute the instructions of the computer program code. is there. The program code causes one or more process units to obtain data from one or more data sources that are attached to the majority of data subjects and dynamically change because of the first data subject of the multiple data subjects. To generate a temporary unique identifier. In that regard, of the one or more data sources, the first data subject is the first data subject in each of the first and second data sources. Then, one or more dynamically changing temporary unique identifiers are generated corresponding to the one or more similar identifiers, and in that respect, each similar identifier has a value. Then, a first request for one or more similar identifier values in the first data source is received on the network and a second request for one or more similar identifier values in the second data source is received. Converts the value received on the first request on the network into one or more fourth dynamically changing temporary unique identifiers, and converts the value obtained on the second request into one Convert to the fourth dynamically changing temporary unique identifier described above. And a first dynamically changing temporary unique identifier, a second dynamically changing temporary unique identifier, one or more third dynamically changing temporary unique identifiers, one or more A fourth dynamically changing temporary unique identifier of the first, dynamically changing temporary unique identifier, a second dynamically changing temporary unique identifier, one The above third dynamically changing temporary unique identifier and one or more fourth dynamically changing temporary unique identifier are transmitted on the network.

[701] Example 108 encompasses the subject matter of Example 107, in which the first dynamically changing temporary unique identifier includes the Replacement DDID (R-DDID).

[702] Example 109 encompasses the subject matter of Example 108, in which one or more third dynamically changing temporary unique identifiers include Association DDIDs (A-DDIDs).

[703] Example 110 encompasses the subject matter of Example 107, where R-DDID contains a particular value.

[704] Example 111 encompasses the subject matter of Example 107, where A-DDID contains a particular value.

[705] Example 112 encompasses the subject matter of Example 109, where one or more process units use the primary key to convert an R-DDID into a first view of R-DDID, and The second key is used to convert the DDID to the second view of the R-DDID, in which the first key is different from the second key.

[706] Example 113 encompasses the subject matter of Example 109, in which one or more process units use a third key to convert the first A-DDID into a third view of the first A-DDID. Then, use the 4th key to convert the first A-DDID to the force view of the first A-DDID, in which the 3rd key is different from the 4th key and the 3rd view is different from the force view. Is.

[707] Example 114 encompasses the subject matter of Example 107, in which the first second dynamically changing temporary unique identifier has the same value in the first and second data sources. ..

[708] Example 115 encompasses the subject matter of Example 107, where at least one of the one or more third dynamically changing temporary unique identifiers includes the first unreadable form. I'm out.

[709] Example 116 encompasses the subject matter of Example 107, where at least one of the one or more fourth dynamically changing temporary unique identifiers is in the second unreadable form. Contains.

[710] Example 117 encompasses the subject matter of Example 115, in which the unreadable form includes encrypted data.

[711] Example 118 encompasses the subject matter of Example 116, where the first unreadable form contains encrypted data.

[712] Example 119 encompasses the subject matter of Example 107, where at least one of the one or more data sources includes a particular subset, population, or population of data subjects.

[713] Example 120 encompasses the subject matter of Example 107, where one or more data sources are attached to a particular variety of data subjects for a period of time.

[714] Example 121 encompasses the subject matter of Example 109, where at least one of the one or more A-DDIDs includes a discrete value or combination of discrete values.

[715] Example 122 encompasses the subject matter of Example 109, where at least one of the one or more A-DDIDs contains a scattered value or a combination of discrete values.

[716] Example 123 is a permanent computer-readable medium in which Example 94 is composed of computer-executable stored instructions, wherein one or more process units perform the following operations. Acquires data from each of one or more data sources that are attached to the majority of data subjects and generate the first dynamically changing temporary unique identifier for the first data subject of the multiple data subjects. .. Here, the first data subject of the one or more data sources has a first data subject in each of the first data source and the second data source. And generating one or more second dynamically changing temporary unique identifiers corresponding to one or more similar identifiers of each of the first and second data sources, where each The similar identifier has a value. Then, a first request for one or more similar identifier values in the first data source is received on the network and a second request for one or more similar identifier values in the second data source is received. Converts the value received on the first request on the network into one or more third dynamically changing temporary unique identifiers, and converts the value obtained on the second request into one Convert to the fourth dynamically changing temporary unique identifier described above. And a first dynamically changing temporary unique identifier, a second dynamically changing temporary unique identifier, one or more third dynamically changing temporary unique identifiers, one or more A fourth dynamically changing temporary unique identifier of the first, dynamically changing temporary unique identifier, a second dynamically changing temporary unique identifier, one The above third dynamically changing temporary unique identifier and one or more fourth dynamically changing temporary unique identifier are transmitted on the network.

[717] Example 124 encompasses the subject matter of Example 123, where the first dynamically changing temporary unique identifier includes the Replacement DDID (R-DDID).

[718] Example 125 encompasses the subject matter of Example 124, where one or more third dynamically changing temporary unique identifiers include an Association DDID (A-DDID).

[719] Example 126 encompasses the subject matter of Example 125, where R-DDID has a particular value.

[720] Example 127 encompasses the subject matter of Example 123, where A-DDID has a particular value.

[721] Example 128 encompasses the subject matter of Example 125, in which one or more process units use the primary key to convert an R-DDID into a first view of R-DDID The second key is used to convert the DDID to the second view of the R-DDID, in which the first key is different from the second key.

[722] Example 129 encompasses the subject matter of Example 125, in which one or more process units use a third key to convert the first A-DDID into a third view of the first A-DDID. Then, use the 4th key to convert the first A-DDID to the force view of the first A-DDID, in which the 3rd key is different from the 4th key and the 3rd view is different from the force view. Is.

[723] Example 130 encompasses the subject matter of Example 123, where the first second dynamically changing temporary unique identifier has the same value in the first and second data sources. have.

[724] Example 131 encompasses the subject matter of Example 123, wherein at least one of the one or more third dynamically changing temporary unique identifiers includes the first unreadable form. I'm out.

[725] Example 132 encompasses the subject matter of Example 123, in which at least one of the one or more fourth dynamically changing temporary unique identifiers is in the second unreadable form. Contains.

[726] Example 133 encompasses the subject matter of Example 131, where the first unreadable form includes encrypted data.

[727] Example 134 encompasses the subject matter of Example 132, where the first unreadable form includes encrypted data.

[728] Example 135 encompasses the subject matter of Example 123, where at least one of the one or more data sources includes a particular subset, population, or population of data subjects.

[729] Example 136 encompasses the subject matter of Example 123, where each of one or more data sources is associated with a particular variety of data subjects over a period of time.

[730] Example 137 encompasses the subject matter of Example 125, where at least one of the one or more A-DDIDs includes either a numerical grouping or a categorical assertive grouping.

[731] Example 138 encompasses the subject matter of Example 125, where at least one of the one or more A-DDIDs contains a discrete value or combination of discrete values.

[732] Example 139 is a configuration of a computer-implemented approach that captures data from each of one or more data sources and attaches to the first data subject majority, Because it is the first data subject, it creates the first dynamically changing temporary unique identifier. Here, the first data subject of the one or more data sources has a first data subject in each of the first data source and the second data source. And generating one or more second dynamically changing temporary unique identifiers corresponding to one or more similar identifiers of each of the first and second data sources, where each The similar identifier has a value. Then, a first request for one or more similar identifier values in the first data source is received on the network and a second request for one or more similar identifier values in the second data source is received. Converts the value received on the first request on the network into one or more third dynamically changing temporary unique identifiers, and converts the value obtained on the second request into one Convert to the fourth dynamically changing temporary unique identifier described above. And a first dynamically changing temporary unique identifier, a second dynamically changing temporary unique identifier, one or more third dynamically changing temporary unique identifiers, one or more A fourth dynamically changing temporary unique identifier of the first, dynamically changing temporary unique identifier, a second dynamically changing temporary unique identifier, one The above third dynamically changing temporary unique identifier and one or more fourth dynamically changing temporary unique identifier are transmitted on the network.

[733] Example 140 encompasses the subject matter of Example 139, where the first dynamically changing temporary unique identifier includes the Replacement DDID (R-DDID).

[734] Example 141 encompasses the subject matter of Example 140, wherein the one or more third dynamically changing temporary unique identifiers include an Association DDID (A-DDID).

[735] Example 142 encompasses the subject matter of Example 139, where R-DDID has a particular value.

[736] Example 143 encompasses the subject matter of Example 139, where A-DDID has a particular value.

[737] Example 144 covers the subject matter of Example 141, using the first key to convert the R-DDID to the first view of the R-DDID, and converting the R-DDID to the second view of the R-DDID. Including using the second key to do. Here, the first key is different from the second key.

[738] Example 145 encompasses the subject matter of Example 141, using a third key to convert the first A-DDID into a third view of the first A-DDID, and the first A-DDID to the first Includes the act of using the fourth key to convert A-DDID to Force View. Here, the third key is different from the fourth key and the third view is different from the force view

[739] Example 146 embraces the subject matter of Example 139, in which the first second dynamically changing temporary unique identifier has the same value in the first and second data sources. To have.

[740] Example 147 embraces the subject matter of Example 139, wherein at least one of the one or more third dynamically changing temporary unique identifiers includes the first unreadable form. I'm out.

[741] Example 148 encompasses the subject matter of Example 139, in which at least one of the one or more fourth dynamically changing temporary unique identifiers has a second unreadable form. Contains.

[742] Example 149 encompasses the subject matter of Example 147, where the first unreadable form includes encrypted data.

[743] Example 150 encompasses the subject matter of Example 148, where the first unreadable form encrypted data comprises encrypted data.

[744] Example 151 encompasses the subject matter of Example 139, where at least one of the one or more data sources includes a particular subset, population, or population of data subjects.

[745] Example 152 encompasses the subject matter of Example 139, where each of one or more data sources is associated with a particular variety of data subjects for a period of time.

[746] Example 153 encompasses the subject matter of Example 141, wherein at least one of the one or more A-DDIDs includes either a numerical grouping or a categorical assertive grouping.

[747] Example 154 encompasses the subject matter of Example 141, where at least one of the one or more A-DDIDs contains a discrete value or combination of discrete values.

[748] Example 155 is a system and includes the following configuration. A communication interface for sending data over a network, an embedded memory with computer program code, one or more data sources, and one or more process units connected to the memory and configured to execute the instructions of the computer program code. is there. The program code causes one or more process units to obtain a request from the first user as a countermeasure to the privacy policy, determine at least in part the first privacy policy based on the request, and the first of the data subject. Retrieve data from the first user associated with the first plurality of the first and generate the first dynamically varying temporary unique identifier (DDID) for the first plurality of the first data subject. Here, the dynamically changing temporary unique identifier is aggregated to replace the first value associated with the first data subject and to meet the determined first privacy policy. Then, the first dynamically changing temporary unique identifier is stored in one or more data storage devices, and the first request for the first value associated with the first data subject is received over the network, and the first If the first request is not authorized to receive the first value according to the privacy policy, the first dynamically changing temporary unique identifier is sent on the network in response to the first request, and the first If the first request is authorized to receive the first value according to the privacy policy, then send the first value over the network in response to the first request.

[749] Example 156 encompasses the subject matter of Example 155, where the first dynamically changing temporary unique identifier comprises a Replacement DDID (R-DDID).

[750] Example 157 encompasses the subject matter of Example 155, where the one or more third dynamically changing temporary unique identifiers include an Association DDID (A-DDID).

[751] Example 158 encompasses the subject matter of Example 156, where R-DDID has a particular value.

[752] Example 159 encompasses the subject matter of Example 157, where A-DDID has a particular value.

[753] Example 160 encompasses the subject matter of Example 159, where a particular value includes a class, a subset, a range of values that replaces the first value.

[754] Example 161 covers the subject matter of Example 155, where a request for privacy policy action from the first user, data relating to the first pluralities of data subjects, and a first value for the first value. At least one of the requests is received via the shim.

[755] Example 162 encompasses the subject matter of Example 155, where the first value contains a similarity identifier.

[756] Example 163 encompasses the subject matter of Example 162, in which similar identifiers include unstructured data.

[757] Example 164 embraces the subject matter of Example 162, where the similar identifiers include rank, population, range of values.

[758] Example 165 encompasses the subject matter of Example 155, where a privacy policy governs the generation of integrated data.

[759] Example 166 encompasses the subject matter of Example 165, where a privacy policy further specifies the generation of DDIDs for consolidated data.

[760] Example 167 encompasses the subject matter of Example 155, where at least some of the data obtained from the original user defines consolidated data.

[761] Example 168 encompasses the subject matter of Example 155, where the data obtained from the first user alone defines the aggregated data.

[762] Example 169 is a configuration of computer-implemented techniques that takes a request from the first user as a measure of privacy policy, determines the first privacy policy based at least in part on the request, and Obtain data from the first user associated with the first plurality of the subject and generate the first dynamically changing temporary unique identifier (DDID) for the first plurality of the first data subject. Here, the dynamically changing temporary unique identifier is aggregated to replace the first value associated with the first data subject and to meet the determined first privacy policy. Then, the first dynamically changing temporary unique identifier is stored in one or more data storage devices, and the first request for the first value associated with the first data subject is received over the network, and the first If the first request is not authorized to receive the first value according to the privacy policy, the first dynamically changing temporary unique identifier is sent on the network in response to the first request, and the first If the first request is authorized to receive the first value according to the privacy policy, then send the first value over the network in response to the first request.

[763] Example 170 encompasses the subject matter of Example 169, where the first dynamically changing temporary unique identifier includes the Replacement DDID (R-DDID).

[764] Example 171 encompasses the subject matter of Example 169, where the one or more third dynamically changing temporary unique identifiers include an Association DDID (A-DDID).

[765] Example 172 encompasses the subject matter of Example 169, where the R-DDID has a particular value that replaces the first value. .

[766] Example 173 encompasses the subject matter of Example 171, where A-DDID has a particular value.

[767] Example 174 encompasses the subject matter of Example 173, where the particular values include class, subset, and range of values that replace the first value.

[768] Example 175 embraces the subject matter of Example 169, where the first user requests a privacy policy action, data related to the first pluralities of data subjects, and a first value for the first value. At least one of the requests is received via the shim.

[769] Example 176 encompasses the subject matter of Example 169, where the first value includes a similarity identifier.

[770] Example 177 embraces the subject matter of Example 176, where the similarity identifier includes unstructured data.

[771] Example 178 encompasses the subject matter of Example 176, where similar identifiers include rank, population, and range of values.

[772] Example 179 encompasses the subject matter of Example 169, where a privacy policy governs the generation of integrated data.

[773] Example 180 encompasses the subject matter of Example 179, where the privacy policy further specifies the generation of DDIDs for consolidated data.

[774] Example 181 encompasses the subject matter of Example 169, where at least some of the data obtained from the first user defines consolidated data.

[775] Example 182 encompasses the subject matter of Example 169, where the data obtained from the first user alone defines the aggregated data.

[776] Example 183 is a permanent program storage device, readable by a programmable control device and composed of stored instructions. The programmable device performs the following operations by executing the instruction. Retrieving requests from the first user as a measure of privacy policy, determining the first privacy policy based at least in part on the request, and retrieving data from the first user associated with the first plurality of data subjects However, because of the first plurality of the first data subject, it generates the first dynamically changing temporary unique identifier (DDID). Here, the dynamically changing temporary unique identifier is aggregated to replace the first value associated with the first data subject and to meet the determined first privacy policy. Then, the first dynamically changing temporary unique identifier is stored in one or more data storage devices, and the first request for the first value associated with the first data subject is received over the network, and the first If the first request is not authorized to receive the first value according to the privacy policy, the first dynamically changing temporary unique identifier is sent on the network in response to the first request, and the first If the first request is authorized to receive the first value according to the privacy policy, then send the first value over the network in response to the first request.

[777] Example 184 encompasses the subject matter of Example 183, where the first dynamically changing temporary unique identifier includes the Replacement DDID (R-DDID).

[778] Example 185 encompasses the subject matter of Example 183, where one or more third dynamically changing temporary unique identifiers include an Association DDID (A-DDID).

[779] Example 186 encompasses the subject matter of Example 185, where the R-DDID has a particular value that replaces the first value.

[780] Example 187 encompasses the subject matter of Example 185, where A-DDID has a particular value.

[781] Example 188 encompasses the subject matter of Example 187, where the particular values include class, subset, and range of values that replace the first value.

[782] Example 189 encompasses the subject matter of Example 183, where the first user requests a privacy policy action, data related to the first pluralities of data subjects, and a first value for the first value. At least one of the requests is received via the shim.

[783] Example 190 encompasses the subject matter of Example 183, where the first value includes a similarity identifier.

[784] Example 191 encompasses the subject matter of Example 190, where the similarity identifier includes unstructured data.

[785] Example 192 encompasses the subject matter of Example 190, where similar identifiers include rank, population, range of values.

[786] Example 193 encompasses the subject matter of Example 183, where a privacy policy governs the generation of integrated data.

[787] Example 194 encompasses the subject matter of Example 193, where a privacy policy further specifies the generation of DDIDs for consolidated data.

[788] Example 195 encompasses the subject matter of Example 183, where at least some of the data obtained from the original user defines consolidated data.

[789] Example 196 encompasses the subject matter of Example 183, where the data obtained from the first user alone defines the aggregated data.

[790] Example 197 is a system and includes the following configuration. A communication interface for sending data over a network, a computer program code and an embedded memory with a distributed ledger capable of recording data, and one or more processes connected to the memory and configured to execute the instructions of the computer program code. It is a unit. The program code causes one or more process units to perform the following operations. Retrieve data from the first user associated with the first data subject and generate a first dynamically changing temporary unique identifier (DDID) for the first data subject. Here, the DDID is aggregated to replace the first value associated with the first data subject. The first DDID is then stored in the first element of the first ledger of one or more distributed ledgers, and the first request from the first requester for the first value associated with the first data subject is sent over the network. , And the first requester is not authorized to receive the first value, it sends the first DDID to the first requester on the network in response to the first request, and the first requester If it is authorized to receive the first value, it sends the first value associated with the first data subject to the first requestor on the network in response to the first request.

[791] Example 198 covers the subject matter of Example 197, in which the network is distributed, the network comprises a plurality of nodes, and the network is at the beginning of one or more distributed ledgers at each node. Save a copy of.

[792] Example 199 encompasses the subject matter of Example 198, where the first of one or more distributed ledgers comprises a blockchain and the first element comprises the first block.

[793] Example 200 encompasses the subject matter of Example 197, where one or more process units are aggregated to execute instructions in computer program code, which code causes the one or more process units to Obtains a request from the first user as a workaround for the privacy policy and determines an initial privacy policy based at least in part on the request. Here, the first DDID is aggregated to meet the determined first privacy policy.

[794] Example 201 encompasses the subject matter of Example 197, where a first DDID shows a storage location containing the first value associated with the first data subject.

[795] Example 202 encompasses the subject matter of Example 201, where one or more process units are aggregated to execute instructions in a computer program code, which code causes the one or more process units to Get a request from the first user to change the first value associated with the data subject to the first modified value and store the first modified value in the storage location containing the first value associated with the data subject ..

[796] Example 203 encompasses the subject matter of Example 197, where the first data subject includes the first feasible period of the smart contract.

[797] Example 204 is a configuration of a computer-implemented approach that obtains data from the first user associated with the first data subject and for the first data subject, the first dynamically changing temporary Generate a unique identifier (DDID). Here, the DDID is aggregated to replace the first value associated with the first data subject. The first DDID is then stored in the first element of the first ledger of one or more distributed ledgers, and the first request from the first requester for the first value associated with the first data subject is sent over the network. , And the first requester is not authorized to receive the first value, it sends the first DDID to the first requester on the network in response to the first request, and the first requester If it is authorized to receive the first value, it sends the first value associated with the first data subject to the first requestor on the network in response to the first request.

[798] Example 205 encompasses the subject matter of Example 204, in which the network is distributed, the network includes a plurality of nodes, and the network is the first of one or more distributed ledgers at each node. The first of the one or more distributed ledgers contains the blockchain and the first element contains the first block.

[799] Example 206 covers the subject matter of Example 204, where a request for a privacy policy is taken from the first user, and the initial privacy policy is based, at least in part, on the request. To do. Here, the first DDID is aggregated to meet the determined first privacy policy.

[800] Example 207 encompasses the subject matter of Example 204, where a first DDID shows a storage location containing the first value associated with the first data subject.

[801] Example 208 encompasses the subject matter of Example 207, where a request from the first user is made to the data subject to change the first value associated with the data subject to the first modified value. Save the first modified value in the storage location that contains the first associated value.

[802] Example 209 encompasses the subject matter of Example 204, where the first data subject includes the first viable period of the smart contract.

[803] Example 210 is a permanent program storage device, readable by a programmable control device and composed of stored instructions. The programmable device performs the following operations by executing the instruction. Retrieve data from the first user associated with the first data subject and generate a first dynamically changing temporary unique identifier (DDID) for the first data subject. Here, the DDID is aggregated to replace the first value associated with the first data subject. The first DDID is then stored in the first element of the first ledger of one or more distributed ledgers, and the first request from the first requester for the first value associated with the first data subject is sent over the network. , And the first requester is not authorized to receive the first value, it sends the first DDID to the first requester on the network in response to the first request, and the first requester If it is authorized to receive the first value, it sends the first value associated with the first data subject to the first requestor on the network in response to the first request.

[804] Example 211 covers the subject matter of Example 210, in which the network is distributed, the network includes a plurality of nodes, and the network is the first of one or more distributed ledgers at each node. Save a copy of.

[805] Example 212 encompasses the subject matter of Example 210, in which the first of one or more distributed ledgers comprises a blockchain and the first element comprises the first block.

[806] Example 213 embraces the subject matter of Example 210, where instructions in the computer program code cause a programmable control device to obtain a request from an initial user as a measure of privacy policy, and at least partially. Determines the initial privacy policy based on the request. Here, the first DDID is aggregated to meet the determined first privacy policy.

[807] Example 214 encompasses the subject matter of Example 210, where a first DDID shows a storage location containing the first value associated with the first data subject.

[808] Example 215Example encompasses the subject matter of Example 214, in which instructions in a computer program code cause a programmable control device to change a first value associated with a data subject to a first modified value. , Get the request from the first user and store the first modified value in a storage location that contains the first value associated with the data subject.

[809] Example 216 encompasses the subject matter of Example 210, where the first data subject includes the first feasible period of the smart contract.

[810] Although the methodology of the present invention has been described and touched upon by specific procedures with specific procedures, these procedures are combined, subclassified, and deviated from the sub-divided, guidance of the invention. Without changing the ordering, the ordering may be changed for a similar method. Therefore, unless otherwise specified, the operating procedures and combinations are not limited to the present invention. For example, as another non-limiting example, the manipulated variables described herein may be rearranged and function in a different procedure than that described.

[811] In this specification, where appropriate, in at least one embodiment of the invention, reference to "an embodiment" or "an example" refers to a particular feature, structure, or characteristic described in connection with the embodiment. Should be understood to be included.

[812] The term "browser" as used herein refers not only to web browsers, but also to programmable display engines used in, for example, X-Windows, remote display devices used to virtualize desktops, text, and multimedia messages. Applications, device user interfaces, etc. enabled by other parties (eg Facebook Messenger, WhatsUp, Snapchat, Wicker, Cyberdust, and other user/corporate applications that provide these features). Mentioned. The term "web" as used herein is not limited to the World Wide Web (WWW), but is, for example, purely verbatim linked documents, spread among multiple actors, or across a single subject (such as an intranet), It also refers to devices that cooperate internally. The term "device" as used herein refers to an existing or "virtual" device, such as a virtual machine (VM) or a nodeJS hosted microdevice. A server consists of multiple elements on different computers or devices, or within the same computer device. Similarly, a client may consist of multiple elements on different computers or devices, or within the same computing device. The server and client communicate via a medium such as the Internet, but also utilize remote procedure calls (RPC) and operating system application programming interfaces (APIs), for example.

[813] The exemplary embodiments of the invention, and the above description of various features of the invention, are sometimes summarized in an embodiment, diagram or description, which streamlines the invention and allows one or more The purpose is to assist in understanding various invention points. However, the approach of the present invention should not be construed to reflect the intention that the claimed invention requires more performance than is expressly recited in each claim. Rather, the inventive aspects of all of the above-described embodiments of the present invention are small and each described embodiment may include one or more inventive features.

[814] The present invention has been shown in detail with reference to examples, and a person skilled in the art can make various other changes in form and details without departing from the true spirit and scope of the invention. Is considered to be.

Claims (20)

A system that includes a communication interface for sending data over a network, a computer program code and a built-in memory with a distributed ledger for recording data, and a computer connected to the memory and configured to execute the instructions of the computer program code. One or more process units One or more process units, configured to execute the instructions of a computer program code, connected to an embedded memory memory with a distributed ledger capable of recording the computer program code, depending on the code. , One or more process units retrieve data from the first user associated with the first data subject,
Generates the first dynamically changing temporary unique identifier (DDID) for the first data subject, where the DDID is aggregated to replace the first value associated with the first data subject. ,
Store the first DDID in the first element of the first ledger of one or more distributed ledger,
Receiving the first request on the network from the first requester for the first value associated with the first data subject,
If the first requestor is not authorized to receive the first value, it sends the first DDID on the network to the first requestor in response to the first request, and
If the first requestor is authorized to receive the first value, the first value associated with the first data subject is sent to the first requestor on the network in response to the first request. The system of claim 1, wherein the network is distributed, the network comprises a plurality of nodes, each network storing an initial copy of one or more distributed ledgers at each node. The system of claim 2, wherein the first of the one or more distributed ledgers comprises a blockchain and the first element comprises the first block. In the system of claim 1, one or more process units are aggregated to execute instructions in a computer program code, the code causing the one or more process units to:
As a measure to privacy policy, we get a request from the first user,
Determine the initial privacy policy based at least in part on the request,
Here, the first DDID is aggregated to meet the determined first privacy policy. In the system of claim 1, the first DDID indicates the storage location containing the first value associated with the first data subject. The system of claim 5, wherein one or more process units are aggregated to execute the instructions of the computer program code, the code causing the one or more process units to:
Get a request from the first user to change the first value associated with the first data subject to the first modified value,
Store the first modified value in the storage location that contains the first value associated with the data subject. In the system of claim 1, the first data subject comprises a first viable period of a smart contract. Obtaining data from a first user associated with a first data subject in a computer-implemented approach, including:
Generates the first dynamically changing temporary unique identifier (DDID) for the first data subject, where the DDID is aggregated to replace the first value associated with the first data subject. The DDID is stored in the first element of the first ledger of one or more distributed ledgers and the first request from the first requestor for the first value associated with the first data subject is received on the network. If the requester is not authorized to receive the first value, the first DDID will be sent to the first requestor on the network in response to the first request.
If the first requestor is authorized to receive the first value, the first value associated with the first data subject is sent to the first requestor on the network in response to the first request. The computer-implemented method of claim 8 wherein:
The network is distributed, the network includes a plurality of nodes, and each network stores an initial copy of one or more distributed ledgers on each node. The first of one or more distributed ledgers contains the blockchain and the first element contains the first block. The computer-implemented method of claim 8 wherein:
As a measure to privacy policy, we get a request from the first user,
Determine an initial privacy policy based at least in part on the request, where the initial DDIDs are aggregated to meet the determined initial privacy policy. The computer implemented method of claim 8, wherein the first DDID indicates a storage location containing a first value associated with a first data subject. Obtaining a request from a first user to change the first value associated with the first data subject to the first modified value in the computer-implemented method of claim 11;
Store the first modified value in the storage location that contains the first value associated with the data subject. The computer-implemented approach of claim 8, wherein the first data subject comprises a first viable period of a smart contract. A permanent program storage device that is readable by a programmable control device and consists of stored instructions that when executed cause the programmable device to
Get data from the first user associated with the first data subject,
Generates a first dynamically changing temporary unique identifier (DDID) for the first data subject, where the DDID is aggregated to replace the first value associated with the first data subject,
Store the first DDID in the first element of the first ledger of one or more distributed ledgers and receive the first request from the first requestor for the first value associated with the first data subject on the network. If the first requester is not authorized to receive the first value, it sends the first DDID to the first requestor on the network in response to the first request, and the first requester receives the first value. If authorized, send the first value associated with the first data subject to the first requestor on the network in response to the first request. The permanent program storage device of claim 14, wherein:
The network is distributed, the network includes a plurality of nodes, and each network stores an initial copy of one or more distributed ledgers on each node. The permanent program storage device of claim 15, wherein the first of the one or more distributed ledgers comprises a blockchain and the first element comprises the first block. 15. In the permanent program storage device of claim 14, the programmable control device obtains a request from the first user as a measure to the privacy policy by an instruction,
Determine the initial privacy policy based at least in part on the request,
Here, the first DDID is aggregated to meet the determined first privacy policy. 15. The permanent program storage device of claim 14, wherein the first DDID indicates the storage location containing the first value associated with the first data subject. The permanent program storage device of claim 18, wherein the programmable control device obtains a request from the first user to change the first value associated with the first data subject to the first modified value by the instruction. Store the first modified value in a storage location that contains the first value associated with. The permanent program storage device of claim 14, wherein the first data subject comprises a first viable period of a smart contract.

Images