Consent Provenance and Compliance Tracking over a Complex Consumer Data Supply Chain Using Blockchain Distributed Ledger

Abstract

The invention is a system based on decentralized ledgers to enable compliance with privacy regulations. A consumer identifier (consumer ID) allows consent provenance to be saved in a shared decentralized ledger. The consent ID also empowers consumers to query as to how their data has been moved through the data supply chain. The consumer data itself is not stored in the blockchain, only consents and data transfer events. A consent API allows companies to enter the original consumer consent in a consent ledger; a data transfer API allows companies to record transfers from one to another; and a subscription API allows companies to be notified of changes to a given consent.

Claims

1. A distributed ledger system for tracking consumer consent data, comprising: a. a plurality of consent ledgers, wherein each of the plurality of consent ledgers is communicationally connected to at least one other of the plurality of consent ledgers, wherein each of the plurality of consent ledgers each contain a plurality of consumer consent data, wherein the consumer consent data comprises data indicative of whether a consumer has consented to use of personal data concerning such consumer, and wherein each of the plurality of consent ledgers is configured to, upon receipt of consumer consent data, copy the consumer data to each of the other of the plurality of consent ledgers; b. a plurality of data transfer ledgers, wherein each of the plurality of data transfer ledgers is communicationally connected to at least one other of the plurality of consent ledgers, wherein each of the plurality of data transfer ledgers each contain a plurality of data transfer entries, and wherein each of the plurality of data transfer ledgers is configured to, upon receipt of a data transfer entry, copy the data transfer entry to each of the other of the plurality of data transfer ledgers; and c. a plurality of company servers, wherein each of the plurality of company servers is in communication with at least one of the plurality of consent ledgers and at least one of the plurality of data transfer ledgers.

2. The distributed ledger system of claim 1, further comprising a plurality of peer nodes, wherein one of the plurality of consent ledgers and one of the plurality of data transfer ledgers are implemented on each of the plurality of peer nodes.

3. The distributed ledger system of claim 2, further comprising a consent application node implemented on a ledger server with at least one of the plurality of peer nodes, wherein the consent application node is configured to receive an original consumer consent message from one of the plurality of company servers that has collected original consumer data, and to write a consumer consent to the one of the plurality of consent ledgers on such one of the peer nodes with which the consent application node is in communication.

4. The distributed ledger system of claim 3, further comprising a data transfer node implemented on a ledger server with at least one of the plurality of peer nodes, wherein the data transfer node is configured to receive data transfer data from one of the plurality of company servers that has received consumer data from another one of the plurality of company servers, and to write the data transfer data to one of the plurality of data transfer ledgers on such one of the peer nodes with which the data transfer node is in communication.

5. The distributed ledger system of claim 4, further comprising a subscription node implemented on a ledger server with at least one of the plurality of peer nodes, wherein the subscription node is configured to receive a subscription request from at least one of the plurality of company servers, and to send consumer out data, consumer change data, or both to the subscribing one of the plurality of company servers in response to a change at one of the plurality of peer nodes.

6. The distributed ledger system of claim 5, wherein the plurality of consumer consent data comprises a consent identifier (consent ID) uniquely corresponding with data pertaining to a particular consumer from a group of consumers.

7. The distributed ledger system of claim 6, wherein the plurality of consumer consent data comprises transfer events.

8. The distributed ledger system of claim 7, wherein the consumer consent data comprises no personally identifiable information (PII) concerning the consumer to whom the consumer consent data pertains.

9. The distributed ledger system of claim 8, wherein the consent application node, the data transfer node, and the subscription node, or any combination of them, are implemented as application programming interfaces (APIs).

10. The distributed ledger system of claim 9, further comprising a company-internal consent management system in communication with one or more of the consent application node, the data transfer node, and the subscription node.

11. The distributed ledger system of claim 10, further comprising a privacy portal in communication with one or more of the consent application node, the data transfer node, and the subscription node.

12. The distributed ledger system of claim 11, further comprising a regulator server in communication with one or more of the consent application node, the data transfer node, and the subscription node.

13. A method for propagating consumer consents through a distributed ledger system comprising a plurality of peer nodes, comprising the method steps of: a. at an original data server, collecting an item of consumer data and a consumer consent, wherein the consumer consent comprises data indicative of whether a consumer has consented to use of personal data concerning such consumer; b. calling a first consent application programming interface (API) at one of the plurality of peer nodes to enter the consumer consent and a consumer identifier (consumer ID) in a consent ledger at such peer node; c. syncing the consumer consent and consumer ID in the consent ledger at such peer node with each of the other peer nodes; d. transferring the consumer data from the original data server to a transferee server; e. calling a first data transfer API at one of the peer nodes to enter data transfer data into a data transfer ledger at such peer node; and f. syncing the data transfer data in the consent ledger at such peer node with each of the other peer nodes.

14. The method of propagating consumer consents of claim 13, further comprising the steps of: a. transferring the consumer data from the transferee server to an advertising server; b. calling a second data transfer API atone of the plurality of peer nodes to enter data transfer data into the data transfer ledger at such peer node; and c. syncing the data transfer data in the consent ledger at such peer node with each of the other peer nodes.

15. The method of propagating consumer consents of claim 14, further comprising the step of calling a third consent API at one of the plurality of peer nodes to retrieve the consumer consent from such node.

16. A method for consumer opting out, comprising the method steps of: a. at an original data server, receiving a consumer message requesting an opt out for use of consumer data pertaining to such consumer; b. calling a first consent application programming interface (API) at a first peer node of a plurality of peer nodes to enter the opt out and a consumer identifier (consumer ID) in a consent ledger at the first peer node, wherein the first peer node is one of the plurality of peer nodes forming a distributed peer node network; c. syncing the opt out in the consent ledger at the first peer node with each of the other peer nodes; d. detecting, at a second consent ledger at a second peer node using a second subscription API, that the consumer has opted out, and sending through the second subscription API to a transferee server an opt-out message, wherein the first peer node and the second peer node may be the same peer node; and e. detecting, at a third consent ledger at a third peer node and using a third subscription API, that the consumer has opted out, and sending through the third subscription API to an advertising server an opt-out message, wherein any or all of the first, second, and third peer nodes may be the same peer node.

17. The method for consumer opting out of claim 16, wherein if any of the second or third subscription APIs are down due to the second or third nodes being down, sending through a fourth subscription API at a fourth peer node an opt-out message, wherein the fourth peer node is a back-up node if the second or third peer nodes are down.

18. The method for consumer opting out of claim 17, further comprising the method steps of: a. receiving, at an advertising server, an audit request from a regulator server; and b. receiving, at a fifth peer node, the audit request from the regulator server and sending the audit request to a fifth consent application programming interface (API) in order to validate that all consumer data used by the advertising server has corresponding valid consent data, wherein the fifth peer node is one of a plurality of peer nodes forming a peer node network.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0017] FIG. 1 is a diagram illustrating the overall system architecture for certain implementations of the present invention.

[0018] FIG. 2 is a data flow diagram illustrating a method of propagating consents in certain implementations of the present invention.

[0019] FIG. 3 is a data flow diagram illustrating a method of revoking consents (opting out) in certain implementations of the present invention.

[0020] FIG. 4 is a data flow diagram illustrating a method of validating consents in certain implementations of the present invention.

DETAILED DESCRIPTION

[0021] An overall architecture for a system according to an implementation of the invention is shown in FIG. 1. The sample architecture in FIG. 1 shows the peer nodes 16, 18, 20, 22, and 24 (in this case there are five, but any number could be used) of the Hyperledger distributed ledger system, all connected to the fabric world state as implemented in the CouchDB database 26. The Rest API running on each of the peer nodes implements the Consent, Data Transfer, and Subscription APIs. The client applications 10, 12, and 14 (e.g., internal consent management systems, the privacy portals, and the regulator portals) call the API service on their preferred peer node; however, any peer node would provide the same functionality and could be used alternatively. In this sample implementation architecture, the client applications 10, 12, and 14 are written in node.js, but could be implemented using any technology that can invoke the Rest API of a peer node 16, 18, 20, 22, or 24. For more robust implementations, there would be API gateways and routing services between the client application and the Rest API service (not shown), but those are not necessary for the system to function.

[0022] Referring now to FIG. 2, the method by which consents are propagated through the system may be explained in accordance with an example. Note, each peer has the API service so calling any peer will work as the peer nodes will synchronize with each other in blockchain ledger fashion. At step 28, Company A's system collects consent from the relevant consumer and gathers consumer data. Company A's website calls the Consent API on the Peer node 16 to enter a new consent to the consent ledger. Peer node 16 uses a distributed ledger consensus protocol to sync with all other peer nodes on the distributed ledger, so that all nodes have the new consent.

[0023] At step 30, Company A sells and transfers data to company B. Company A's system calls the Data Transfer API on the Peer node 16 to enter the data transfer information in the data transfer ledger. The user consent ID is part of the data transfer entry. Peer node 16 uses distributed ledger consensus protocol to sync with all other peer nodes on the distributed ledger, so all nodes have the new data transfer entry.

[0024] At step 32, Company B sends data to Company C for an advertising campaign. Company B's system calls the Data Transfer API on the Peer node 16 to enter the data transfer information in the data transfer ledger. The consent ID is passed along into this new data transfer entry. Peer node 16 uses distributed ledger consensus protocol to sync with all other peer nodes on the distributed ledger, so all nodes have the new data transfer entry. After receiving the data, Company C then validates that explicit consumer consent is there to use the data for marketing purposes. In order to validate, Company C's system calls the Consent API on peer node 20 to look up the consent details and verify that the consent allows marketing purposes. It may be noted again that each of the peer nodes could perform this same functionality, and thus the calls just described to a peer node may be performed with respect to any peer node.

[0025] Referring now to FIG. 3, the method by which a consumer may opt out using the system may be described. The processing begins by consumer 34 contacting the company and requesting an opt-out. At step 36, Peer node 16 uses distributed ledger consensus protocol to sync with all other peer nodes on the distributed ledger, so all nodes now have revoked consent.

[0026] At step 38, the Subscription API On Peer node 18 detects that the consent has been revoked and sends a notification to Company B's system because previously Company B system had subscribed to notification for that consent.

[0027] At step 40, the Subscription API on peer node 20 detects that the consent has been revoked and sends a notification to Company C's system because previously Company C's system had subscribed to notification for that consent. It may be noted that using standard redundancy protocol, the Subscription API will have a primary and secondary peer node to ensure that one node being down will not cause notification not to be sent, but that the particular nodes that perform these functions may change.

[0028] Referring now to FIG. 4, the method by which the system may perform a regulator function by checking for compliance may be explained with reference to a particular example. Suppose that Company C is audited by the regulator. At step 42, the Company C system sends the requested data with associated consent IDs to the regulator. The regulator calls the Peer node 22 Consent API to validate that all data has valid consents. Peer node 22 then returns to the regular the requested validation data.

[0029] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the exemplary methods and materials are described herein.

[0030] All terms used herein should be interpreted in the broadest possible manner consistent with the context. When a grouping is used herein, all individual members of the group and all combinations and sub-combinations possible of the group are intended to be individually included in the disclosure. All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification. If a range is expressed herein, such range is intended to encompass and disclose all sub-ranges within that range and all particular points within that range.