Techniques for controlling access to segmented data

Abstract

The present invention discloses a technique for controlling access to segmented data of multiple users requested by at least one data consuming device. In response to conditions specified in communications between at least one data aggregator system and the at least one data consuming device, information of multiple users meeting specified search criteria is shared (e.g., for a limited time). Using the data in violation of the specified conditions may trigger penalties under smart contracts on a distributed ledger or blockchain.

Description

Technical Field

[0001] The present disclosure relates to techniques for controlling access to segmented data and, in at least one embodiment, to techniques for segmenting data into separately encrypted groups of data and controlling access thereto to control its appropriate use and manage its inappropriate use. Summary of the Invention

[0002] Sharing computer-oriented data via wide area networks (e.g., the Internet) is becoming increasingly common. When a user interacts with a computer application (sometimes implemented and referred to as an "app") or website, user data, such as demographic data, is valuable in determining how to customize the user experience. However, once a user shares their data (including but not limited to personal data, demographic data, personally identifiable information (PII), and / or any other valuable user data) outside of their own user device, and particularly if they share their data across multiple computer systems, the user traditionally has no control over how long the data can be used, for what purpose the data can be used, and whether the data can be redistributed.

[0003] In accordance with at least one aspect of the systems described herein, a user's data is segmented into multiple groups such that access to each group's data can be individually controlled and the user can be individually incentivized to provide access to each group. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The following description, given with reference to the accompanying non-limiting examples, may be better understood with reference to the accompanying drawings, in which:

[0005] Figure 1A is a block diagram of a group of user devices sharing data with at least one data aggregator system that individually controls access by the data consuming devices to segmented portions of the user data;

[0006] Figure 1B is a diagram of an exemplary computer system for implementing at least one of a user device, a data aggregator system, and a data consumption device;

[0007] Figure 1Cis a block diagram of any of the following: (a) an exemplary data aggregator system including a computer storage device for storing and providing at least one of user data records, smart contracts related to the use of user data records, a distributed ledger recording conditions for the use of user data records, and filtering rules for controlling / limiting communications between the data aggregator system and at least one user device; (b) an exemplary user device for providing data to at least one of the data aggregator systems and receiving and responding to requests for additional data from at least one of the data aggregator systems; and (c) an exemplary data consuming device for requesting and receiving shared data from at least one user device via at least one aggregator device;

[0008] Figure 2 is an exemplary typed data block representing exemplary group data initially obtained by the data aggregator system for user "User1";

[0009] Figure 3 is an exemplary typed data block representing exemplary set data originally generated by a data aggregator system for Figure 2 The user "user1" is stored internally;

[0010] Figure 4A is a data exchange diagram illustrating at least one data aggregator system obtaining data from at least one user device, publishing the availability of at least a portion of the obtained data, and a data consuming device requesting and being provided access to the requested portion of the available data;

[0011] Figure 4B yes Figure 4A a first continuation of the data exchange diagram and illustrating a data consuming device requesting and being supplied access to data related to data obtained from at least one user device, said data being published by at least one data aggregator system and being supplyable by said at least one data aggregator system without user intervention;

[0012] Figure 4C yes Figure 4A a second continuation of the data exchange diagram of and illustrating a data consuming device requesting and being provided access to data related to data obtained from at least one user device, said data being published by at least one data aggregator system, but under a new set of conditions “c2”;

[0013] Figure 4D yes Figure 4A a third alternative continuation of the data exchange diagram and showing that under a new set of conditions “c2”, the data consuming device requests but is denied access to the requested data via the user device proxy;

[0014] Figure 5is an exemplary typed data block representing an exemplary set of data shared with a data consuming device under a set of conditions "c1";

[0015] Figure 6 Yes Figure 3 An exemplary typed data block of exemplary set data that has been supplemented to include information corresponding to how to share with a data consuming device under a set of conditions "c1" Figure 5 Usage records of the data part in;

[0016] Figure 7 Yes Figure 6 an exemplary typed data block of an exemplary set of data, the data block being supplemented to contain additional information in response to a query from a data consuming device without user intervention;

[0017] Figure 8 Yes Figure 7 an exemplary typed data block of exemplary group data of which the group data has been supplemented to include a condition "c2" for utilizing an additional group of a plurality of data elements therein;

[0018] Figure 9 Yes Figure 8 an exemplary typed data block of exemplary groups of data, wherein each group of data elements has been encrypted using a different key;

[0019] Figure 10 is part of an exemplary request from a data consuming device, including a description of the smart contract conditions proposed by the data consuming device at the time of use and penalties for misuse of user data; and

[0020] Figure 11 is part of an exemplary response from a user device or a user device agent, including a description of the proposed smart contract usage conditions objected to by the user device or the user device agent and penalties for misuse of user data. DETAILED DESCRIPTION

[0021] To address the technical problem of limiting access to shared data, a data aggregator system acts as a gatekeeper between at least one user device of at least one user and at least one data-consuming device, which utilizes (and potentially redistributes) shared data obtained from the at least one user device (via the data aggregator system). The shared data is initially obtained from the at least one user device by the data aggregator system. When the data-consuming device initially queries the data aggregator system to determine whether it has shared data that meets specified conditions and / or has specified attributes, the data aggregator system can notify the data-consuming device whether it has initially matching data and, if so, how many records of such initially matching data it has. The data-consuming device can later query the data aggregator system to obtain additional data corresponding to a subset of the initially matching data (e.g., other characteristics and / or attributes of the user). If the data-consuming device requests and is provided with any shared data from the at least one user device via the data aggregator system, a (non-repudiable) record of the conditions under which the data was provided is created to track data misuse. By building a combined record set regarding data misuse, the data aggregator can, for example, use statistical analysis to identify data-consuming devices that improperly use and / or redistribute data to assess at least one penalty against the identified data-consuming devices 140. For example, by correlating suspected illegal uses of one or more group data under an executed smart contract with other reported suspected illegal uses of other group data of other users, the data aggregator system can, responsive to the correlation, determine that the data-consuming device is a participant in at least one of a threshold number and / or a threshold percentage of smart contracts with suspected illegal uses, thereby triggering a penalty.

[0022] like Figure 1A As shown in the block diagram of FIG. 1 , at least one data aggregator system 100A-100Y collects data from a single user device 120A or a plurality of user devices 120A-120X (wherein the user devices may operate one or more programs, applications, "apps," or interpreted environments, including but not limited to network-based environments and / or virtual environments) of a user (where X and Y may be the same, but typically will be different, where a single data aggregator system operates to aggregate at least many orders of magnitude more user devices than aggregator devices (e.g., each aggregator device aggregates data from millions or at least hundreds of thousands of user devices). As used herein, each user device 120 is represented by an oval, and when discussing groups of user devices 120 collectively, more than one of the plurality of user devices may also be referred to herein by the reference numeral 120. However, the technology disclosed herein is equally applicable to a single user device or a plurality of user devices. Although Figure 1AAlthough indicated as independent in the examples, those skilled in the art will appreciate that some or all of the functionality described herein with respect to a user device may be performed by a device other than the user device 120 owned by the user. For example, a user may use the user device 120 to log into or otherwise interact with a remotely provided service (e.g., a web-based service) such that processing is performed on a remote server (on behalf of the user of the user device 120) in response to interactions with a web page or graphical user interface (e.g., an HTML form; an HTML interface, such as an HTML5 interface; and an Angular.js interface). Such interfaces may be used to, among other things, provide, modify, and / or delete a user's data and to specify conditions for managing user data. As described in more detail below with respect to a user device agent, filtering rules may also be uninstalled from the user device 120.

[0023] When at least one of the data aggregator systems 100 "obtains" data from any one of the user devices 120, the at least one of the data aggregator systems 100 may receive the data via any form of data transfer, including, but not limited to, receiving the data using wired communication (e.g., serial-based communication such as USB or Ethernet) or wireless communication (e.g., using radio frequency (RF) communication such as Wi-Fi (under any 802.11 family of standards), mesh, cellular, and / or wireless local area network (WLAN) communication, infrared (IR) communication, or other light-based communication). Such transfer also includes copying files from one or more storage media physically (e.g., attached via USB) or logically (e.g., using at least one file server) attached to the at least one data aggregator system 100. Such transfer also includes inter-process communication when the application of the user device 120 and the at least one data aggregator system 100 are running computer code on a single platform (e.g., when running in different virtual machines on a common set of hardware).

[0024] As discussed in more detail below, any data aggregator system, user data device, and data consumption device as described herein may be implemented using dedicated hardware on a fixed or portable device comprising: (a) one or more computer processors having specially programmed computer instructions for controlling the one or more computer processors to perform one or more of the techniques described herein; and / or (b) application-specific hardware that uses binary logic to perform one or more of the techniques described herein.

[0025] When any of devices 100, 120, and 140 obtain data from another of those devices, they may do so by utilizing one or more different types of user interfaces, such as (1) a customized application for communicating with the device, (2) a web browser or cloud-based application that connects to or communicates with the device (or the device's agent), or (3) an email interface or social media interface that connects to or communicates with the device (or the device's agent).

[0026] Similarly, when any of devices 100, 120, and 140 "transfers" data to any of the other devices, the device may send the data via any form of data transfer, including, but not limited to, sending data using wired communication (e.g., serial-based communication such as via Universal Serial Bus (USB) or Ethernet) or wireless communication (e.g., using radio frequency (RF) communication such as Wi-Fi (under any 802.11 family of standards), mesh, cellular, and / or WLAN communication, IR communication, or other light-based communication). Such transfers also include copying files to one or more storage media physically (e.g., via USB attachment) or logically (e.g., using at least one file server, including via a cloud-based connection) attached to any of the devices. Such transfers also include inter-process communication when the devices are running computer code on a single platform (e.g., when running in different virtual machines on a common set of hardware).

[0027] Each data aggregator system 100 can receive and process requests from both user devices and data consuming devices from multiple application programming interfaces and user interfaces, either serially or in parallel (e.g., using multiple physical and / or virtual communication connections). Such communication connections are preferably via at least one reliable communication service (e.g., TCP / IP or Reliable Datagram Protocol (RDP)) or via an unreliable communication service (e.g., UDP), with application-specific retransmission and / or authentication protocols established on top of the unreliable communication service. In addition to reliable and / or unreliable communication services, the devices described herein can communicate using a variety of communication protocols (e.g., HTTP, Secure HTTP (HTTPS), WebDAV), and / or the devices can communicate via dedicated tunneling protocols (e.g., using a virtual private network (VPN)). As shown in FIG. 1 , the number of data consuming devices 140A to 140Z can also be different from the number of data aggregator systems 100 or user devices 120, or can be the same as either or both.

[0028] like Figure 2As shown in FIG, in an exemplary process described for purposes of illustration, at least one data aggregator system 100 obtains a set of data initially describing a user "User 1" from a user device 120. To entice the user to provide such data, a variety of different incentives may be offered by at least one data aggregator system 100 to the user of the user device 120. Such incentives may include, but are not limited to, currency, cryptocurrency, reward travel points, store points, and discounted or free services.

[0029] As shown in the figure, the received data is a typed data block with a notation similar to XML or JSON style format, where the data type (or data key) surrounds the data itself, and the attributes or metadata that further describe the data follow the data type and precede the data itself. The data type (or data key), the data itself, and the attributes (or metadata) are collectively referred to as data elements. For example, the "user" data element is marked with " <user> "and"< / user> " to show where the information about the user begins and ends. As will be understood by those skilled in the art, the overall structure of the data elements may be recursive and may be described by an architectural specification (e.g., such as a data type definition (DTD) file). Furthermore, the data types (or keywords) and data used herein are for illustrative purposes only; other keywords may alternatively be used to represent the same type of data (e.g., "user" may be replaced with "person"). Furthermore, while the description herein is primarily provided with reference to "users," the system is not limited to aggregating only data about users. Other "entities" may be similarly tracked for similar purposes. For example, information about a "device" may be tracked so that services provided to the device can be similarly customized.

[0030] like Figure 2 As further shown in , the typed data block can be further divided into various overlapping or non-overlapping data elements. The first shown data element contains one or more sub-data elements, each of which corresponds to demographic information about a user. For example, the user device 120 can provide the name of the corresponding user (e.g., "Name 1") and information about the user (e.g., birthday, height, and eye color) to the at least one data aggregator system 100. As will be understood, more or less demographic information is provided in various embodiments of the information described herein without departing from the intent of the present disclosure.

[0031] Likewise Figure 2As shown in FIG, identification information (in a data element with a data keyword called "identification information") can be provided in a separate data element and can contain information designed to identify the user (e.g., a U.S. Social Security number (e.g., in the form of xxx-yy-zzzz) or a driver's license number (such as that issued by the State of California)). As shown in the figure, the data elements can contain overlapping information (e.g., a "name" data element) so that certain portions of the information can be shared without having to share other information, especially if different groups of data elements are encrypted with different keys (e.g., Figure 9 ) is provided separately in multiple contexts. For example, data segmentation can occur when a user is willing to share demographic information with the data consuming device 140 but not identifying information or financial information, or when a user is willing to share financial information with the data consuming device 140 but not identifying information or demographic information.

[0032] like Figure 3 As shown in FIG, at least one data aggregator system 100 can aggregate information received from multiple users (shown as "User 1," "User 2," and "User 3") having corresponding user devices 120 and (1) utilize data elements of the received information as is, (2) remove information from the data elements, and (3) supplement the information with additional data elements. In the typed data block shown, the at least one data aggregator system 100 aggregates the "User" data element as part of a nested "User" data element. Internally, the "Identifying Information" data element is shown as having information that the at least one data aggregator system 100 is not allowed to store (or chooses not to store), such as social security numbers and driver's license numbers, removed. However, the User data element is shown as supplemented with an internally generated "User id" attribute (having an exemplary value of "1234") so that shared data corresponding to the user of the corresponding user device can be monitored by the at least one data aggregator system 100. The attribute information can also be used to manage information sharing with one or more data consuming devices when sharing other elements in the same data element. As shown, the "Date of Birth" data element has a "Never Share" attribute set to "True" added to it, so that the date of birth information is never directly shared. In one embodiment, the user can still choose to provide age-related information by including an "Age" data element, which includes a "Cut-off" attribute so that the system can use the current date and the attribute value (e.g., "2019-01-01" for the attribute) to determine the approximate age.

[0033] The user's data elements are additionally supplemented with placeholders for other information associated with the user (e.g., "health information" and "purchase information"), which are represented by using corresponding empty tags (e.g., " <healthinformation / > "and" <purchasinginformation / >”). In addition, as will be described in more detail below, the at least one data aggregator system 100 can add to the information about the user device 120 additional information related to which information of the user information has been shared with different data consuming devices 140 (such as by storing such information in a data element referred to as “usage information”).

[0034] The data stored by at least one data aggregator system 100 is stored in a manner that allows it to be retrieved and managed upon request, in response to requests from user devices and / or data aggregator systems. In one such embodiment, the data is simply written to a file (e.g., as used in a fixed-format file or a self-describing data file such as an XML-style file) as a series of data records and / or data elements. In an alternative embodiment, the data is stored in at least one record in a database (or multiple local and / or remote databases) that can be accessed directly by reading from / writing to the database or by a database manager (including a database manager that performs network access (including reading and writing) to at least one remote database). In another alternative embodiment, when stored by at least one data aggregator system 100, the data elements are written (in encrypted form) to a distributed ledger (e.g., using a blockchain) to provide accountability for data received from user devices and / or transmitted to data consuming devices. In another alternative embodiment, a cryptographic digest of the data (such as a hash) is written to the distributed ledger to provide accountability for data received from user devices and / or transmitted to data consuming devices. In yet another alternative embodiment, a record number or record pointer identifying a record in an off-ledger data store (e.g., a database) is written to the distributed ledger to provide accountability for data received from a user device and / or transmitted to a data consuming device. As will be appreciated by one of ordinary skill in the art, different databases and / or distributed ledgers may be used to store different data (e.g., a user's data may be stored on a local or remote database, and the conditions for use of that data may be stored on a distributed ledger).

[0035] Go to Figures 4A to 4D , a series of data exchange diagrams illustrate multiple data transfers between at least one data aggregator system 100, a user device 120, and a data consuming device 140. Figure 4A In the embodiment, at least one data aggregator system 100 obtains (via transmission T400) data from at least one user device 120. After processing the obtained data as needed (e.g., Figure 2 The data is converted into Figure 3After obtaining data from at least one data aggregator system 100, at least one data aggregator system 100 publishes (via one or more transmissions T410) the availability of at least a portion of the obtained data. In one embodiment, the data is made available to a query (e.g., using an API) from a data consuming device 140 requesting access to the data. In such an embodiment, prior to the one or more transmissions T410, a request (not shown) is sent requesting the number of records stored by at least one data aggregator system 100 that meet certain criteria. For example, as part of a market analysis for a new eyeshadow color, a data consuming device 140 requests the number of user data elements stored by at least one data aggregator system 100 for users who are over 20 years old, have an income of over $40,000, and have blue eyes. In response to the request, at least one data aggregator system 100 publishes (by responding to the query) the number of such records to the data consuming device 140, without revealing the records themselves that meet those criteria.

[0036] In an alternative embodiment, the anonymized and aggregated summary is published where the data consuming device 140 can read it (e.g., on a distributed ledger or blockchain) so that a separate query directly to the at least one data aggregator system 100 is not required (thereby reducing the messaging load on the at least one data aggregator system 100).

[0037] After determining that there is data of interest, the data consumption device 140 may request access to the shared data corresponding to its needs. Figure 4A As shown in FIG, using transmission T420, the data consuming device 140 requests access to data published by the DA 100 obtained from at least one user 120 under acceptable conditions. For example, the data consuming device 140 may request records corresponding to condition "c1", which for illustrative purposes is a monetary incentive (e.g., a payment of $1 to a default account).

[0038] In an embodiment using a smart contract, transmission T420 further includes a smart contract description including code for implementing the smart contract and a type field indicating the usage conditions of the data being requested by the data consuming device 140, so that if the data consuming device 140 is found to be misusing the data it receives, an implementation mechanism can be used with the data consuming device 140. Figure 10As shown in , the smart contract records the length of time the data can be used (as specified in the "valid minimum" field) and confirmation of what data fields the data consuming device 140 will receive. The smart contract is further shown to include payer and payee fields to automatically handle the payment of fines and amounts to be incurred. The amount is shown as a one-time payment of $5,000 to an account of the data aggregator system. The contract_code field contains the actual code (e.g., an interpreted script written in a language supported by the distributed ledger or blockchain) implemented by the distributed ledger or blockchain system when the data aggregator system or other "oracle" reports data abuse. Although not shown, the smart contract can include multiple types of abuse, conditions indicating abuse, and corresponding penalties for each type of abuse.

[0039] Back to Figure 4A As part of transmitting T430, the data consumption device 140 may receive one or more corresponding records (eg, Figure 5 To control costs, the data consuming device 140 may specify as part of its request T420 a maximum number of records that it wishes to receive as a result (thereby limiting any number of factors, such as the cost of the data consuming device 140).

[0040] As part of transmitting T430, at least one data aggregator system 100 will update the information corresponding to the user whose information was supplied. Figure 6 As shown, the transferred information and the conditions under which the information was transferred are added to the information of User 1. Although for illustrative purposes, the data element corresponding to the usage record is added directly (in the "Usage Record" data element) to the other data records of User 1, in alternative embodiments, the usage records are stored separately (e.g., in a database of usage records so that they can be more easily queried). Alternatively, the usage records can be sent to the corresponding user devices for their storage, so that the shared data can be removed from the data aggregator system at the request of the user device without losing a record of what was stored and with whom it was shared. Alternatively, the data aggregator system can store a hash of the information or a signed hash of the information so that the user device can prove to the data aggregator system what information was previously shared without having to allow the data aggregator system to permanently store the shared data.

[0041] In an embodiment using smart contracts, one or more smart contracts for sharing data are written to a distributed ledger or blockchain before transmission T430 to record the conditions agreed upon for data sharing. Alternatively, before transmission T430, the data aggregator system 100 sends a hash of the data to be transmitted to the data consuming device 140 and requests a signed message from the data consuming device 140 confirming the hash, so that the data consuming device 140 cannot later deny the transmission.

[0042] Figure 4B yes Figure 4A and illustrates a data consumption request and being provided access to data related to data published by at least one data aggregator system 100 obtained from at least one user 120. For example, in transmission T440, the data consuming device 140 may request to supplement information associated with at least one record returned as part of a previous transmission T430 (e.g., the record for user id="1234" returned a month ago) with additional information about the corresponding user's education to determine the user's years of education after high school. In one such embodiment, before the at least one data aggregator system 100 communicates with the user, the at least one data aggregator system 100 attempts to leverage information it already has about the user to avoid interrupting the user's acquisition of information. For example, the URL where User 1 stores their public social media may be used by the at least one data aggregator system 100 to determine that User 1 attended a four-year college and earned an MBA. Thus, the at least one data aggregator system 100 may autonomously add the requested data element ( <educationinformation> <posthseducation> 4+< / posthseducation> < / educationinformation> ).like Figure 7 As shown in , in addition to adding the educational information to the user record, in transmission T450, a new usage record is added to the user information, showing that the educational information is shared (also under condition "c1"). Figure 7 Although the example utilizes condition "c1" for both instances, transfer may occur under any condition acceptable to the data consuming device 140 for which a user condition already exists that satisfies the transfer criteria.

[0043] Alternatively, when it is known that the corresponding information is not available from the user, T450 may instead include a denial of the request in transmission T440. For example, if transmission T440 had requested the date of birth of user 1, at least one data aggregator system 100 would already know that it is not possible to share that information from the "never share" attribute of the date of birth data element (e.g., Figure 3 shown in ).

[0044] Figure 4C yes Figure 4A , and illustrates a data consuming device requesting and being provided access to data related to data obtained from at least one user device 120, said data being published by at least one data aggregator system 100, but under a new set of conditions "c2". Figure 4C In transmission T460, the data-consuming device 140 requests new data that is not yet available (and that the at least one data aggregator system 100 cannot autonomously obtain) or uses the data under a set of incentives / usage parameters that have not been previously established. For example, as part of its eyeshadow research, the data-consuming device 140 may request information about the user's hair color in addition to eye color. Because such data was previously unavailable, the at least one data aggregator system 100 requests the hair color information in transmission T470. Alternatively, transmission T470 may have requested a new set of permissions, such as the right to use existing data for a longer period than previously permitted or the right to redistribute the data. In either case, in transmission T480, the user device 120 indicates whether the updated conditions are acceptable and / or what the acceptable conditions are. Assuming that condition "c2" is acceptable, in transfer T490, at least one data aggregator system 100 (1) stores the requested permission and / or data from at least one user device 120, and (2) provides access to data related to the data published by DA 100 obtained from at least one user device 120, but under new conditions (e.g., c2). Figure 8 , the user's data elements are updated accordingly.

[0045] In embodiments utilizing smart contracts, the smart contract may be included in the transmission T460 such that the data aggregator is bound by its proposed use of the data to be shared. Figure 10 As discussed, the smart contract information can be added to the blockchain or distributed ledger as part of the process of sending the requested data. The conditions of the smart contract will then also be transmitted to the user device 120 as part of the transmission T470.

[0046] exist Figure 4CIn a transfer, it is assumed that data-consuming device 140 provides a set of conditions acceptable to user device 120 by specifying the requested data and usage conditions (e.g., incentive amount and expiration date). However, transfer T460 may alternatively take the form of a request for information or permission change, along with a request for a permission acceptable to the user. In such a configuration, additional transfers would be required to complete at least one offer / acceptance cycle for the conditions of the transfer. Therefore, the number of transfers may vary. In one embodiment, user device 120 bids for the use of its data before providing it. When contacted by at least one data aggregator system 100 (e.g., via email, in response to a query on a website, or via an application), the user can indicate the conditions under which the information will be provided without first providing the information. For example, condition c2 provided by data-consuming device 140 may have open-ended incentive terms to which the user must respond, or condition c2 may be objected to by the user (e.g., by specifying a higher or different incentive), and a counteroffer returned to data-consuming device 140. If the specified incentive terms are acceptable to data-consuming device 140, the user provides the data via aggregator device 100.

[0047] In such embodiments, rather than accepting or rejecting the conditions specified by the data aggregator system in transmission T460, the user device 120 between transmissions T470 and T480 may instead generate and send back to the data consuming device (via the data aggregator system 100) a counter-proposal to the requested use, and in the case of embodiments using smart contracts, a new smart contract that controls the use under the counter-proposal. Figure 11 As shown in , the counterproposal may include one or more sets of conditions that the data aggregator system can accept and that the user device is willing to be bound by. Figure 11 As shown in , although the counterproposal can include a single set of conditions, the counterproposal shown includes two different sets of conditions with different time lengths for data use and two different penalties: (1) a one-time fee of $10,000; and (2) a monthly fee of $2,000 for 12 months. Such conditions may be acceptable to a data aggregator system that knows the data will not be misused, so that the increased penalty will never need to be paid. The proposal / counterproposal process can be repeated any number of times between transmissions T470 and T480 until a mutually acceptable set of conditions is found or no agreement can be reached.

[0048] Figure 4D yes Figure 4AThe third alternative continuation of the data exchange diagram shows that under a new set of conditions "c2", the data consuming device 140 requests, but is denied, access to the requested data via the user device agent. In transmission T500, the data consuming device 140 requests access to data related to data published by the data aggregator system 100 obtained from at least one user device 120, but under new conditions (e.g., c2). In transmission T510, the data aggregator system 100 notifies the user device agent 125 of at least one user device 120 of a proposed change in use of its / their data and / or requests access to and / or perhaps the acquisition or use of additional data, rather than contacting the user device 120 to obtain additional input from the user itself. The user device agent 125 then performs a series of checks (e.g., using a set of rules) to determine whether it can determine (1) whether the request should be passed to the user of the user device; (2) based on stored rules, the request should be denied; or (3) the request should be objected to with a pre-stored objection or a dynamically generated objection based on at least one rule. In one embodiment, the user device agent 125 resides on the user device and is designed to reduce the number of interactions required with the user in view of requests from the data aggregator system 100. In an alternative embodiment, the user device agent 125 resides on the data aggregator system (e.g., in a separate virtual machine) and is designed to reduce the number of interactions required with the user device while isolating / hiding the user's rules from the data aggregator system 100 (e.g., avoiding situations where the data aggregator system 100 can see the conditions under which the user's data device will accept changes and / or provide additional data). In yet another embodiment, the user device agent 125 operates as part of the data aggregator system on behalf of the user device as a set of filtering rules to reduce the overhead of the agent / data aggregator system interaction. Exemplary rules that may be used on behalf of the user include the following rules: (1) If the data consuming device is requesting <x>information, then pass the request to the user; (2) if (2a) the data consumption device is requesting <y>Information, (2b) Request from <z>Data consumption device, and (2c) expiry date of data usage <date1> - <date2>if the request is within the date range specified in the preceding text, then the request is delivered to the user; and (3) otherwise, the request is prevented from being delivered to the user.

[0049] In transmission T520, the user device agent 124 notifies the data aggregator system 100 that the user device agent 125 has denied the request for data of the at least one user device 120 without requiring intervention from the user of the user device. In transmission T530, the data aggregator system 100 notifies the data consuming device 140 that the request for data of the at least one user device 120 has been denied. Alternatively, as described above, the agent may engage in one or more counter-proposals with the data consuming device before deciding on the acceptance or rejection conditions.

[0050] When storing information about which user's information was transmitted to which data consumption device 140, the system may require that the transmitted information (or a cryptographic digest of the transmitted information) be stored on a distributed ledger or blockchain so that the data consumption device 140 cannot deny that it received the information and received it under the conditions it negotiated. Alternatively, the data consumption device 140 may provide a signed message containing the cryptographic digest of the transmitted information.

[0051] This type of information authentication is important if the data consumption device 140 is accused of misusing data. In fact, in one exemplary embodiment, the transmission of information (e.g., in transmissions T430, T450, and T490) can involve the automatic execution of an automatically executing smart contract. In such a configuration, when a consensus is reached that the data consumption device 140 has misused user data, the account of the data consumption device 140 will be automatically debited to compensate the user.

[0052] In addition, in one embodiment, a distributed ledger (e.g., a blockchain) is utilized to track abuse of the data aggregator system. When a violation of the conditions of use is detected, one or more entries are added to the distributed ledger to track one or more of the following: (1) the type of abuse; (2) when the abuse occurred and / or was detected; (3) how the abuse occurred (e.g., what conditions of use were violated); (4) which data aggregator system is responsible for the abuse; (5) any penalties assessed for the abuse and whether the penalties are in progress; (6) what compensation is provided and whether the compensation is in progress; and (7) any other information about the abuse that may be important to other user devices, such as characteristics of the query that resulted in the misuse of a portion of the query results, so that other user devices that are part of the same query results or other queries for the same type of data can be notified.

[0053] As will be appreciated by those skilled in the art, the distributed ledger may also be used to store additional information. For example, in one embodiment, the same or different distributed ledger is used to store preferences corresponding to at least one of the user devices 120.

[0054] Each of the at least one data aggregator system 100, the user device 120, and the data consumption device 140 is implemented in at least one embodiment as at least one computer system including at least one processor, at least one (non-transitory) computer memory for storing computer instructions to control the operation of the at least one processor, and at least one input / output interface for performing the communications described herein (e.g., communications that enable the at least one data aggregator system 100 to obtain and transmit the data described herein). Figure 1B In one exemplary embodiment shown in FIG, computer system 2 includes, but is not limited to, at least one processor 4 in communication with at least one memory subsystem 6, at least one communication adapter 8, at least one input / output controller 10 (e.g., for communicating via Universal Serial Bus (USB) communication), magnetic digital storage 12 (e.g., a hard drive), semiconductor digital storage 13 (e.g., flash-based memory), low-density removable media storage (e.g., a floppy disk drive) 14, and high-density removable media storage (e.g., a Blu-ray, optical drive, and / or tape drive) 16. Furthermore, a keyboard 18 and a monitor 20 are connected to computer system 2 for inputting interactions with the computer system and outputting the resulting actions from computer system 2, respectively. An additional printer 22 for printing reports 24 is also provided.

[0055] The processor may include a commercially available processor (e.g., Intel 80x86, Motorola 680x0, Power PC, etc.) to direct and coordinate the activities of the other components of the computer system. The memory subsystem 6 includes at least one of a read-only memory (ROM) and a random access memory (RAM), and stores instructions to be executed by the processor 4. The processor 4 and the memory subsystem 6 together control the other devices of the computer system and communication with other computer systems (e.g., communication between the user device 120 and the data aggregator system 100 and / or communication between the data aggregator system 100 and the data consumption device 140). Similarly, each of at least one of the data aggregator system 100, the user device 120, and the data consumption device 140 can be implemented as a distributed system in which multiple computer systems communicate to jointly provide the functionality described herein. In one such embodiment, load balancing may be performed across multiple computer systems to provide reduced latency and / or increased throughput (e.g., by directing data consuming devices 140 and / or user devices 120 to a closer or more powerful computer system that implements a portion of at least one of the data aggregator systems 100). The multiple computer systems may include at least one cloud-based implementation, including at least one cloud-based implementation that dynamically distributes and removes processors and other computer resources based on load.

[0056] Those skilled in the art will appreciate that at least one embodiment utilizes a processor with multiple processing cores and / or threads to implement parallel processing of operations described herein that do not require serialization. In the event that operations do need to be serialized, the computer system utilizes synchronization and / or serialization mechanisms (e.g., semaphores, locks, and / or schedulers) provided by the computer system to achieve this (e.g., as may be required when two processes both wish to update the same portion of data at the same time) to provide increased concurrency.

[0057] In an alternative embodiment of at least one data aggregator system 100, at least one data aggregator system 100 is implemented as a set of dedicated processing circuit systems (e.g., one or more of an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a general purpose logic array (GAL)), which may be non-programmable, one-time programmable, or reprogrammable. Furthermore, in yet another embodiment, at least one data aggregator system 100 is implemented as a combination of a computer system and a set of dedicated circuit systems to implement the functionality described herein.

[0058] Furthermore, the communications described herein can be performed using either unencrypted or encrypted communications, whereby data is obtained by and transmitted from at least one data aggregator system 100. In one embodiment using encrypted communications, at least one data aggregator system 100, user device 120, and / or data consuming device 140 encrypts the data to be transmitted before providing the pre-encrypted data to a corresponding communication interface (physical or virtual (such as a socket)). In an alternative embodiment, at least one data aggregator system 100, user device 120, and / or data consuming device 140 provides the data to the corresponding communication interface in unencrypted form but requests that the corresponding communication interface encrypt the data before or as part of the transmission. In one embodiment, at least one data aggregator system 100, user device 120, and / or data consuming device 140 communicate using Secure Sockets Layer (SSL)-based communications, so that at least one data aggregator system 100, user device 120, and / or data consuming device 140 does not have to handle the communications separately.

[0059] Although portions of the above description have described data stored in the system as typed data blocks (which are stored in one or more data files, or in non-volatile storage (e.g., a hard drive), or in volatile storage (e.g., RAM), in alternative embodiments, the data is instead stored in one or more databases and accessed using direct database operations or through a database manager. In such configurations, the data is typically stored in data rows within a data table, or in corresponding objects in the case of an object-oriented database.

[0060] like Figure 9 As shown in , in one embodiment, a user's confidential information is encrypted with one or more keys, allowing the data to be segmented and individually controlled in encrypted form. Data elements identify the key number (but not the key value) of the key used to encrypt the various elements. In at least one embodiment, the user encrypts the data in a format specified by the at least one data aggregator system 100 before providing the data to the at least one data aggregator system 100. In this manner, data can be transmitted before conditions are specified for its use without concern that the data will be inappropriately shared. < / date1> < / z> < / y> < / x>

Claims

1. An access control system comprising: one or more processors; as well as a computer memory coupled to the one or more processors for storing computer instructions that, when executed by the one or more processors, control the one or more processors to perform operations including: obtaining a first set of data from a first user device, wherein the first set of data comprises a first data value and a corresponding first tag indicating a data type of the first data value; transmitting a data type of the first data value of the first set of data to a data consuming device; obtaining, from the data consuming device, a first request for a second set of data from the first user device; obtaining the second set of data, wherein the second set of data comprises a second data value and a corresponding second tag indicating a data type of the second data value; and The first set of data and the second set of data are transmitted to the data consuming device for use under a first set of specified conditions.

2. The system of claim 1 , wherein the computer memory further comprises instructions for controlling the one or more computer processors to: receiving a third set of data from the first user device, wherein the third set of data includes a third data value and a corresponding third tag indicating a data type of the third data value; and The third set of data from the first user device is stored with the first set of data and the second set of data.

3. The system of claim 2, wherein the computer memory further comprises instructions for controlling the one or more computer processors to: encrypting the first set of data for the first user device using a first key specific to the first user device; and The third set of data for the first user device is encrypted using a second key specific to the first user device, wherein the first key and the second key are different.

4. The system according to claim 2 or claim 3, wherein the first set of data and the third set of data correspond to different information fields.

5. The system of claim 4, wherein each of the first set of data and the third set of data corresponds to a respective different field of information selected from the group consisting of: personally identifiable information, financial information, medical information, travel information, purchasing information, residential information, and demographic information. 6 . The system of claim 1 , wherein storing the first set of data from the first user device comprises storing the first set of data from the first user device in a database.

7. The system of claim 1 , wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions comprises storing the first set of data and the second set of data on a distributed ledger.

8. The system of claim 1 , wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions comprises storing the first set of specified conditions on a distributed ledger.

9. The system of claim 1 , wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions comprises storing a result of an irreversible hash function performed on the first set of data and the second set of data on a distributed ledger.

10. The system of claim 1 , wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions comprises storing results of a cryptographic function performed on the first set of data and the second set of data on a distributed ledger.

11. The system of claim 10, wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions further comprises storing the first set of specified conditions on the distributed ledger.

12. The system of claim 1 , wherein the computer memory further comprises instructions for controlling the one or more computer processors to: In response to receiving the first request for the second set of data from the data consuming device, an electronic request for the second set of data is sent to the first user device.

13. The system of claim 12, wherein the electronic request comprises a smart contract for controlling use of the first set of data and the second set of data by the data consuming device, and The computer memory further includes instructions for controlling the one or more computer processors to perform the following steps: receiving an executed smart contract from the first user device in response to the smart contract sent in the electronic request.

14. The system of claim 1, wherein receiving the second set of data from the first user device comprises receiving a smart contract for the use of the first set of data and the second set of data.

15. The system of claim 12, wherein the electronic request comprises at least one of an email, a web-based notification, and an application-based notification.

16. The system of claim 1 , wherein the computer memory further comprises instructions for controlling the one or more computer processors to: An incentive is provided to a first user device for use of the first set of data and the second set of data under a first set of specified conditions, the incentive comprising at least one of: currency, cryptocurrency, reward travel points, and store credit.

17. The system of claim 1 , wherein the computer memory further comprises instructions for controlling the one or more computer processors to: receiving a notification of suspected illegal use of the first set of data and the second set of data under the executed smart contract; correlating the allegedly illegal use of the first set of data and the second set of data under the executed smart contract with other reported alleged illegal uses of other sets of data of users other than the first user device; as well as In response to the correlation, it is determined that the data-consuming device is a participant that is suspected of violating at least one of a threshold number and a threshold percentage of smart contracts used.

18. The system of claim 1, wherein transmitting the first set of data and the second set of data to the data-consuming device for use under a first set of specified conditions comprises executing a smart contract between the first user device and the data-consuming device using the first set of specified conditions.

19. The system of claim 1 , wherein transmitting the first set of data and the second set of data to the data consuming device for use under the executed smart contract comprises temporarily decrypting the first set of data and the second set of data within a server; and The first set of data and the second set of data are transmitted to the data consuming device through an encrypted communication channel.

20. The system of claim 1, wherein transmitting the first set of data and the second set of data to the data consuming device for use under a first set of specified conditions comprises: performing an encryption function on the first set of data and the second set of data; as well as The result of the cryptographic function is stored on a distributed ledger.

21. The system of claim 1 , wherein the computer memory further comprises instructions for controlling the one or more computer processors to: obtaining a third set of data from a second user device, wherein the third set of data includes a third data value and a corresponding third tag indicating a data type of the third data value; obtaining, from the data consuming device, a second request for a fourth set of data from the second user device; obtaining the fourth set of data; The third set of data and the fourth set of data are transmitted to the data consuming device for use under a second set of specified conditions.

22. The system of claim 1, wherein the computer memory is non-transitory computer memory.

23. An access control method, comprising: obtaining a first set of data from a first user device, wherein the first set of data comprises a first data value and a first tag indicating a data type of the first data value; transmitting a data type of the first data value of the first set of data to a data consuming device; obtaining, from the data consuming device, a first request for a second set of data from the first user device; obtaining the second set of data, wherein the second set of data comprises a second data value and a corresponding second tag indicating a data type of the second data value; as well as The first set of data and the second set of data are transmitted to the data consuming device for use under a first set of specified conditions.

24. The method of claim 23, further comprising: receiving a third set of data from the first user device, wherein the third set of data includes a third data value and a corresponding third tag indicating a data type of the third data value; as well as The third set of data from the first user device is stored with the first set of data and the second set of data.

25. The method of claim 24, further comprising: encrypting the first set of data for the first user device using a first key specific to the first user device; as well as The third set of data for the first user device is encrypted using a second key specific to the first user device, wherein the first key and the second key are different.

26. The method of claim 24 or claim 25, wherein the first set of data and the third set of data correspond to different information fields.

27. The method of claim 26, wherein each of the first set of data and the third set of data corresponds to a respective different field of information selected from the group consisting of: personally identifiable information, financial information, medical information, travel information, purchasing information, residential information, and demographic information.

28. The method of claim 23, wherein storing the first set of data from the first user device comprises storing the first set of data from the first user device in a database.

29. The method of claim 23, wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions comprises storing the first set of data and the second set of data on a distributed ledger.

30. The method of claim 23, wherein transmitting the first set of data and the second set of data to the data consuming device for use under the first set of specified conditions comprises storing results of a cryptographic function performed on the first set of data and the second set of data on a distributed ledger.

31. The method of claim 23, further comprising: In response to receiving the first request for the second set of data from the data consuming device, an electronic request for the second set of data is sent to the first user device.

32. The method of claim 31 , wherein the electronic request comprises a smart contract for controlling use of the first set of data and the second set of data by the data-consuming device, and The method further includes receiving an executed smart contract from the first user device in response to the smart contract sent in the electronic request.

33. The method of claim 23, wherein receiving the second set of data from the first user device comprises receiving a smart contract for the use of the first set of data and the second set of data.

34. The method of claim 31 , wherein the electronic request comprises at least one of an email, a web-based notification, and an application-based notification.

35. The method of claim 23, further comprising providing an incentive to a first user device for use of the first set of data and the second set of data under a first set of specified conditions, wherein the incentive comprises at least one of: currency, cryptocurrency, reward travel points, and store credit.

36. The method of claim 23, further comprising: receiving a notification of suspected illegal use of the first set of data and the second set of data under the executed smart contract; correlating the allegedly illegal use of the first set of data and the second set of data under the executed smart contract with other reported alleged illegal uses of other sets of data of users other than the first user device; as well as In response to the correlation, it is determined that the data-consuming device is a participant that is suspected of violating at least one of a threshold number and a threshold percentage of smart contracts used.

37. The method of claim 23, wherein transmitting the first set of data and the second set of data to the data-consuming device for use under a first set of specified conditions comprises executing a smart contract between the first user device and the data-consuming device using the first set of specified conditions.

38. The method of claim 23, wherein transmitting the first set of data and the second set of data to the data consuming device for use under the executed smart contract comprises temporarily decrypting the first set of data and the second set of data within a server; and The first set of data and the second set of data are transmitted to the data consuming device through an encrypted communication channel.

39. The method of claim 23, wherein transmitting the first set of data and the second set of data to the data consuming device for use under a first set of specified conditions comprises performing a cryptographic function on the first set of data and the second set of data; and The result of the cryptographic function is stored on a distributed ledger.

40. The method of claim 23, further comprising: obtaining a third set of data from a second user device, wherein the third set of data includes a third data value and a corresponding third tag indicating a data type of the third data value; obtaining, from the data consuming device, a second request for a fourth set of data from the second user device; obtaining the fourth set of data; The third set of data and the fourth set of data are transmitted to the data consuming device for use under a second set of specified conditions.

41. The method of claim 23, wherein the method is performed by a computer processor under the control of computer instructions stored in a computer memory.

42. The method of claim 23, wherein the method is performed by processing circuitry.

43. The method of claim 42, wherein the processing circuitry comprises any combination of: an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and a general purpose logic array (GAL).

44. The method of claim 24, further comprising: encrypting the first set of data for the first user device using a first key specific to a user of the first user device; as well as The third set of data for the first user device is encrypted using a second key specific to the user of the first user device, wherein the first key and the second key are different.

45. A computer-readable medium for storing instructions for controlling one or more processors to perform the method according to any one of claims 23 to 40 and 44.

46. A computer program product storing computer instructions that, when executed by one or more processors, control the one or more processors to perform operations comprising: obtaining a first set of data from a first user device, wherein the first set of data comprises a first data value and a corresponding first tag indicating a data type of the first data value; transmitting a data type of the first data value of the first set of data to a data consuming device; obtaining, from the data consuming device, a first request for a second set of data from the first user device; obtaining the second set of data, wherein the second set of data comprises a second data value and a corresponding second tag indicating a data type of the second data value; as well as The first set of data and the second set of data are transmitted to the data consuming device for use under a first set of specified conditions.

47. The computer program product of claim 46, wherein the computer program product is a non-volatile computer program product.

48. The computer program product of claim 46, wherein the computer program product is one of: an optical disk, a magnetic hard drive, and a solid-state memory device.

Images