Systems, methods, and computer program products for consent management

Abstract

Systems, methods, and computer program products for consent management are provided. A method may include: receiving a first data request for user data associated with a user, the user data being stored in a user data database; transmitting a consent request to the requestor system; receiving a consent response from the requestor system; storing consent data associated with the consent response for the user data requested in the first data request in an immutable ledger; receiving a consent verification request from the user data database, the consent verification request being based on a second data request from the requestor system to the user data database for the user data; verifying the consent verification request based on the consent data; and transmitting a consent verification response to the user data database, the consent verification response indicating that the user consents to sharing the user data with the requestor system.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application Nos. 63 / 238,945 filed on August 31, 2021 and 63 / 314,744 filed on February 28, 2022, the disclosures of which are incorporated herein by reference in their entireties. Technical Field

[0003] The present invention relates to managing consent to share and / or use user data and / or take actions on behalf of users, and in non-limiting embodiments or aspects, to systems, methods, and computer program products for managing consent to share and / or use user data and / or take actions on behalf of users through an automated consent platform. Background Art

[0004] In recent years, there has been a growing concern about the misuse of users' personal data. Several new laws have been enacted around the world to provide users with more oversight over how their data is used. However, the burden is increasingly borne by users themselves, as they grant permissions to various websites but have little ability to verify how their data is used, nor can they easily change where, how, and by whom their data is used. In addition, each individual data holder (e.g., resource provider, website, etc.) must store and track the permissions granted to it by each user. Therefore, there is a need for a method to consolidate permissions to improve efficiency, reduce redundancy and / or utilization of computing resources, improve the security of user data, allow review and / or audit of granted consents, enable modification of consents, promote consistency, and enable traceability of data usage. Summary of the invention

[0005] According to some non-limiting embodiments or aspects, a method is provided, comprising: receiving, by a consent database, a first data request for user data associated with a user from a requestor system, the user data being stored in a user data database separate from the consent database; transmitting, by the consent database, the consent request to the requestor system for display to the user on a user device associated with the user; receiving, by the consent database, a consent response from the requestor system based on input from the user device, the consent response indicating that the user agrees to share the user data requested in the first data request; storing, by the consent database, consent data associated with the consent response to the user data requested in the first data request in an immutable ledger; receiving, by the consent database, a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verifying, by the consent database, the consent verification request based on the consent data stored in the immutable ledger; and transmitting, by the consent database, a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user agrees to share the user data from the user data database with the requestor system.

[0006] In some non-limiting embodiments or aspects, the method may further include: receiving, by the consent database, utilization data associated with consent to use user data from the requestor system; and storing, by the consent database, the utilization data associated with the user data in the immutable ledger. The method may further include: receiving, by the consent database, allocation data associated with data access to the user data from the requestor system from the user data database; and storing, by the consent database, the allocation data associated with the user data in the immutable ledger. The method may further include: comparing, by the consent database, the allocation data associated with the user data and the consent data associated with the user data; determining, by the consent database, compliance of the allocation data with the conditions of the consent data; and storing, by the consent database, an indication of compliance of the allocation data in the immutable ledger.

[0007] In some non-limiting embodiments or aspects, the method may further include: comparing, by the consent database, utilization data associated with the user data and consent data associated with the user data; determining, by the consent database, compliance of the utilization data with conditions of the consent data; and storing, by the consent database, an indication of compliance of the utilization data in the immutable ledger. The method may further include: receiving, by the consent database, an audit request associated with the user data from the user data database; and transmitting, by the consent database, an indication of compliance of the utilization data associated with the user data to the user data database.

[0008] In some non-limiting embodiments or aspects, the method may also include: receiving, by the consent database, a revocation request for consent associated with the user data from the user device; updating, by the consent database, the consent response based on the revocation request; and transmitting, by the consent database, the updated consent response to the user data database.

[0009] According to a non-limiting embodiment or aspect, a system for managing consent is provided, the system comprising at least one server computer, the at least one server computer comprising at least one processor, the at least one server computer being programmed and / or configured to: receive a first data request for user data associated with a user from a requester system, the user data being stored in a user data database separate from a consent database; transmit the consent request to the requester system for display to the user on a user device associated with the user; receive a consent response from the requester system based on input from the user device, the consent response indicating that the user agrees to share the user data requested in the first data request; store consent data associated with the consent response to the user data requested in the first data request in an immutable ledger; receive a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requester system to the user data database; verify the consent verification request based on the consent data stored in the immutable ledger; and transmit a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user agrees to share the user data from the user data database with the requester system.

[0010] In some non-limiting embodiments or aspects, the at least one server computer is programmed and / or configured to: receive utilization data associated with consent to use user data from the requester system; and store the utilization data associated with the user data in the immutable ledger. The at least one server computer may be programmed and / or configured to: receive allocation data associated with accessing the user data from the requester system data from the user data database; and store the allocation data associated with the user data in the immutable ledger. The at least one server computer may be programmed and / or configured to: compare the allocation data associated with the user data with the consent data associated with the user data; determine compliance of the allocation data with the conditions of the consent data; and store an indication of compliance of the allocation data in the immutable ledger.

[0011] In some non-limiting embodiments or aspects, the at least one server computer is programmed and / or configured to: compare utilization data associated with the user data with consent data associated with the user data; determine compliance of the utilization data with conditions of the consent data; and store an indication of compliance of the utilization data in the immutable ledger. The at least one server computer may be programmed and / or configured to: receive an audit request associated with the user data from the user data database; and transmit an indication of compliance of the utilization data associated with the user data to the user data database.

[0012] In some non-limiting embodiments or aspects, the at least one server computer may be programmed and / or configured to: receive a revocation request for consent associated with the user data from the user device; update the consent response based on the revocation request; and transmit the updated consent response to the user data database.

[0013] According to a non-limiting embodiment or aspect, a computer program product is provided, comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium including one or more program instructions, the one or more program instructions, when executed by at least one processor, causing the at least one processor to: receive a first data request for user data associated with a user from a requestor system, the user data being stored in a user data database separate from a consent database; transmit a consent request to the requestor system for display to the user on a user device associated with the user; receive a consent response from the requestor system based on input from the user device, the consent response indicating that the user agrees to share the user data requested in the first data request; store consent data associated with the consent response for the user data requested in the first data request in an immutable ledger; receive a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verify the consent verification request based on the consent data stored in the immutable ledger; and transmit a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user agrees to share the user data from the user data database with the requestor system.

[0014] In some non-limiting embodiments or aspects, the one or more program instructions may further cause the at least one processor to: receive utilization data associated with consent to use user data from the requestor system; and store the utilization data associated with the user data in the immutable ledger. The one or more program instructions may further cause the at least one processor to: receive allocation data associated with accessing the user data from the requestor system data from the user data database; and store the allocation data associated with the user data in the immutable ledger. The one or more program instructions may further cause the at least one processor to: compare the allocation data associated with the user data with the consent data associated with the user data; determine compliance of the allocation data with the conditions of the consent data; and store an indication of compliance of the allocation data in the immutable ledger.

[0015] In some non-limiting embodiments or aspects, the one or more program instructions may further cause the at least one processor to: compare utilization data associated with the user data with consent data associated with the user data; determine compliance of the utilization data with a condition of the consent data; and store an indication of compliance of the utilization data in the immutable ledger. The one or more program instructions may further cause the at least one processor to: receive an audit request associated with the user data from the user data database; and transmit an indication of compliance of the utilization data associated with the user data to the user data database.

[0016] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: receiving, by a consent service system, a data request for user data associated with a user from a consent requester system, wherein the user data is stored in a resource provider system, and wherein the data request includes a consent beneficiary system identifier associated with a consent beneficiary system; receiving, by the consent service system, an identification token, wherein the identification token authenticates the identity of the user associated with the data request; transmitting, by the consent service system, a consent token request to a consent ledger system, wherein the consent token request includes the identification token, the beneficiary system identifier, and data associated with the data request; generating, by the consent ledger system, a consent token associated with the consent token request and the user; transmitting, by the consent ledger system, the consent token to the consent requester system; receiving, by the resource provider system, the consent token; and transmitting, by the resource provider system, the user data associated with the consent token to the consent beneficiary system.

[0017] In some non-limiting embodiments or aspects, the consent requestor system includes at least one of the consent beneficiary system, the consent presenter system, or any combination thereof.

[0018] In some non-limiting embodiments or aspects, the consent presenter system may receive a service request from the user via a graphical user interface displayed on a user device of the user. Additionally or alternatively, the consent presenter system may transmit the service request to the consent beneficiary system. Additionally or alternatively, the consent beneficiary system may transmit the data request to the consent requester system based on receiving the service request.

[0019] In some non-limiting embodiments or aspects, the data request includes at least one consent item associated with the user data, wherein each consent item in the at least one consent item includes at least one of the following: consent item type data associated with the type of the consent item; duration data associated with the duration of the consent item; time range data associated with the time range of the consent item; frequency data associated with how often the consent item will be requested; time span data associated with the time span of the consent item; consent state data associated with the state of the consent item; consent status data associated with the status of the consent item; primary purpose data associated with at least one primary purpose for which the consent item will be used; secondary purpose data associated with at least one secondary purpose for which the consent item will be used, the at least one secondary purpose being different from the at least one primary purpose; or any combination thereof.

[0020] In some non-limiting embodiments or aspects, the consent service system may transmit the data request to a consent directory service system. Additionally or alternatively, the consent service system may receive resource provider identification data associated with at least one resource provider system storing the user data, the at least one resource provider system including the resource provider system. Additionally or alternatively, the consent service system may transmit the resource provider identification data to the consent requester system.

[0021] In some non-limiting embodiments or aspects, the consent service system may receive resource provider selection data associated with a resource provider system in the at least one resource provider system. Additionally or alternatively, the consent service system may transmit the resource provider selection data to the consent directory service system. Additionally or alternatively, the consent service system may receive identity provider identification data associated with at least one identity provider system authorized to authenticate the identity of the user. Additionally or alternatively, the consent service system may transmit the identity provider identification data to the consent requester system.

[0022] In some non-limiting embodiments or aspects, an identity provider system of the at least one identity provider system may generate the identification token based on receiving authentication data from the user.

[0023] In some non-limiting embodiments or aspects, receiving the identification token may include receiving, by the consent service system, a consent request from the consent requestor system. Additionally or alternatively, the consent request may include the identification token and at least one consent item associated with the user data. Additionally or alternatively, each consent item may include at least one of the beneficiary system identification, data associated with the data request, or any combination thereof.

[0024] In some non-limiting embodiments or aspects, transmitting the consent token request may include transmitting, by the consent service system, the consent request to the consent ledger system.

[0025] In some non-limiting embodiments or aspects, generating a consent token may include generating, by the consent ledger system, the consent token based on the consent request. Additionally or alternatively, transmitting the consent token to the consent requester system may include transmitting, by the consent ledger system, the consent token to the consent service system, and / or transmitting, by the consent service system, the consent token to the consent requester system.

[0026] In some non-limiting embodiments or aspects, the consent requester system may transmit the consent token to the consent beneficiary system. Additionally or alternatively, the consent beneficiary system may store the consent token. Additionally or alternatively, the consent beneficiary system may transmit the consent token to the resource provider system.

[0027] In some non-limiting embodiments or aspects, the resource provider system may transmit a token verification request to the consent service system based on the consent token. Additionally or alternatively, the resource provider system may receive a token verification response indicating that the consent token is valid.

[0028] In some non-limiting embodiments or aspects, transmitting the user data to the consent beneficiary system may include transmitting, by the resource provider system, at least one consent value for each of the at least one consent item. Additionally or alternatively, each consent value may include at least a portion of the user data.

[0029] According to non-limiting embodiments or aspects, a system is provided, including a resource provider system, a consent ledger system, and a consent service system. The consent service system may be configured to receive a data request for user data associated with a user from a consent requester system. The user data may be stored in a resource provider system. The data request may include a consent beneficiary system identifier associated with a consent beneficiary system. The consent service system may be configured to receive an identification token. The identification token may authenticate the identity of the user associated with the data request. The consent service system may be configured to transmit a consent token request to a consent ledger system. The consent token request may include the identification token, the beneficiary system identifier, and / or data associated with the data request. The consent ledger system may be configured to generate a consent token associated with the consent token request and the user. The consent ledger system may be configured to transmit the consent token to the consent requester system. The resource provider system may be configured to receive the consent token. The resource provider system may be configured to transmit the user data associated with the consent token to the consent beneficiary system.

[0030] According to a non-limiting embodiment or aspect, a computer program product is provided, the computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions, the one or more instructions, when executed by at least one processor, may cause the at least one processor to: receive, by a consent service system, a data request for user data associated with a user from a consent requestor system. The user data may be stored in a resource provider system. The data request may include a consent beneficiary system identifier associated with a consent beneficiary system. The one or more instructions, when executed by the at least one processor, may cause the at least one processor to: receive, by the consent service system, an identification token. The identification token may authenticate the identity of the user associated with the data request. The one or more instructions, when executed by the at least one processor, may cause the at least one processor to: transmit, by the consent service system, a consent token request to a consent ledger system. The consent token request may include the identification token, the beneficiary system identifier, and data associated with the data request. The one or more instructions, when executed by the at least one processor, may cause the at least one processor to: generate, by the consent ledger system, a consent token associated with the consent token request and the user. The one or more instructions, when executed by the at least one processor, may cause the at least one processor to: transmit the consent token by the consent ledger system to the consent requester system. The one or more instructions, when executed by the at least one processor, may cause the at least one processor to: receive the consent token by the resource provider system. The one or more instructions, when executed by the at least one processor, may cause the at least one processor to: transmit user data associated with the consent token by the resource provider system to the consent beneficiary system.

[0031] According to a non-limiting embodiment or aspect, a system is provided, comprising at least one processor and at least one non-volatile computer-readable medium, wherein the at least one non-volatile computer-readable medium comprises one or more instructions that, when executed by the at least one processor, instruct the at least one processor to perform any of the methods described herein.

[0032] According to a non-limiting embodiment or aspect, a computer program product is provided, comprising at least one non-transitory computer-readable medium, wherein the at least one non-transitory computer-readable medium comprises one or more instructions, which when executed by at least one processor causes the at least one processor to perform any method described herein.

[0033] Additional embodiments or aspects are set forth in the following numbered clauses:

[0034] Clause 1: A computer-implemented method, comprising: receiving, by a consent database, a first data request for user data associated with a user from a requestor system, the user data being stored in a user data database separate from the consent database; transmitting, by the consent database, the consent request to the requestor system for display to the user on a user device associated with the user; receiving, by the consent database, a consent response from the requestor system based on input from the user device, the consent response indicating that the user agrees to share the user data requested in the first data request; storing, by the consent database, consent data associated with the consent response to the user data requested in the first data request in an immutable ledger; receiving, by the consent database, a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verifying, by the consent database, the consent verification request based on the consent data stored in the immutable ledger; and transmitting, by the consent database, a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user agrees to share the user data from the user data database with the requestor system.

[0035] Clause 2: The method according to clause 1 further includes: receiving, by the consent database, utilization data associated with consent to use user data from the requester system; and storing, by the consent database, the utilization data associated with the user data in the immutable ledger.

[0036] Clause 3: The method according to clause 1 or clause 2 further includes: receiving, by the consent database, allocation data associated with accessing the user data from the requester system data from the user data database; and storing, by the consent database, the allocation data associated with the user data in the immutable ledger.

[0037] Clause 4: The method according to any one of clauses 1-3 further includes: the consent database comparing the allocation data associated with the user data and the consent data associated with the user data; the consent database determining the compliance of the allocation data with the conditions of the consent data; and the consent database storing an indication of the compliance of the allocation data in the immutable ledger.

[0038] Clause 5: The method according to any one of clauses 1-4 further includes: the consent database comparing utilization data associated with the user data and consent data associated with the user data; the consent database determining compliance of the utilization data with the conditions of the consent data; and the consent database storing an indication of the compliance of the utilization data in the immutable ledger.

[0039] Clause 6: The method according to any one of clauses 1-5 further includes: receiving, by the consent database, an audit request associated with the user data from the user data database; and transmitting, by the consent database, an indication of compliance of utilization data associated with the user data to the user data database.

[0040] Clause 7: The method according to any one of clauses 1-6 further includes: the consent database receiving a revocation request for consent associated with the user data from the user device; the consent database updating the consent response based on the revocation request; and the consent database transmitting the updated consent response to the user data database.

[0041] Clause 8: A system for managing consent, the system comprising at least one server computer, the at least one server computer comprising at least one processor, the at least one server computer being programmed and / or configured to: receive a first data request for user data associated with a user from a requestor system, the user data being stored in a user data database separate from a consent database; transmit the consent request to the requestor system for display to the user on a user device associated with the user; receive a consent response from the requestor system based on input from the user device, the consent response indicating that the user agrees to share the user data requested in the first data request; store consent data associated with the consent response to the user data requested in the first data request in an immutable ledger; receive a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verify the consent verification request based on the consent data stored in the immutable ledger; and transmit a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user agrees to share the user data from the user data database with the requestor system.

[0042] Clause 9: The system of clause 8, wherein the at least one server computer is programmed and / or configured to: receive utilization data associated with consent to use user data from the requestor system; and store the utilization data associated with the user data in the immutable ledger.

[0043] Clause 10: A system according to clause 8 or clause 9, wherein the at least one server computer is programmed and / or configured to: receive allocation data associated with accessing the user data from the requester system data from the user data database; and store the allocation data associated with the user data in the immutable ledger.

[0044] Clause 11: A system according to any of clauses 8-10, wherein the at least one server computer is programmed and / or configured to: compare allocation data associated with the user data and consent data associated with the user data; determine compliance of the allocation data with conditions of the consent data; and store an indication of compliance of the allocation data in the immutable ledger.

[0045] Clause 12: A system according to any of clauses 8-11, wherein the at least one server computer is programmed and / or configured to: compare utilization data associated with the user data and consent data associated with the user data; determine compliance of the utilization data with conditions of the consent data; and store an indication of compliance of the utilization data in the immutable ledger.

[0046] Clause 13: A system according to any of clauses 8-12, wherein the at least one server computer is programmed and / or configured to: receive an audit request associated with the user data from the user data database; and transmit an indication of compliance of utilization data associated with the user data to the user data database.

[0047] Clause 14: A system according to any of clauses 8-13, wherein the at least one server computer is programmed and / or configured to: receive a revocation request for consent associated with the user data from the user device; update the consent response based on the revocation request; and transmit the updated consent response to the user data database.

[0048] Clause 15: A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium including one or more program instructions that, when executed by at least one processor, cause the at least one processor to: receive a first data request for user data associated with a user from a requestor system, the user data being stored in a user data database separate from a consent database; transmit a consent request to the requestor system for display to the user on a user device associated with the user; receive a consent response from the requestor system based on input from the user device, the consent response indicating that the user consents to sharing the user data requested in the first data request; store consent data associated with the consent response for the user data requested in the first data request in an immutable ledger; receive a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verify the consent verification request based on the consent data stored in the immutable ledger; and transmit a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user consents to sharing the user data from the user data database with the requestor system.

[0049] Clause 16: A computer program product according to clause 14 or clause 15, wherein the one or more program instructions further cause the at least one processor to: receive utilization data associated with consent to use user data from the requestor system; and store the utilization data associated with the user data in the immutable ledger.

[0050] Clause 17: A computer program product according to any of clauses 14-16, wherein the one or more program instructions further cause the at least one processor to: receive from the user data database allocation data associated with accessing the user data from the requester system data; and store the allocation data associated with the user data in the immutable ledger.

[0051] Clause 18: A computer program product according to any of clauses 14-17, wherein the one or more program instructions further cause the at least one processor to: compare allocation data associated with the user data and consent data associated with the user data; determine compliance of the allocation data with conditions of the consent data; and store an indication of compliance of the allocation data in the immutable ledger.

[0052] Clause 19: A computer program product according to any of clauses 14-18, wherein the one or more program instructions further cause the at least one processor to: compare utilization data associated with the user data and consent data associated with the user data; determine compliance of the utilization data with conditions of the consent data; and store an indication of compliance of the utilization data in the immutable ledger.

[0053] Clause 20: A computer program product according to any one of clauses 14-19, wherein the one or more program instructions further cause the at least one processor to: receive an audit request associated with the user data from the user data database; and transmit an indication of compliance of utilization data associated with the user data to the user data database.

[0054] Clause 21: A computer-implemented method, comprising: receiving, by a consent service system, a data request for user data associated with a user from a consent requestor system, wherein the user data is stored in a resource provider system, and wherein the data request includes a consent beneficiary system identifier associated with a consent beneficiary system; receiving, by the consent service system, an identification token, wherein the identification token authenticates the identity of the user associated with the data request; transmitting, by the consent service system, a consent token request to a consent ledger system, wherein the consent token request includes the identification token, the beneficiary system identifier, and data associated with the data request; generating, by the consent ledger system, a consent token associated with the consent token request and the user; transmitting, by the consent ledger system, the consent token to the consent requester system; receiving, by the resource provider system, the consent token; and transmitting, by the resource provider system, the user data associated with the consent token to the consent beneficiary system.

[0055] Clause 22: The method of clause 21, wherein the consent requestor system comprises at least one of the consent beneficiary system, the consent presenter system, or any combination thereof.

[0056] Clause 23: The method according to Clause 21 or Clause 22 also includes: receiving a service request from a user by a consent presenter system via a graphical user interface displayed on a user device of the user; transmitting the service request to the consent beneficiary system by the consent presenter system; and transmitting the data request to the consent requester system by the consent beneficiary system based on receiving the service request.

[0057] Clause 24: A method according to any one of clauses 21-23, wherein the data request includes at least one consent item associated with the user data, wherein each consent item in the at least one consent item includes at least one of the following: consent item type data associated with the type of the consent item; duration data associated with the duration of the consent item; time range data associated with the time range of the consent item; frequency data associated with how often the consent item will be requested; time span data associated with the time span of the consent item; consent state data associated with the state of the consent item; consent status data associated with the status of the consent item; primary purpose data associated with at least one primary purpose for which the consent item will be used; secondary purpose data associated with at least one secondary purpose for which the consent item will be used, the at least one secondary purpose being different from the at least one primary purpose; or any combination thereof.

[0058] Clause 25: The method according to any one of Clauses 21-24 further includes: the consent service system transmitting the data request to the consent directory service system; the consent service system receiving resource provider identification data associated with at least one resource provider system storing the user data, the at least one resource provider system including the resource provider system; and the consent service system transmitting the resource provider identification data to the consent requester system.

[0059] Clause 26: The method according to any one of Clauses 21-25 further includes: the consent service system receiving resource provider selection data associated with a resource provider system in the at least one resource provider system; the consent service system transmitting the resource provider selection data to the consent directory service system; the consent service system receiving identity provider identification data associated with at least one identity provider system authorized to authenticate the identity of the user; and the consent service system transmitting the identity provider identification data to the consent requester system.

[0060] Clause 27: The method of any of clauses 21-26, wherein an identity provider system of the at least one identity provider system generates the identification token based on receiving authentication data from the user.

[0061] Clause 28: A method according to any one of clauses 21-27, wherein receiving the identification token includes receiving a consent request by the consent service system from the consent requester system, wherein the consent request includes the identification token and at least one consent item associated with the user data, wherein each consent item includes at least one of the beneficiary system identification, data associated with the data request, or any combination thereof.

[0062] Clause 29: The method of any of clauses 21-28, wherein transmitting the consent token request comprises transmitting, by the consent service system, the consent request to the consent ledger system.

[0063] Clause 30: A method according to any one of clauses 21-29, wherein generating the consent token includes generating the consent token by the consent ledger system based on the consent request, and wherein transmitting the consent token to the consent requester system includes: transmitting the consent token by the consent ledger system to the consent service system; and transmitting the consent token by the consent service system to the consent requester system.

[0064] Clause 31: The method according to any one of clauses 21-30 further includes: transmitting the consent token by the consent requester system to the consent beneficiary system; storing the consent token by the consent beneficiary system; and transmitting the consent token by the consent beneficiary system to the resource provider system.

[0065] Clause 32: The method according to any one of clauses 21-31 further includes: the resource provider system transmitting a token verification request to the consent service system based on the consent token; and the resource provider system receiving a token verification response indicating that the consent token is valid.

[0066] Clause 33: A method according to any one of clauses 21-32, wherein transmitting the user data to the consent beneficiary system includes transmitting by the resource provider system at least one consent value for each consent item in the at least one consent item, each consent value including at least a portion of the user data.

[0067] Clause 34: A system comprising: a resource provider system; a consent ledger system; and a consent service system, wherein the consent service system is configured to: receive a data request for user data associated with a user from a consent requester system, wherein the user data is stored in the resource provider system, and wherein the data request includes a consent beneficiary system identifier associated with a consent beneficiary system; receive an identification token, wherein the identification token authenticates the identity of the user associated with the data request; and transmit a consent token request to the consent ledger system, wherein the consent token request includes the identification token, the beneficiary system identifier, and data associated with the data request; wherein the consent ledger system is configured to: generate a consent token associated with the consent token request and the user; and transmit the consent token to the consent requester system; wherein the resource provider system is configured to: receive the consent token; and transmit the user data associated with the consent token to the consent beneficiary system.

[0068] Clause 35: A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions, which when executed by at least one processor cause the at least one processor to: receive, by a consent service system, a data request for user data associated with a user from a consent requestor system, wherein the user data is stored in a resource provider system, and wherein the data request includes a consent beneficiary system identifier associated with a consent beneficiary system; receive, by the consent service system, an identification token, wherein the identification token authenticates the identity of the user associated with the data request; transmit, by the consent service system, a consent token request to a consent ledger system, wherein the consent token request includes the identification token, the beneficiary system identifier, and data associated with the data request; generate, by the consent ledger system, a consent token associated with the consent token request and the user; transmit, by the consent ledger system, the consent token to the consent requestor system; receive, by the resource provider system, the consent token; and transmit, by the resource provider system, the user data associated with the consent token to the consent beneficiary system.

[0069] Clause 36: A system comprising: at least one processor; and at least one non-volatile computer-readable medium, wherein the at least one non-volatile computer-readable medium comprises one or more instructions, wherein the one or more instructions, when executed by the at least one processor, instruct the at least one processor to perform a method according to any one of clauses 1-7 or 21-33.

[0070] Clause 37: A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions which, when executed by at least one processor, cause the at least one processor to perform a method according to any one of clauses 1-7 or 21-33.

[0071] These and other features and characteristics of the present invention and the methods of operation and functions of the combinations of related structural elements and parts and the manufacturing economy will become more apparent after considering the following description and the appended claims with reference to the accompanying drawings, all of which form part of this specification, wherein like reference numerals indicate corresponding parts in the various figures. However, it should be expressly understood that the drawings are for illustration and description purposes only and are not intended to be a definition of limitations of the present invention. Unless the context clearly dictates otherwise, when used in this specification and claims, the singular forms "a", "an", and "said" include multiple referents. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Additional advantages and details are explained in more detail below with reference to exemplary embodiments shown in the schematic drawings, in which:

[0073] Figure 1A is a schematic diagram of an exemplary system for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter;

[0074] Figures 1B-1F is a swim lane diagram of an exemplary process for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter;

[0075] Figure 2A is a schematic diagram of an exemplary system for consent management in accordance with the principles of the presently disclosed subject matter;

[0076] Figure 2B-2E is a swim lane diagram of an exemplary process for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter;

[0077] Figure 3 is a schematic diagram of an exemplary computing device according to a non-limiting embodiment or aspect of the presently disclosed subject matter;

[0078] Figure 4A and 4B is a screenshot of an exemplary graphical user interface according to a non-limiting embodiment or aspect of the presently disclosed subject matter; and

[0079] Figure 5 is a flow chart of an exemplary process for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter; and

[0080] Figure 6 is a flow chart of an exemplary process for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter. DETAILED DESCRIPTION

[0081] For the purposes of the following description, the terms "end", "upper", "lower", "right", "left", "vertical", "horizontal", "top", "bottom", "lateral", "longitudinal" and their derivatives shall relate to the orientation of the embodiments in the accompanying drawings. However, it shall be understood that the embodiments may employ various alternative variations and step sequences, except where expressly specified to the contrary. It shall also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the present invention. Accordingly, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein shall not be considered limiting.

[0082] The aspects, parts, elements, structures, actions, steps, functions, instructions, etc. used herein should not be understood as critical or necessary unless explicitly described as such. Also, as used herein, the article "one" is intended to include one or more items, and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one item, the term "one" or similar language is used. Also, as used herein, the term "having" and the like are intended to be open terms. In addition, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on".

[0083] As used herein, the terms "communication" and "transmission" may refer to the reception, acceptance, transmission, transmission, provision, etc. of information (e.g., data, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicating with another unit means that the unit is able to directly or indirectly receive information from the other unit and / or send information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, etc.) that is wired and / or wireless in nature. In addition, although the information sent can be modified, processed, relayed and / or routed between the first unit and the second unit, the two units may also communicate with each other. For example, even if the first unit passively receives information and does not actively send information to the second unit, the first unit may communicate with the second unit. As another example, if at least one intermediate unit (e.g., a third unit located between the first unit and the second unit) processes the information received from the first unit and transmits the processed information to the second unit, the first unit may communicate with the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (eg, a data packet and / or the like) that includes data. It should be appreciated that many other arrangements are possible.

[0084] As used herein, the term "mobile device" may refer to one or more portable electronic devices configured to communicate with one or more networks. As an example, a mobile device may include a cellular phone (e.g., a smart phone or a standard cellular phone), a portable computer (e.g., a tablet computer, a laptop computer, etc.), a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. As used herein, the term "client device" refers to any electronic device configured to communicate with one or more servers or remote devices and / or systems. Client devices may include mobile devices, network-enabled appliances (e.g., network-enabled televisions, refrigerators, thermostats, etc.), computers, point-of-sale (POS) systems, and / or any other device or system capable of communicating with a network.

[0085] As used herein, the term "computing device" may refer to one or more electronic devices configured to communicate directly or indirectly with one or more networks or communicate through one or more networks. The computing device may be a mobile device. In other non-limiting embodiments or aspects, the computing device may be a desktop computer, a server, a server group or other non-mobile computers. In addition, the term "computer" may refer to any computing device including necessary components for receiving, processing and outputting data and generally including a display, a processor, a memory, an input device and a network interface. The term "application" may refer to computer code or other data sorted on a computer-readable medium, which may be executed by a processor to facilitate interaction between software components, such as interaction of a client-side front end and / or a server-side back end to receive data from a client. The term "interface" may refer to a generated display, such as one or more graphical user interfaces (GUIs), and a user may interact with the GUI directly or indirectly (e.g., via a keyboard, a mouse, etc.).

[0086] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communications and processing by multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and that there may be various other arrangements. In addition, multiple computing devices (e.g., servers, point of sale (POS) devices, mobile devices, etc.) that communicate directly or indirectly in a network environment may constitute a "system." As used herein, references to "servers" or "processors" may refer to previously described servers and / or processors, different servers and / or processors, and / or combinations of servers and / or processors stated as implementing previous steps or functions. For example, as used in the specification and claims, a first server and / or first processor stated as implementing a first step or function may refer to the same or different servers and / or processors stated as implementing a second step or function.

[0087] As used herein, the term "system" may refer to one or more computing devices or combinations of computing devices, such as, but not limited to, processors, servers, client devices, software applications, and / or other similar components.

[0088] As used herein, the term "account data" refers to any data about one or more accounts of one or more users. Account data may include, for example, one or more account identifiers, user identifiers, transaction history, balances, credit limits, issuer institution identifiers, etc.

[0089] As used herein, the term "token" may refer to a data structure and / or identifier used to authenticate another identifier and / or used as a substitute or replacement for another identifier. As used herein, the term "payment token" may refer to an account identifier used as a substitute or replacement for another account identifier (e.g., a primary account number (PAN)). A payment token may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, etc.) so that the payment token can be used to conduct payment transactions without directly using the original account identifier. In some non-limiting embodiments or aspects, an original account identifier such as a PAN may be associated with multiple payment tokens for different individuals or purposes. In some non-limiting embodiments or aspects, a payment token may be associated with a PAN or other account identifier in one or more data structures so that the payment token can be used to conduct transactions without directly using a PAN or other account identifier. In some instances, an original account identifier such as a PAN may be associated with multiple payment tokens for different uses or purposes.

[0090] The non-limiting embodiments or aspects described herein relate to a system, method and computer program product for consent management. Currently, when a user decides to grant permission to use the data stored in an entity (e.g., a provider and / or holder of such data), each provider of the user data and each user of the user data must track and store the consent granted or denied by each user. This makes it difficult for users to record their user data because it may be difficult to determine who has been granted permission. Users do not have any easy way to determine whether their data is used in a manner consistent with their consent. There may be an event in which a user needs to quickly revoke consent to specific user data to prevent such data from being abused. However, having to contact each provider or recipient of the data may make the user data vulnerable due to the time required to contact multiple entities and the increased possibility that at least one provider or recipient of the data may be ignored. The non-limiting embodiments or aspects described herein provide a unique arrangement and architecture that allows management of user consent. User consent is stored in a centralized consent database, allowing users to determine all consents granted by the user and the users to whom the consent is granted. This database is accessible by the provider of the user data and the requester of the user data. This reduces the amount of computing resources required for data requesters and providers because they no longer have to store and maintain each user's own consent. As a result, user data is more secure because providers are less likely to provide data to unauthorized users because the entity that tracks the user's consent is separate from the provider of the data that benefits from sharing the data. The consent database can also be an immutable ledger, which improves the security of user data by ensuring that a single entity cannot change consent without the user's knowledge. The security of user data is also improved by allowing users to quickly identify all consents in a single location. In the event that a particular aspect of a user's data is compromised or otherwise becomes a concern, the user is able to quickly identify all requesters who have access to the user's data and all providers who can provide the user's data and communicate the revocation of any consent provided to the user's data. Due to the rapid nature of online communications, the ability to quickly revoke consent is necessary to ensure increased security of user data. Consistency of consent also improves the security of user data. By standardizing the representation of consent, users are able to more easily understand what permissions the user has granted, rather than trying to understand dozens of different formats from dozens of different requesters or providers. It also creates increased efficiency for both provider systems and requester systems. Instead of a provider system or requester system needing to interpret dozens or hundreds of different formats of data requests, which may result in interpretation errors, a standardized format has the ability to increase the automation of requests by requiring requesters and providers to only deal with a single format. The ability to automate requests reduces the computing resources and human resources required to interpret data requests, thereby making the processing of user data faster and more secure.Non-limiting embodiments or aspects described herein enable actions to be taken on behalf of a user (e.g., in addition to, in lieu of, or as part of sharing and / or using user data), such as enabling at least one device and / or system to perform an action based on the user's consent (e.g., unlocking a smart lock on a door to allow a delivery to be placed inside, allowing a connected car to initiate a proximity-based payment, etc.).

[0091] Reference now Figure 1A , shows a system 100 for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter. System 100 includes a consent database 102, a requester system 104, a user device 106, and a user data database 108. The consent database 102, the requester system 104, the user device 106, and the user data database 108 may each include one or more computing devices configured to communicate via one or more communication networks, such as communication network 112. In a non-limiting embodiment or aspect, the consent database 102 may be a component of the consent system or may be a separate system. In a non-limiting embodiment or aspect, the user data database 108 may be a component of a data holder (e.g., resource provider) system or may be a separate system.

[0092] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, a requester may transmit a data use request to the consent database 102 through its requester system 104. The requester may use the system 100 to access the user's consent data for its own business purposes.

[0093] The data use request may include one or more data components associated with the specific data that the requester is seeking. This may include one or more data fields (e.g., data types, such as geographic location, transactions, payment history, event time, online activities, websites visited, etc.). The data components may also include one or more data holders (e.g., entities / individuals / companies / participants / servers, etc. that store data) and / or one or more data recipients (e.g., entities / individuals / companies / participants / servers, etc. that will receive data). The data recipient may be the data requester, or may be a third party to whom the requester wishes to transfer data or to whom data may be transferred. Additional data components may include at least one data field (e.g., data type), one or more purposes for using the requested data, one or more quantities of the requested data, one or more durations of the request, one or more frequencies of the request, etc.

[0094] The purpose of the requested data may include an intended use of the data associated with at least one user. The data use request may include a textual explanation of the intended use. The textual explanation may include a sentence or paragraph providing a concise explanation of the intended use.

[0095] The amount of data requested may include a date range in which the data was generated or occurred (e.g., all data available between August 1, 2015 and September 15, 2018; all data available from September 1, 2020 to the present; all data starting from now, etc.), the number of data entries (e.g., 200 entries, 1000 entries, etc.), the size of the data (e.g., 1GB of data, 100GB of data, 1TB of data, etc.), and the like.

[0096] At least one frequency may state how often the data requester wishes to access the data (e.g., daily, monthly, annually, etc.). A frequency may be one-time. More than one frequency may be included, and they may be associated with different data components. For example, if two purposes are included and two different durations are included, a different frequency may be associated with each purpose, each duration, and / or different combinations of the purposes and durations.

[0097] The duration may include the number of times the data may be accessed (e.g., a single access, 20 accesses, 100 accesses, etc.) and / or the period of time during which the data may be accessed (e.g., one month after permission is granted, until June 12, 2023, until permission is revoked, etc.). More than one duration may be included, and they may be associated with different data components. For example, if two purposes are included and two different frequencies are included, a different duration may be associated with each purpose, each frequency, and / or different combinations of the purposes and the frequencies.

[0098] In some non-limiting embodiments or aspects, components of a data usage request, such as data holder, data field, purpose, amount, duration, frequency, and data recipient, can be determined based on a textual interpretation of the intended use. These components can be determined based on the textual interpretation by artificial intelligence or a keyword database.

[0099] Continue to refer Figure 1AIn certain non-limiting embodiments or aspects, the requester system 104 may communicate with the consent database 102 via a data requester portal 120. The data requester portal 120 may be displayed to the requester and / or data holder via a user interface (UI) service. The data requester portal 120 may be hosted on a server (e.g., a server operated by the consent database 102, the consent system, or a third party). The data requester portal 120 may facilitate communication between the consent database 102, the requester system 104, and the user data database 108. The data requester portal 120 may facilitate data sharing between the requester system 104 and the user data database 108 based on permissions granted by the user and stored in the consent database 102.

[0100] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, the requestor system 104 may transmit a data use request through a data requestor portal 120. The requestor system 104 may set up a desired data sharing use case (e.g., a data use request) through the data requestor portal 120. The requestor system 104 may select and / or describe the user data to which it is requesting access. The requestor may enter information or make selections through the data requester portal 120 accessed through the requestor system 104, through a keyboard, mouse, trackpad, etc. The data use request may be automatically processed by the requestor system 104. The requestor system 104 may transmit at least one data holder, at least one data field, at least one purpose, at least one amount, at least one duration, at least one frequency, and at least one user of the data.

[0101] Continue to refer Figure 1A In some non-limiting embodiments or aspects, the data requester portal 120 can allow for standardization of data requests from requesters. Such standardization can make it easier to understand and distinguish between requesters and the use of data. In some non-limiting embodiments or aspects, the UI design of the data requester portal 120 can be different based on the type of requester or the type of data being sought.

[0102] Continue to refer Figure 1A In some non-limiting embodiments or aspects, the consent database 102 may receive a data use request and determine whether the data use request meets predetermined criteria. The predetermined criteria may require that the data use request include at least one data component or a certain number of data components. The predetermined criteria may require a list of all predetermined data components. The data use request may include additional information beyond what is required by the criteria. In some non-limiting embodiments or aspects, the predetermined criteria may depend on one of the components, such as a data field.

[0103] Continue to refer Figure 1AIn certain non-limiting embodiments or aspects, if the data use request does not meet the predetermined criteria, the data use request may be denied. The consent database 102 may communicate the denial to the requestor system 104. The denial may be communicated via the data requestor portal 120. The denial may include a reason for the denial, such as a task component, an invalid entry, or an entry out of range.

[0104] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, if the data use request meets predetermined criteria, the data use request may be accepted. The consent database 102 may communicate the acceptance to the requestor system 104. The acceptance may be communicated through the data requestor portal 120.

[0105] Continue to refer Figure 1A In some non-limiting embodiments or aspects, if the data use request is accepted, the consent database 102 may store the components of the data use request in the consent database 102. The consent database 102 may initiate communication with the user based on the data use request to obtain consent. The consent database 102 may communicate with the user through a user device 106 associated with the user. The user contacted may depend on the components of the data use request. For example, if the data request includes a specific data holder and a specific data type, the consent database 102 may communicate with each user who has the data type at the data holder in response to receiving the data use request. Users who have the data type at the data holder may be determined based on the data included in the consent database, including registered users with registered accounts associated with the data holder.

[0106] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, the consent database 102 can communicate with the user device 106 through a consumer portal 122. The user device 106 can be selected by a user. The consumer portal 122 can include a UI displayed through the user device 106. The consumer portal 122 can be hosted by the consent system, the consent database 102, the requester system 104, the user data database 108, and / or the data holder system. If the consumer portal 122 is hosted by the requester system 104, the UI can utilize JavaScript object representation (JSON) from the consent system or the consent database 102.

[0107] Continue to refer Figure 1AIn some non-limiting embodiments or aspects, the consumer portal 122 can be hosted by the consent database 102, and the consent database 102 can transmit the consumer portal 122 to the requester system 104. The user can receive a notification to access the consumer portal 122. The notification can be transmitted from the requester system 104 or the consent database 102. The notification can be transmitted to a user device 106 associated with the user. The user can access the consumer portal 122 through the user device 106.

[0108] Continue to refer Figure 1A In some non-limiting embodiments or aspects, the consumer portal 122 may present a user with a selection of permissions for user data. The consumer portal 122 may display data components associated with a data use request. Each data component may be displayed to provide the user with a comprehensive understanding of what data is being requested, who is requesting the data, and how the data is being used. The consumer portal 122 may provide a unified presentation of data components to ensure a consistent and clear experience regarding granting or denying permissions related to data access. Each data use request may be presented to the user in a similar or identical format to ensure that the user understands the request compared to other requests. The data components presented to the user through the consumer portal 122 may include data holders, data fields, purposes, amounts, durations, frequencies, data requesters, and the like.

[0109] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, a user may enter a usage response into the consumer portal 122 via a user device 106 associated with a data usage request. The usage response may include an indication that the requestor's proposed usage is allowed or not allowed. The user may enter an acceptance response to the usage, such as opt-in, approve, allow, accept, etc., to indicate that the user will allow the usage as described by the data request. The user may also enter a rejection response to the usage, such as opt-out, deny, refuse, object, etc.

[0110] Continue to refer Figure 1AIn certain non-limiting embodiments or aspects, a user may enter a data transfer response into the consumer portal 122 via a user device 106 associated with a data use request. The data transfer response may indicate the manner in which the data will be shared between the requester and the data holder. The data may be shared by a requester system 104 or a third-party system that accesses data from and downloads data from the user data database 108 (e.g., the requester system 104 may pull data from the user data database 108). The data may also be shared by a user data database 108 that transmits the data to the requester system 104 or a third-party system (e.g., the user data database 108 pushes the data to the requester system 104). The user may select push data and / or pull data as acceptable data transfer methods in the data transfer response.

[0111] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, a user may enter an access response into the consumer portal 122 via a user device 106 associated with a data use request. The access response may indicate the rights of the requestor system 104 or a third party to change the user's data. The user may choose to provide only read access. Read access may allow the requestor system 104 or a third party to receive the data and process the data. The user may choose to provide write access. Write access may allow the requestor system 104 or a third party to receive the data, process the data, and change the data. Changing the data may include adding data to the database, deleting data from the database, or changing data in the database.

[0112] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, the consent database 102 may receive consent response data from a user. The requester system 104 may transmit the consent response data to the consent database 102. The user device 106 may transmit the consent response data to the consent database 102 via the consumer portal 122. The consent response data may include a use response, a data transfer response, and / or an access response. The consent database 102 may compare the consent response data with a validation requirement. The validation requirement may be a predetermined set of criteria for the consent response data. If the consent response data does not meet the validation requirements, the consent database 102 may transmit a rejection to the requester system 104.

[0113] Continue to refer Figure 1AIn some non-limiting embodiments or aspects, if the consent response data meets the verification requirements, the consent database 102 may encode the consent response data. Encoding the consent response data may include tokenizing any sensitive information (e.g., PAN, social security number, etc.). The consent database 102 may attach encoding details to each data element of the consent response data. The de-identified encoding results may be stored in the consent database 102. The consent database 102 may then publish the encoded consent response data to an immutable ledger. In some non-limiting embodiments or aspects, an immutable ledger may include a ledger and / or database in which the data stored cannot be changed (or cannot be easily changed). For example, an immutable ledger may include a blockchain, a version control database, an append-only database, etc.

[0114] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, the requester system 104 can transmit a data request to the user data database 108. The data request can be transmitted through the data requester portal 120 or through the communication network 112. The data request can include at least one component of a data usage request, such as at least one data holder, at least one data field, at least one purpose, at least one amount, at least one duration, at least one frequency, and / or at least one user of the data.

[0115] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, in response to receiving a data request, the user data database 108 may transmit a consent verification based on the data request to the consent database 102. The consent verification may be transmitted via the data requester portal 120 or via the communication network 112. The consent verification may include at least one component of the data request (e.g., at least one data holder, at least one data field, at least one purpose, at least one amount, at least one duration, at least one frequency, and / or at least one user of the data). The consent verification may ensure that the user has granted appropriate permissions that will allow the user data database 108 to share the user data with the requester system 104 based on the components of the data request.

[0116] Continue to refer Figure 1AIn certain non-limiting embodiments or aspects, in response to receiving the consent verification, the consent database 102 may compare the components of the consent verification to the encoded consent stored in the immutable ledger. If the encoded consent does not match the consent verification (e.g., the user does not agree to share data with the requester, share the requested amount of data, share data for the requested duration, share data at the requested frequency, share data for the above purposes, and / or share data from the data holder), the consent database 102 may transmit a rejection of the consent verification to the user data database 108 and / or the requester system 104. The rejection of the consent verification may include which component of the consent verification violates the user's consent. The consent database 102 may initiate a consent coordination review between the user data database 108 and the requester system 104 to determine what changes need to be made to the data request to satisfy the user's consent requirements.

[0117] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, if the consent verification matches the coded consent, the consent database 102 may transmit the completion verification to the user data database 108. The completion verification may indicate that the user has provided appropriate consent to allow the transmission of data as described in the consent verification. In response to receiving the completion verification, the user data database 108 may fulfill the data request. The user data database 108 may transmit the data as described in the data request to the requestor system 104. The data may be transmitted via the data requester portal 120 or the communication network 112. The consent database 102 may provide a direct connection between the requestor system 104 and the user data database 108 supported by at least one application programming interface (API) to support the transmission of data between the user data database 108 and the requestor system 104. The data may be transmitted by the user data database 108 pushing the data to the requestor system 104 or the requestor system 104 pulling the data from the user data database 108. In response to fulfilling the data request, the user data database 108 may transmit a record of the data request fulfillment to the consent database. The fulfillment record may include the transmission time, transmission method, and transmission component. The implemented records may be transmitted via the data requester portal 120 or the communication network 112 .

[0118] Continue to refer Figure 1AIn certain non-limiting embodiments or aspects, a user may manage consent and revoke consent through the consumer portal 122. The user may access the consumer portal 122 at any time. The consumer portal 122 may display all permissions associated with the user. These permissions may include all permissions for user data sharing that are granted and / or denied. At any time, the user may manage, grant and / or revoke permissions for all or individual data holders and / or requesters. The user may update consent through the consumer portal 122 using the user device 106. The updated consent may be transmitted directly or indirectly to the consent database 102. The updated consent may be transmitted to the host of the consumer portal 122, and the host may transmit the updated consent to the consent database 102.

[0119] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, when a user intends to manage consents for data associated with the user, the user may access the consumer portal 122 through their user device 106. The user device 106 may communicate a management request to the consent database 102, the requestor system 104 associated with the user's data, and the user data database 108 associated with the user's data. The management request may indicate that the user wishes to review the consents associated with their account. In response to receiving the management request, the requestor system 104 and the user data database 108 may communicate a user consent request to the consent database 102. The user consent request may include user device identification data identifying the user device 106 associated with the user or other identification information of the user.

[0120] Continue to refer Figure 1A In some non-limiting embodiments or aspects, if the consent database 102 hosts the consumer portal 122, the consent database 102 may transmit the UI of the consumer portal 122 to the user device 106. The consent database 102 may transmit the encoded consumer consent selection associated with the user to the requestor system 104 and the user data database 108 associated with the user. In response to receiving the encoded consumer consent selection, the requestor system 104 and the user data database 108 may transmit the encoded consumer consent selection to the consumer portal 122. In some non-limiting embodiments or aspects, the consent database 102 may transmit the encoded consumer consent selection directly to the consumer portal 122. In response to receiving the encoded consumer consent selection, the consumer portal 122 may display the consent selection to the user through the UI of the consumer portal 122 on the user device 106.

[0121] Continue to refer Figure 1AIn some non-limiting embodiments or aspects, after the consent selection is displayed to the user, the user can change the presented consent. The user can interact with the UI of the consumer portal 122 through the user device 106 to add, revoke, change and / or perform similar operations on consents associated with the user. Changes to consents can be transmitted to the associated requestor system 104 and / or data user database 108. In response to receiving the changes to the consents, the requestor system 104 and / or the user data database 108 can transmit the changes to the consent database 102. In some non-limiting embodiments or aspects, the changes can be transmitted from the consumer portal 122 to the consent database 102.

[0122] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, in response to receiving a consent change, the consent database 102 may encode the consent change. Encoding the consent change may include tokenizing any sensitive information (e.g., PAN, social security number, etc.). The consent database 102 may append the encoding details to each data element of the consent change. The de-identified encoding results may be stored in the consent database 102. The consent database 102 may then publish the encoded consent change data to the immutable ledger.

[0123] Continue to refer Figure 1A In some non-limiting embodiments or aspects, after the consent database 102 updates the immutable ledger, the consent database 102 may transmit the encoded consumer consent selection to the user data database 108 and the requester system 104. In response to receiving the updated encoded consumer consent selection, the user data database 108 and the requester system 104 may transmit the consent selection to the consumer portal 122, which will display the updated selection to the user via the user device 106. If the updated encoded consumer consent selection includes revoking consent, the requester system 104 or the user data database 108 may transmit a verification message regarding the revoked consent.

[0124] Continue to refer Figure 1AIn certain non-limiting embodiments or aspects, a user, data holder, or third party (e.g., an auditor system or a regulatory system) may request and initiate an audit of consent selections and data usage. A user may initiate an audit through a user device 106 through a consumer portal 122. A data holder may initiate an audit through a user data database 108 through a data requester portal 120. A third party may initiate an audit through a consumer portal 122, a requester portal 120, or may communicate with the consent database 102. An audit request may ensure that data is used only in accordance with the permissions granted by the user. An audit request may include one or more users, requesters, and / or data holders. An audit request may ensure that all data associated with a user, requester, and / or data holder included in the audit request is used appropriately (e.g., in accordance with the permissions of the associated user). An audit request may be transmitted to any requester system 104 associated with data associated with a requesting user or a requesting data holder. An audit request may be transmitted to a requester system through a consumer portal 122 or a data requester portal 120. The user data database 108 and / or the requester system 104 may transmit an audit request to the consent database 102. In some non-limiting embodiments or aspects, a user may transmit an audit request to the consent database 102 through the consumer portal 122 .

[0125] Continue to refer Figure 1A In certain non-limiting embodiments or aspects, in response to receiving an audit request, the consent database 102 may initiate an audit. The consent database 102 may pull all associated encoded consent data from the immutable ledger associated with the user, requester, and / or data holder included in the audit request. The consent database 102 may initiate data tracking for all associated requester systems 104. The data tracking may determine each use of data from the user data database 108 by each requester system 104. The consent database 102 may transmit a data tracking request to each requester system 104. The data tracking request may include at least one user associated with user data from the user data database 108, at least one user data database 108, at least one requester system 104, a time period of data to be tracked, and / or an amount of data to be tracked. In response to receiving the data tracking request, the requester system 104 may transmit a record of each use of the user data associated with the data tracking request. The consent database 102 may compare the record of each use with the encoded consent data to ensure that the record of each use does not violate the requirements of the encoded consent data. The consent database 102 may communicate the comparison results in the audit report to the consumer or data holder via the consumer portal 122 or the data requester portal 120 .

[0126] Continue to refer Figure 1AIn a non-limiting embodiment or aspect, a single digital identifier can be associated with a user across multiple platforms. The user can consent to the digital identifier through the consumer portal 122, and the consent of the digital identifier can be transmitted to the consent database 102.

[0127] Figure 1A The number and arrangement of systems and devices shown in are provided as examples. Additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, and / or devices may be present. Figure 1A In addition, the system and / or device may be implemented in a single system or device. Figure 1A two or more systems or devices shown in, or Figure 1A The single system or device shown in the figure may be implemented as multiple distributed systems or devices. In addition or alternatively, a group of systems (e.g., one or more systems) or a group of devices (e.g., one or more devices) of the system 100 can perform one or more functions described as being performed by another group of systems or another group of devices of the system 100.

[0128] refer to Figure 1B and Figure 1C , a process 100a for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 100a can be performed by consent database 102 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 100a can be performed by another system, another device, another group of systems, or another group of devices (e.g., requester system 104, user device 106, and / or user data database 108) that is separate from or includes consent database 102 (e.g., completely, partially, etc.). Figure 1B and Figure 1C The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects.

[0129] like Figure 1B As shown in , at step 131, process 100a may include transmitting at least one initial data request for user data. For example, consent database 102 may receive an initial data request for user data associated with a user from requestor system 104. In some non-limiting embodiments or aspects, the user data may be stored in user data database 108, which is separate from consent database 102.

[0130] In some non-limiting embodiments or aspects, the initial data request may include at least one consent use case. For example, the requester system 104 may transmit the initial data request including the consent use case to the consent database 102. For example, the consent use case may include primary purpose data associated with at least one primary purpose for which the user data will be used (e.g., usage data required to provide at least one service to the user). Additionally or alternatively, the consent use case may include at least one secondary purpose data associated with at least one secondary purpose for which the user data will be used. For example, the secondary purpose may be different from the primary purpose.

[0131] like Figure 1B As shown in , at step 132, process 100a may include transmitting an initial response to the initial data request. For example, consent database 102 may transmit an initial response to requestor system 104 based on the initial data request.

[0132] In some non-limiting embodiments or aspects, the initial response may indicate that the initial data request (and / or its consent use case) does not meet the consent criteria. For example, the consent database 102 may determine that the consent use case (e.g., primary purpose, secondary purpose, etc.) does not meet the consent criteria (e.g., is not a permitted purpose, lacks sufficient information, etc.). In some non-limiting embodiments or aspects, if the initial response indicates that the initial data request does not meet the consent criteria, the process 100a may stop.

[0133] In some non-limiting embodiments or aspects, the initial response may indicate that the initial data request (and / or its consent use case) is verified. For example, the consent database 102 may determine that the consent use case (e.g., primary purpose, secondary purpose, etc.) meets the consent criteria (e.g., is a permitted purpose, includes sufficient information, etc.). In some non-limiting embodiments or aspects, if the consent use case request meets the consent criteria, the process 100a may proceed to step 133.

[0134] like Figure 1B As shown in FIG. 1 , at step 133 , process 100 a can include transmitting a consent request. For example, consent database 102 can transmit the consent request to requestor system 104 .

[0135] In some non-limiting embodiments or aspects, the consent request may include a hosted consent interface. For example, the consent database 102 may transmit the hosted consent interface (e.g., a UI, a GUI, at least one web page, etc.) to the requestor system 104. In some non-limiting embodiments or aspects, the consent database 102 may transmit at least one JSON message to the requestor system 104 to render the hosted consent interface. For example, the JSON message may include at least one JSON object associated with at least one graphical element (e.g., a button, a checkbox, a drop-down menu, a text box, etc.) and / or at least one field for the consent request.

[0136] like Figure 1B As shown in FIG. 1 , at step 141 , process 100a may include initiating a consent experience. For example, user device 106 may initiate a consent experience with requester system 104 .

[0137] In some non-limiting embodiments or aspects, initiating the consent experience may include the user device 106 receiving input from a user to request at least one service from the requestor system 104. For example, as described herein, a service may be associated with at least one consent use case.

[0138] like Figure 1B As shown in FIG. 1 , at step 142 , process 100 a can include transmitting the consent request. For example, requester system 104 can transmit the consent request to user device 106 .

[0139] In some non-limiting embodiments or aspects, as described herein, the consent request may include a hosted consent interface. Additionally or alternatively, the user device 106 may display the hosted consent interface. For example, the requester system 104 may transmit the hosted consent interface to the user device 106, which may display the hosted consent interface.

[0140] like Figure 1B As shown in , at step 143, process 100a may include transmitting a consent response. For example, user device 106 may transmit the consent response to requester system 104. In some non-limiting embodiments or aspects, the consent response may indicate that the user agrees to share the user data requested in the initial data request.

[0141] In some non-limiting embodiments or aspects, transmitting the consent response may include the user device 106 receiving input from the user indicating that the user agrees to share the user data. For example, the user may select at least one graphical element (e.g., a button, a checkbox, a drop-down menu, a text box, etc.) of a hosted consent interface (e.g., a UI, a GUI, etc.) to indicate consent to share the requested user data. In some non-limiting embodiments or aspects, based on the user input, the user device 106 may transmit the consent response to the requester system 104.

[0142] like Figure 1B As shown in , at step 144, process 100a may include transmitting a consent response. For example, requester system 104 may transmit the consent response to consent database 102. In some non-limiting embodiments or aspects, as described herein, the consent response may indicate that the user agrees to share the user data requested in the initial data request.

[0143] In some non-limiting embodiments or aspects, the consent response may be validated by the consent database 102. If the consent response does not meet the validation requirements (e.g., cannot be validated), the process 100a may proceed to step 145. If the consent response does meet the validation requirements, the process 100a may proceed to step 146.

[0144] like Figure 1B As shown in FIG. 1 , at step 145, process 100a can include communicating based on the consent response. For example, consent database 102 can transmit at least one communication with requestor system 104 based on the consent response.

[0145] In some non-limiting embodiments or aspects, at least one communication may include an indication that the consent response does not meet the verification requirements (e.g., cannot be verified). In some non-limiting embodiments or aspects, if at least one communication indicates that the consent response does not meet the verification requirements, process 100a may stop.

[0146] In some non-limiting embodiments or aspects, at least one communication may include an indication that the consent response does satisfy the verification requirements. In some non-limiting embodiments or aspects, if at least one communication indicates that the consent response does satisfy the verification requirements, process 100a may proceed to step 146.

[0147] like Figure 1B As shown in , at step 146, process 100a can include storing consent data. For example, consent database 102 can store consent data associated with a consent response (e.g., for user data requested in the initial data request). In some non-limiting embodiments or aspects, as described herein, storing the consent data can include storing the consent data in an immutable ledger.

[0148] In some non-limiting embodiments or aspects, storing the consent data may include encoding at least a portion of the data from the consent response to provide at least a portion of the consent data. For example, the consent database 102 may encode (at least a portion of) the consent response data. The encoding may include tokenizing any sensitive information (e.g., PAN, social security number, etc.). Additionally or alternatively, the encoding may include (e.g., by the consent database 102) appending encoding details to each data element of the consent response data to form (at least a portion of) the consent data. In some non-limiting embodiments or aspects, the de-identified results of the encoding may be stored in the consent database 102 (e.g., stored in a metrics database of the consent database 102). In some non-limiting embodiments or aspects, as described herein, the consent database 102 may publish the consent data (e.g., encoded consent response data) to an immutable ledger.

[0149] like Figure 1B As shown in , at step 151, process 100a may include transmitting a data request to a user data database. For example, requestor system 104 may transmit a (second) data request to user data database 108. In some non-limiting embodiments or aspects, the (second) data request transmitted from requestor system 104 to user data database 108 may be for user data associated with the user (e.g., the same user data requested by the initial data request). Additionally or alternatively, the (second) data request may include an indication that the user has consented to user data database 108 sharing the user data with requestor system 104.

[0150] like Figure 1B As shown in , at step 152, process 100a may include transmitting a consent verification request. For example, user data database 108 may transmit the consent verification request to consent database 102. In some non-limiting embodiments or aspects, the consent verification request may be based on a (second) data request for user data received by user data database 108.

[0151] In some non-limiting embodiments or aspects, consent database 102 may receive a consent verification request from user data database 108 .

[0152] like Figure 1B As shown in , at step 153, process 100a may include verifying the consent verification request. For example, consent database 102 may verify the consent verification request based on (stored) stored consent data (e.g., consent data stored in an immutable ledger).

[0153] In some non-limiting embodiments or aspects, verifying the consent verification request may include determining (eg, by consent database 102 ) whether the consent verification matches (stored) consent data.

[0154] like Figure 1B As shown in , at step 154, process 100a may include transmitting a consent verification response. For example, consent database 102 may transmit a consent verification response to user data database 108 based on verifying the consent verification request to the user data database. In some non-limiting embodiments or aspects, the consent verification response may indicate that the user consents to share user data from user data database 108 with requestor system 104.

[0155] In some non-limiting embodiments or aspects, if the consent verification matches the (stored) consent data, the consent verification response (e.g., transmitted by the consent database 102) may indicate that the consent verification request is verified. For example, the consent database 102 may transmit a consent verification response indicating that the consent verification request is verified (e.g., verification completed) to the user data database 108. The consent verification request (e.g., verification completed) may indicate that the user has provided appropriate consent to allow the transfer of the requested user data as described in the consent verification request.

[0156] like Figure 1C As shown in FIG. 1 , at step 155 , process 100 a may include transmitting a record of the fulfillment of the (second) data request. For example, user data database 108 may transmit a record of the fulfillment of the (second) data request to consent database 102 .

[0157] In some non-limiting embodiments or aspects, the user data database 108 may transmit a record of the fulfillment of the (second) data request in response to receiving the consent verification response.

[0158] In some non-limiting embodiments or aspects, the user data database 108 may transmit a record of the implementation of the (second) data request in response to transmitting the user data to the requester system 104, as described below with respect to step 156 (e.g., step 155 may be subsequent to step 156).

[0159] In some non-limiting embodiments or aspects, the record of the implementation of the (second) data request may include a transmission time (eg, the time to transmit the user data to the requester system 104), a transmission method, a transmission component, any combination thereof, and the like.

[0160] like Figure 1C As shown in FIG. 1 , at step 156 , process 100 a may include transmitting the user data from the user data database to the requester system. For example, user data database 108 may transmit the user data to requester system 104 .

[0161] In some non-limiting embodiments or aspects, in response to receiving the consent verification response, the user data database 108 may fulfill the (second) data request by transmitting the user data (eg, as requested in the second data request) to the requestor system 104 .

[0162] In some non-limiting embodiments or aspects, as described herein, the consent database 102 can provide a direct connection between the requestor system 104 and the user data database 108 supported by at least one API.

[0163] refer to Figure 1D , showing a process 100b for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter. In some non-limiting embodiments or aspects, one or more steps of process 100b can be performed by consent database 102 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 100b can be performed by another system, another device, another group of systems, or another group of devices (e.g., requester system 104, user device 106, and / or user data database 108) that is separate from or includes consent database 102 (e.g., completely, partially, etc.). Figure 1D The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects. Figure 1D The dashed lines shown in the drawings illustrate additional or alternative actions that may be performed at each step.

[0164] like Figure 1D As shown in FIG. 1 , process 100b may include transmitting a consent management request at step 161. For example, user device 106 may transmit a consent management request to user data database 108 (and / or requester system 104).

[0165] In some non-limiting embodiments or aspects, the consent management request may include a user identifier of the user.

[0166] In some non-limiting embodiments or aspects, the user device 106 may receive input from the user indicating that the user intends to initiate a consent management request. In response to receiving such input, the user device 106 may transmit the consent management request to the user data database 108 (and / or the requester system 104).

[0167] like Figure 1D As shown in FIG. 1 , at step 162 , process 100 b may include transmitting the consent management request to the consent database. For example, user data database 108 (and / or requester system 104 ) may transmit the consent management request to consent database 102 .

[0168] In some non-limiting embodiments or aspects, consent database 102 may look up consent data associated with the user that is stored by consent database 102. For example, consent database 102 may look up consent data associated with the user based on a user identifier.

[0169] like Figure 1D As shown in , at step 163, process 100b may include transmitting consent selection data associated with the consent data. For example, consent database 102 may transmit consent selection data associated with the user's consent data to user data database 108 (and / or requester system 104).

[0170] In some non-limiting embodiments or aspects, the consent selection data may include a list identifying each item of user data that the user consents to be shared from the user data database 108 (and / or to the requester system 104 ).

[0171] In some non-limiting embodiments or aspects, the consent selection data may include a hosted consent management interface. For example, the consent database 102 may transmit the hosted consent management interface (e.g., a UI, a GUI, at least one web page, etc.) to the user data database 108 (and / or the requester system 104). In some non-limiting embodiments or aspects, the consent database 102 may transmit at least one JSON message to the user data database 108 (and / or the requester system 104) to render the hosted consent management interface. For example, the JSON message may include at least a JSON object associated with at least one graphical element (e.g., a button, a checkbox, a drop-down menu, a text box, etc.) and / or at least one field for a list of items of user data that the user consents to be shared from the user data database 108 (and / or shared to the requester system 104).

[0172] like Figure 1D As shown in , at step 164, process 100b may include transmitting consent selection data associated with the consent data to the user device. For example, user data database 108 (and / or requester system 104) may transmit consent selection data associated with the user's consent data to user device 106.

[0173] In some non-limiting embodiments or aspects, as described herein, the consent selection data can include a hosted consent management interface. Additionally or alternatively, the user device 106 can display a hosted consent management interface.

[0174] like Figure 1DAs shown in FIG. 1 , process 100b may include transmitting a consent modification request at step 165. For example, user device 106 may transmit a consent modification request to user data database 108 (and / or requester system 104).

[0175] In some non-limiting embodiments or aspects, the consent modification request may include a revocation request. For example, the user device 106 may receive input from a user indicating that the user is revoking consent to share the user data. In response to receiving such input, the user device 106 may transmit a revocation request (e.g., indicating that the user is revoking consent associated with the user data) to the user data database 108 (and / or the requestor system 104).

[0176] In some non-limiting embodiments or aspects, the consent modification request may include a modification of at least one attribute of the consent to share user data (e.g., rather than completely withdrawing consent). For example, a user may consent to share user data for a primary purpose, but withdraw consent to share user data for a secondary purpose. As another example, a user may consent to share user data for a duration different from the original selection (e.g., a longer duration, a shorter duration, etc.).

[0177] like Figure 1D As shown in , at step 166, process 100b may include transmitting the consent modification request to the consent database. For example, user data database 108 (and / or requester system 104) may transmit the consent modification request to consent database 102.

[0178] like Figure 1D As shown in , at step 167, process 100b may include updating the consent data based on the consent modification request. For example, consent database 102 may update the consent data (eg, consent data associated with the consent response stored by consent database 102) based on the consent modification request.

[0179] In some non-limiting embodiments or aspects, if the consent data is stored in an immutable ledger, updating the consent data may include storing the additional consent data in the immutable ledger (e.g., adding a new data record including the additional consent data to the immutable ledger). For example, the additional consent data may indicate that the consent represented by the (originally stored) consent data has been modified, and / or may indicate a modification to the (originally stored) consent data. Thus, the immutable ledger still contains the (originally stored and / or unmodified) consent data and the additional consent data.

[0180] In some non-limiting embodiments or aspects, if the consent data is not stored in the immutable ledger, updating the consent data may include modifying the consent data based on the consent modification request.

[0181] In some non-limiting embodiments or aspects, if the consent modification request includes a revocation request, updating the consent data may include revoking consent to share the user data.

[0182] like Figure 1D As shown in , process 100b may include transmitting an updated consent response at step 168. For example, consent database 102 may transmit an updated consent response to user data database 108 (and / or requester system 104) based on the updated consent data.

[0183] In some non-limiting embodiments or aspects, the user data database 108 may modify and / or revoke its sharing of the user data (and / or the requester system 104 may modify and / or revoke its use of the user data) based on the updated consent response.

[0184] like Figure 1D As shown in , at step 169, process 100b may include transmitting data to the user device based on the updated consent response. For example, user data database 108 (and / or requester system 104) may transmit data to user device 106 based on the updated consent response.

[0185] In some non-limiting embodiments or aspects, the data based on the updated consent response may include an update to the hosted consent management interface. Additionally or alternatively, the user device 106 may display an update to the hosted consent management interface. For example, the update to the hosted consent management interface may indicate that the consent has been successfully modified and / or revoked.

[0186] refer to Figure 1E , a process 100c for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 100c can be performed by consent database 102 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 100c can be performed by another system, another device, another group of systems, or another group of devices (e.g., requester system 104, user device 106, and / or user data database 108) that is separate from or includes consent database 102 (e.g., completely, partially, etc.). Figure 1E The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects. Figure 1E The dashed lines shown in the drawings illustrate additional or alternative actions that may be performed at each step.

[0187] like Figure 1EAs shown in , at step 171, process 100c may include initiating an audit. For example, user device 106 (and / or user data database 108) may initiate an audit. In some non-limiting embodiments or aspects, initiating an audit may include transmitting an audit request from user device 106 to user data database 108 (and / or requester system 104). In some non-limiting embodiments or aspects, user data database 108 may initiate an audit independent of user device 106.

[0188] In some non-limiting embodiments or aspects, user device 106 may receive input from a user indicating that the user intends to initiate an audit. In response to receiving such input, user device 106 may transmit an audit request to user data database 108 (and / or requester system 104) to initiate an audit.

[0189] like Figure 1E As shown in FIG. 1 , at step 172 , process 100 c may include transmitting the audit request to the consent database. For example, user data database 108 (and / or requester system 104 ) may transmit the audit request to consent database 102 .

[0190] like Figure 1E As shown in , at step 173, process 100c may include retrieving consent data. For example, consent database 102 may retrieve consent data associated with the user from a storage device (e.g., an immutable ledger).

[0191] In some non-limiting embodiments or aspects, consent database 102 may determine a list of each item of user data that the user consented to be shared based on the retrieved consent data.

[0192] like Figure 1E As shown in FIG. 1 , at step 174, process 100c may include requesting utilization data. For example, consent database 102 may request utilization data from requestor system 104 (and / or user data database 108). The utilization data may be associated with the use of user data by requestor system 104 (and / or user data database 108).

[0193] like Figure 1E As shown in FIG. 1 , process 100c may include requesting to receive utilization data at step 175. For example, consent database 102 may receive utilization data from requestor system 104 (and / or user data database 108).

[0194] like Figure 1EAs shown in , at step 176, process 100c may include storing and / or analyzing utilization data. For example, consent database 102 may store utilization data. In some non-limiting embodiments or aspects, consent database 102 may store utilization data associated with user data in an immutable ledger.

[0195] In some non-limiting embodiments or aspects, analyzing the utilization data may include comparing the utilization data to the consent data (e.g., by the consent database 102). For example, the consent database 102 may determine compliance of the utilization data with the conditions of the consent data based on comparing the utilization data and the consent data. In some non-limiting embodiments or aspects, the consent database 102 may store an indication of compliance (or noncompliance) of the utilization data (e.g., in an immutable ledger).

[0196] In some non-limiting embodiments or aspects, the consent database 102 may request and (in response to the request) receive from the user data database 108 allocation data associated with at least one data access of the requestor system 104 to the user data. Additionally or alternatively, the consent database 102 may store the allocation data (e.g., in an immutable ledger). In some non-limiting embodiments or aspects, the consent database 102 may compare the allocation data with the consent data. For example, the consent database 102 may determine compliance of the allocation data with the conditions of the consent data based on the comparison. In some non-limiting embodiments or aspects, the consent database 102 may store an indication of compliance (or noncompliance) of the allocation data (e.g., in an immutable ledger).

[0197] like Figure 1E As shown in , process 100c may include transmitting an indication of compliance at step 177. For example, consent database 102 may transmit an indication of compliance of utilization data and / or allocation data associated with user data to user data database 108 (and / or requester system 104).

[0198] like Figure 1E As shown in , at step 178, process 100c may include transmitting an indication of compliance to a user device. For example, user data database 108 (and / or requester system 104) may transmit an indication of compliance to user device 106.

[0199] refer to Figure 1F, a process 100d for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 100d can be performed by consent database 102 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 100d can be performed by another system, another device, another group of systems, or another group of devices (e.g., requester system 104, user device 106, and / or user data database 108) that is separate from or includes consent database 102 (e.g., completely, partially, etc.). Figure 1F The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects. Figure 1F The dashed lines shown in the drawings illustrate additional or alternative actions that may be performed at each step.

[0200] like Figure 1F As shown in FIG. 1 , at step 181 , process 100 d may include transmitting a request for a digital identifier. For example, user device 106 may transmit a request for a digital identifier to consent database 102 .

[0201] like Figure 1F As shown in FIG. 1 , at step 182 , process 100 d may include generating a digital identifier. For example, consent database 102 may generate a digital identifier for a user of user device 106 .

[0202] In some non-limiting embodiments or aspects, the digital identifier may include a user identifier (eg, an identification token associated with a user, etc.).

[0203] In some non-limiting embodiments or aspects, the consent database 102 may associate the digital identifier with the user's consent data stored by the consent database 102 .

[0204] like Figure 1F As shown in , at step 183, process 100d may include communicating with the user device based on the digital identifier. For example, consent database 102 may transmit the digital identifier to user device 106. Additionally or alternatively, consent database 102 may transmit a hosted consent management interface to user device 106.

[0205] like Figure 1F As shown, at step 184 , process 100 d may include communicating with at least one of user data database 108 and / or requestor system 104 based on the digital identifier and / or consent data stored by consent database 102 .

[0206] In some non-limiting embodiments or aspects, communications based on a consent response and / or a consent verification response as described herein may be based on a digital identifier and / or consent data stored by the consent database 102 .

[0207] like Figure 1F As shown in , at step 185, process 100d may include communicating with the user device based on the digital identifier. For example, user data database 108 (and / or requester system 104) may communicate with user device 106 based on the digital identifier.

[0208] In some non-limiting embodiments or aspects, the communication based on the digital identifier may include transmitting a hosted consent management interface. Additionally or alternatively, the user device 106 may display the hosted consent management interface. For example, the hosted consent management interface may include a list of each item of user data that the user has agreed to share based on the digital identifier.

[0209] refer to Figure 2A, a system 200 for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. System 200 includes a consent ledger system 202, a consent beneficiary system 203, a consent requestor system 204, a user device 206, a consent directory service system 207, a resource provider system 208, an identity provider system 210, a consent presenter system 220, a consent service system 222, an authority system 224, an auditor system 226, and / or a communication network 212. Consent ledger system 202, consent beneficiary system 203, consent requestor system 204, user device 206, consent directory service system 207, resource provider system 208, identity provider system 210, consent presenter system 220, consent service system 222, authority system 224, and / or auditor system 226 may each include one or more computing devices configured to communicate over one or more communication networks (e.g., communication network 212). In some non-limiting embodiments or aspects, at least one of the consent ledger system 202, the consent directory service 207, the consent service system 222, the authority system 224, and / or the auditor system 226 may be the same as or similar to the consent database 102. In some non-limiting embodiments or aspects, at least one of the consent beneficiary system 203, the consent requester system 204, and / or the consent presenter system 220 may be the same as or similar to the requester system 104. In some non-limiting embodiments or aspects, at least one of the user device 206 and / or the consent presenter system 220 may be the same as or similar to the user device 106. In some non-limiting embodiments or aspects, at least one of the resource provider system 208 and / or the identity provider system 210 may be the same as or similar to the user data database 108. In some non-limiting embodiments or aspects, the communication network 212 may be the same as or similar to the communication network 112.

[0210] In some non-limiting embodiments or aspects, the user device 206 may be associated with a user (e.g., an individual, an entity, a fiduciary acting on behalf of an individual or entity). For example, a user may have the authority to consent to sharing user data (e.g., for at least one specified purpose). In some non-limiting embodiments or aspects, the user may include a consumer, a business entity, etc. In some non-limiting embodiments or aspects, a user may (e.g., via the user device 206) view consent items, grant consent, revoke consent, renew consent, any combination thereof, etc.

[0211] In some non-limiting embodiments or aspects, the consent beneficiary system 203 may be associated with at least one consent beneficiary. For example, the consent beneficiary may be a party known to the user (e.g., an individual, an entity, etc.). In some non-limiting embodiments or aspects, the consent beneficiary may provide services to the user, and the service may rely on personal data from the user. For example, the service may include providing loans, credit cards, bank accounts, etc. to the user, and such services may rely on the credit history of the user. As another example, the service may include a mobile application for users to purchase products and / or other services (e.g., subscriptions, delivery services, etc.), and such services may rely on user data associated with the user, such as name, address, contact information (e.g., email address, phone number, etc.), account identifiers, etc. Exemplary consent beneficiaries may include advertisers, airlines, rideshare operators, lenders, financial technology companies, advertising technology companies, aggregators or intermediaries, loyalty platforms, etc. In some non-limiting embodiments or aspects, as described herein, the consent beneficiary system 203 may initiate a consent request (e.g., based on a user's request), maintain (e.g., store) a mapping of a user to at least one consent token, use a consent token to request a consent value, etc. In some non-limiting embodiments or aspects, a consent beneficiary may (e.g., via the consent beneficiary system 203) view resource providers (e.g., based on the consent context to which the consent beneficiary belongs), request identity providers (e.g., when selected from a user), authenticate a user (e.g., when selected from a user), grant consent (e.g., when requested by a user), revoke consent (e.g., when requested by a user), renew consent (e.g., when requested by a user), store at least one consent token, request consent values, view consent items, etc. In some non-limiting embodiments or aspects, multiple consent beneficiary systems 203 (e.g., of multiple consent beneficiaries) may be associated with a single data request (e.g., multiple consent beneficiaries use the requested data for the same and / or different purposes, one consent beneficiary facilitates the transfer of data from a resource provider to a second consent beneficiary, etc.).

[0212] In some non-limiting embodiments or aspects, the consent presenter system 220 may present a UI to the user on behalf of the consent beneficiary system 203. For example, the consent presenter system 220 may include the system of an aggregator or intermediary, a consent management platform provider, an open banking provider, etc. Additionally or alternatively, the consent presenter system 220 may include the user device 106, its operating system, applications thereon, etc.

[0213] In some non-limiting embodiments or aspects, the consent requester system 204 can execute the consent request (e.g., on behalf of the consent beneficiary system 203, etc.). For example, the consent requester system 204 can receive the consent request from the consent beneficiary system 203 and / or transmit the consent request to the consent service system 222. In some non-limiting embodiments or aspects, as described herein, the consent requester system 204 can maintain (e.g., store) a mapping of the user to each consent beneficiary and / or each consent token. Exemplary consent requesters can include banks, open banking providers, aggregators or intermediaries, marketing companies, financial technology companies, advertising technology companies, operating systems, advertisers, privacy technology companies, etc. In some non-limiting embodiments or aspects, a consent requester can (e.g., via the consent requester system 204) view resource providers, request identity providers, authenticate users (e.g., upon granting a beneficiary request), grant consent (e.g., upon granting a beneficiary request), revoke consent (e.g., upon granting a beneficiary request), renew consent (e.g., upon granting a beneficiary request), store at least one consent token, request a consent value, view consent items, and the like.

[0214] In some non-limiting embodiments or aspects, as described herein, the consent service system 222 can coordinate events (e.g., communications) between other systems and / or devices of the system 200. In some non-limiting embodiments or aspects, the consent service system 222 can review resource providers, request identity providers, authenticate users (e.g., when requested by a consent requestor), grant consent (e.g., when requested by a consent requestor), revoke consent (e.g., when requested by a consent requestor), renew consent (e.g., when requested by a consent requestor), archive consent, delete consent, review consent items, revoke consent (e.g., when requested by a user), analyze consent value and user decisions for consent beneficiaries, and the like.

[0215] In some non-limiting embodiments or aspects, the consent directory system 207 can authenticate and / or onboard the consent requester system 204 and / or the identity provider system 210. In some non-limiting embodiments or aspects, the consent directory system 207 can maintain (e.g., store) a mapping of consent requesters, consent contexts, and / or consent items, as described herein. In some non-limiting embodiments or aspects, the consent directory system 207 can maintain (e.g., store) a mapping of resource provider systems 208 to identity provider systems 210. In some non-limiting embodiments or aspects, the consent directory system 207 can view resource providers, requesting identity providers, onboard consent requesters, onboard consent beneficiaries, onboard resource providers, onboard identity providers, etc.

[0216] In some non-limiting embodiments or aspects, the resource provider system 208 stores user data of the user (e.g., data requested by the consent beneficiary and / or the consent requester). For example, as described herein, the resource provider system 208 can take actions based on the user's consent for at least one purpose (e.g., share the user data or a portion thereof). Exemplary resource provider systems can include banks, merchants, healthcare providers, mobile device operators, Internet of Things (IoT) device operators, etc.

[0217] In some non-limiting embodiments or aspects, the identity provider system 210 can authenticate the user (eg, on behalf of the resource provider system 208 ).

[0218] In some non-limiting embodiments or aspects, as described herein, the consent ledger system 202 can maintain (e.g., store) an auditable record of each transaction and state change (e.g., each consent request, consent token, etc.) within the system 200. For example, the consent ledger system 202 can include at least one immutable ledger. In some non-limiting embodiments or aspects, the consent service system 222 can operate at least one consent ledger system 202. In some non-limiting embodiments or aspects, each resource provider system 208 can be associated with at least one consent ledger system 202.

[0219] In some non-limiting embodiments or aspects, the authority system 224 can be associated with an authority (eg, of the system 200). For example, the authority can be responsible for defining rules for the system 200 and / or its devices and / or systems.

[0220] In some non-limiting embodiments or aspects, the auditor system 226 may have the ability to perform audits of the system 200 and / or its devices and / or systems.

[0221] Figure 2A The number and arrangement of systems and devices shown in are provided as examples. Additional systems and / or devices, fewer systems and / or devices, different systems and / or devices, and / or devices may be present. Figure 2A In addition, the system and / or device may be implemented in a single system or device. Figure 2A two or more systems or devices shown in, or Figure 2AThe single system or device shown in may be implemented as multiple distributed systems or devices. Additionally or alternatively, a group of systems (e.g., one or more systems) or a group of devices (e.g., one or more devices) of system 200 may perform one or more functions described as being performed by another group of systems or another group of devices of system 200. In some non-limiting embodiments or aspects, the consent presenter system 220 may be the same as or may be a part of the user device 206. In some non-limiting embodiments or aspects, at least two of the consent presenter system 220, the consent beneficiary system 203, and / or the consent requester system 204 may be the same system and / or part of the same system. In some non-limiting embodiments or aspects, at least two of the consent service system 222, the consent directory service system 207, and / or the consent ledger system 202 may be the same system and / or part of the same system. In some non-limiting embodiments or aspects, the identity provider system 210 and / or the resource provider system 208 may be the same system and / or part of the same system. In some non-limiting embodiments or aspects, consent presenter system 220, consent beneficiary system 203, consent requester system 204, identity provider system 210, and resource provider system 208 may be the same system and / or parts of the same system (e.g., a merchant requests consent to use user data stored on a separate part of the merchant's system to provide a new service to the user).

[0222] A user may request a service through a user device 206, which may communicate with Figure 1A The user device 206 may be the same as or similar to the user device 106 in the example. The user device 206 may transmit the service request to the consent beneficiary system 203. The consent beneficiary system 203 may determine that the service requested in the service request requires the use of personal data from the user. The consent beneficiary system 203 may then send the consent request to the consent requestor system 204. The consent beneficiary system 203 and / or the consent requestor system 204 may communicate with Figure 1A The consent requester system 204 may be the same or similar to the consent beneficiary system 203. The consent requester system 204 may be the same or a different system than the consent beneficiary system 203. The consent requester system 204 may determine the data user consent required to complete the consent request. The consent requester system 204 may transmit a provider request to the consent service system 222 to provide a list of providers that may access the user data requested in the consent request or may store the user data.

[0223] Continue to refer Figure 2AIn certain non-limiting embodiments or aspects, in response to receiving the provider request, the consent service system 222 can transmit the provider request to the consent directory service system 207. The consent directory service system 207 can determine whether the consent request matches the requested user data. The consent directory service system 207 can determine a list of resource provider systems 208 that store the user data requested in the consent request. The consent directory service system 207 can transmit the list of resource provider systems to the consent presenter system 220.

[0224] Continue to refer Figure 2A In some non-limiting embodiments or aspects, the consent presenter system 220 can display a list of resource provider systems 208 to the user through a UI display on the user device 206. The user can select one or more resource provider systems 208, and the user grants consent to the consent beneficiary system 203 to obtain access to the relevant user data. The consent presenter system 220 can transmit the selected resource provider system 208 to the consent service system 222.

[0225] Continue to refer Figure 2A In some non-limiting embodiments or aspects, the consent service system 222 may communicate with the consent directory service system 207 to determine how each selected resource provider system 208 requires authentication of the user's identity. The consent directory service system 207 may communicate with the user through the user device 206 based on the requirements of the resource provider system 208, instructing the user to authenticate his or her identity. The user may authenticate his or her identity using the identity provider system 210 based on the requirements of the resource provider system 208. After authenticating the user's identity, the identity provider system 210 may transmit an identification (ID) token to the consent service system 222, the identification token indicating that the user's identity has been authenticated.

[0226] Continue to refer Figure 2A In certain non-limiting embodiments or aspects, once the consent service system 222 receives the ID token, the consent service system 222 may transmit a consent token request to the consent ledger system 202. The consent token request may include the ID token, the identity of the consent beneficiary system 203, the identity of the consent requester system 204, the identity of the selected resource provider system 208, the requested user data, the purpose of the data use, the amount of the requested user data, the duration of the request, the frequency of the request, etc.

[0227] Continue to refer Figure 2AIn certain non-limiting embodiments or aspects, in response to receiving the consent token request, the consent ledger system 202 may record an event in the consent ledger system 202. The consent ledger system 202 may verify that the consent token request does not violate the consent granted by the user. If the consent token request matches the user consent, the consent ledger system 202 may transmit the consent token to the consent requester system 204.

[0228] Continue to refer Figure 2A In some non-limiting embodiments or aspects, the consent requester system 204 may store the consent token. The consent requester system 204 may then transmit the consent token to the consent beneficiary system 203. The consent beneficiary system 203 may then store the consent token and transmit the consent token to the relevant resource provider system 208 where the user grants consent to receive the consented user data. In response to receiving the consent token, the resource provider system 208 may transmit the consented user data to the consent beneficiary system 203.

[0229] Continue to refer Figure 2A In some non-limiting embodiments or aspects, the aforementioned devices and / or systems may communicate via at least one communication network 212 , which may be the same as or similar to the communication network 112 .

[0230] Continue to refer Figure 2A , in some non-limiting embodiments or aspects, actions may be taken on behalf of the user (e.g., in addition to, instead of, or as part of sharing and / or using user data). For example, the consent beneficiary system 203 may automatically take action on behalf of the user, for example, in response to receiving a consent token and / or consent value. For example, the consent beneficiary system 203 may instruct and / or control at least one device and / or system (which may be part of and / or separate from the consent beneficiary system 203) to perform an action (e.g., unlocking a smart lock on a door to allow a delivery to be placed inside, allowing a connected car to initiate a proximity-based payment, etc.) based on the user's consent (e.g., a consent token and / or consent value associated with the user). For example, the consent value may include data that enables the consent beneficiary system 203 to communicate with, instruct, and / or control such a device (e.g., an identifier, an account identifier, a payment token, authentication data, Internet address data, etc.).

[0231] refer to Figure 2B-2D, a process 200a for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 200a can be performed by a consent service system 222 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 200a can be performed by another system, another device, another group of systems, or another group of devices that is separate from or includes the consent service system 222, such as the consent ledger system 202, the consent beneficiary system 203, the consent requester system 204, the user device 206, the consent directory service system 207, the resource provider system 208, the identity provider system 210, the consent presenter system 220, the authority system 224, and / or the auditor system 226 (e.g., completely, partially, etc.). Figure 2B-2D The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects.

[0232] like Figure 2B As shown in FIG. 2 , at step 231 , process 200 a may include transmitting a service request. For example, user device 206 may transmit the service request to consent presenter system 220 .

[0233] In some non-limiting embodiments or aspects, the user device may display a UI (eg, GUI). For example, the user device 206 may receive input from a user via the UI to request a service (eg, from the consent beneficiary system 203, etc.).

[0234] In some non-limiting embodiments or aspects, the consent presenter system 220 may receive a service request from a user via a UI (eg, GUI) displayed on the user device 206 of the user.

[0235] like Figure 2B As shown in FIG. 2 , at step 232 , process 200 a may include transmitting the service request. For example, consent presenter system 220 may transmit the service request to consent beneficiary system 203 .

[0236] like Figure 2B As shown in FIG. 2 , at step 233 , process 200a may include transmitting a data request. For example, consent beneficiary system 203 may transmit a data request to consent requester system 204 based on receiving a service request.

[0237] In some non-limiting embodiments or aspects, the data request may include at least one consent item associated with the user data. For example, each consent item may be associated with a type (e.g., a category) of the user data. In some non-limiting embodiments or aspects, each consent item may include at least one of the following: consent item type data associated with the type of the consent item, duration data associated with the duration of the consent item; time range data associated with the time range of the consent item; frequency data associated with how often the consent item will be requested; time span data associated with the time span of the consent item; consent state data associated with the state of the consent item; consent state data associated with the state of the consent item; primary purpose data associated with at least one primary purpose for which the consent item will be used; secondary purpose data associated with at least one secondary purpose for which the consent item will be used, the at least one secondary purpose being different from the at least one primary purpose; any combination thereof, etc. In some non-limiting embodiments or aspects, the consent state may be granted or revoked. In some non-limiting embodiments or aspects, the consent status can be one of: active (e.g., a consent value for a consent item can be requested), archived (e.g., a consent item is no longer active), deleted, initiated (e.g., a consent item has been created, but consent has not yet been granted), suspended (e.g., a consent item is temporarily disabled), revoked, consumed (e.g., used, and can no longer be used), expired (e.g., no longer valid because the consent item has met or exceeded its expiration date), etc. In some non-limiting embodiments or aspects, the frequency can be streamlined (e.g., continuously available), periodic (e.g., available at specified intervals such as daily, weekly, monthly, yearly, etc.), on-demand (e.g., available upon user initiation / request), contextual (e.g., available when an event specified in a (primary or secondary) purpose occurs), one-time, etc. In some non-limiting embodiments or aspects, the time span can be a point in time (e.g., an account balance at the time of a transaction) within a selected time period (e.g., a day's data, a week's data, a month's data, a year's data, etc.), etc. In some non-limiting embodiments or aspects, the consent item type is the type of consent item (eg, web browsing history, payment transactions, banking transactions, personal information, etc.).

[0238] In some non-limiting embodiments or aspects, only certain parties (e.g., types of parties, categories of parties, etc.) may be allowed to request certain types of consent items. The parties (e.g., types of parties, categories of parties, etc.) that are allowed to request such consent items may be based on the consent contexts associated with the consent item types. For example, each consent context may include a name (and / or identifier) ​​and a set of one or more consent item types associated with the consent context. Additionally or alternatively, each consent context may include and / or be associated with a set of one or more consent requestor systems 204 and / or a second type of one or more consent requestor types that are allowed to request the consent item types associated with the consent context.

[0239] like Figure 2B As shown in , at step 234, process 200a may include transmitting the data request to the consent service system. For example, the consent requester system 204 may transmit the data request to the consent service system 222. Additionally or alternatively, the consent requester system 204 may request an identification of at least one resource provider system 208 from the consent service system 222 based on the data request (e.g., its consent item).

[0240] like Figure 2B As shown in , at step 235, process 200a may include transmitting the data request to the consent directory service system. For example, the consent service system 222 may transmit the data request to the consent directory service system 207. Additionally or alternatively, the consent service system 222 may request an identification of at least one resource provider system 208 from the consent directory service system 207 based on the data request (e.g., its consent item).

[0241] like Figure 2B As shown in , process 200a may include determining resource provider identification data at step 236. For example, consent directory service system 207 may determine resource provider identification data associated with at least one resource provider system 208 storing user data requested in the data request.

[0242] In some non-limiting embodiments or aspects, the consent catalog service system 207 may determine one or more resource provider systems 208 based on the resource provider systems 208 associated with the consent item type of the consent item of the data request.

[0243] In some non-limiting embodiments or aspects, the consent directory service system 207 can verify that the consent item (e.g., the consent item type of the consent item) corresponds to the consent context of the consent requester system 204. For example, the consent directory service system 207 can verify this correspondence based on the consent requester (and / or the type of consent requester), the consent context, and / or a mapping of consent items maintained (e.g., stored) by the consent directory service system 207.

[0244] like Figure 2B As shown in FIG. 2 , at step 237 , process 200 a can include transmitting the resource provider identification data. For example, consent directory service system 207 can transmit the resource provider identification data to consent service system 222 .

[0245] like Figure 2B As shown in FIG. 2 , at step 238 , process 200 a can include transmitting the resource provider identification data. For example, consent service system 222 can transmit the resource provider identification data to consent requester system 204 .

[0246] like Figure 2B As shown in FIG. 2 , at step 239 , process 200 a may include transmitting resource provider identification data. For example, consent requester system 204 may transmit resource provider identification data to consent beneficiary system 203 .

[0247] like Figure 2B As shown in FIG. 2 , at step 240 , process 200 a may include transmitting resource provider identification data. For example, consent beneficiary system 203 may transmit resource provider identification data to consent presenter system 220 .

[0248] like Figure 2B As shown in FIG. 2 , at step 241 , process 200 a can include transmitting resource provider identification data. For example, consent presenter system 220 can transmit resource provider identification data to user device 206 .

[0249] like Figure 2B As shown in FIG. 2 , at step 242 , process 200 a may include transmitting resource provider selection data. For example, user device 206 may transmit resource provider selection data associated with selection of resource provider system 208 to consent presenter system 220 .

[0250] In some non-limiting embodiments or aspects, the user device may display a UI (e.g., a GUI) that includes at least one identifier of a resource provider system 208 identified by the resource provider identification data. For example, the user device 206 may receive input from a user via the UI to select one of the displayed resource provider systems 208. In some non-limiting embodiments or aspects, the user device 206 may select (one of) the resource provider system 208 based on the input and transmit the resource provider selection data to the consent presenter system 220.

[0251] like Figure 2B As shown in FIG. 24 , at step 243 , process 200 a may include transmitting the resource provider selection data. For example, consent presenter system 220 may transmit the resource provider selection data to consent beneficiary system 203 .

[0252] like Figure 2B As shown in FIG. 2 , at step 244 , process 200 a may include transmitting the resource provider selection data. For example, consent beneficiary system 203 may transmit the resource provider selection data to consent requester system 204 .

[0253] like Figure 2B As shown in FIG. 2 , at step 245 , process 200 a can include transmitting the resource provider selection data. For example, the consent requester system 204 can transmit the resource provider selection data to the consent service system 222 .

[0254] like Figure 2B As shown in FIG. 2 , at step 246 , process 200 a may include transmitting the resource provider selection data. For example, consent service system 222 may transmit the resource provider selection data to consent directory system 207 .

[0255] like Figure 2B As shown in , process 200a may include transmitting identity provider identification data at step 247. For example, consent directory service system 207 may transmit identity provider identification data associated with at least one identity provider system 210 authorized to authenticate the identity of the user to consent service system 222.

[0256] In some non-limiting embodiments or aspects, as described herein, the consent directory service system 207 can maintain (e.g., store) a mapping of resource provider systems 208 to identity provider systems 210. Additionally or alternatively, the consent directory service system 207 can transmit identity provider identification data associated with at least one identity provider system 210 that is authorized to authenticate the identity of the user based on the mapping of the resource provider systems 208 to the identity provider systems 210.

[0257] like Figure 2BAs shown in FIG. 2 , at step 248 , process 200 a can include transmitting the identity provider identification data. For example, consent service system 222 can transmit the identity provider identification data to consent requester system 204 .

[0258] like Figure 2C As shown in FIG. 2 , at step 249 , process 200a may include transmitting the identity provider identification data. For example, consent requester system 204 may transmit the identity provider identification data to consent beneficiary system 203 .

[0259] like Figure 2C As shown in FIG. 2 , at step 250 , process 200 a may include transmitting identity provider identification data. For example, consent beneficiary system 203 may transmit identity provider identification data to consent presenter system 220 .

[0260] like Figure 2C As shown in FIG. 2 , at step 251 , process 200 a may include rendering an authentication user interface. For example, consent presenter system 220 may render an authentication user interface for display on user device 206 .

[0261] like Figure 2C As shown in , at step 252, process 200a can include transmitting and / or displaying an authentication user interface. For example, user device 206 can receive an authentication user interface from consent presenter system 220 and / or display an authentication user interface.

[0262] like Figure 2C As shown in , process 200a may include transmitting authentication data at step 253. For example, user device 206 may transmit authentication data to consent presenter system 220 (eg, based on input received from a user via an authentication user interface).

[0263] like Figure 2C As shown in , at step 254 , process 200 a can include transmitting the authentication data. For example, consent presenter system 220 can transmit the authentication data to identity provider system 210 .

[0264] like Figure 2C As shown in , process 200a may include transmitting the ID token at step 255. For example, identity provider system 210 may transmit the ID token to consent presenter system 220 based on receiving the authentication data.

[0265] In some non-limiting embodiments or aspects, the identity provider system 210 may generate an ID token based on receiving the authentication data. In some non-limiting embodiments or aspects, the ID token may include an indication (e.g., a reference) of a successful authentication (e.g., identity verification) of the user by the identity provider system 210, the type of identity verification performed, a signature (and / or certificate, etc.) proving the authentication (e.g., proving the authenticity of the ID token purportedly provided by the identity provider system 210), any combination thereof, and the like.

[0266] like Figure 2C As shown in FIG. 2 , at step 256 , process 200 a can include transmitting the ID token. For example, consent presenter system 220 can transmit the ID token to user device 206 .

[0267] like Figure 2C As shown in FIG. 2 , at step 257 , process 200 a may include transmitting a consent request. For example, consent presenter system 220 may transmit a consent request (eg, from a data request) including an ID token and a consent item to consent beneficiary system 203 .

[0268] like Figure 2C As shown in FIG. 2 , at step 258 , process 200 a can include transmitting the consent request. For example, consent beneficiary system 203 can transmit the consent request to consent requester system 204 .

[0269] like Figure 2C As shown in FIG. 2 , at step 259 , process 200 a can include transmitting the consent request. For example, the consent requester system 204 can transmit the consent request to the consent service system 222 .

[0270] like Figure 2C As shown in FIG. 2 , at step 260 , process 200 a may include transmitting the consent request. For example, consent service system 222 may transmit the consent request to consent ledger system 207 .

[0271] In some non-limiting embodiments or aspects, the consent request may include a consent token request.

[0272] like Figure 2C As shown in FIG. 2 , process 200a may include transmitting a consent token at step 261. For example, consent ledger system 207 may transmit the consent token to consent service system 222 based on a consent request (eg, a consent token request).

[0273] In some non-limiting embodiments or aspects, the consent ledger system 207 can generate a consent token based on a consent request (e.g., a consent token request). In some non-limiting embodiments or aspects, the consent token can include a consent identifier (e.g., a unique identifier for the consent token), a user ID token, at least one consent beneficiary identifier (e.g., associated with the consent beneficiary system 203 that transmitted the data request and / or the consent request), a resource provider identifier (e.g., associated with the resource provider system 208 selected by the user), a consent item, jurisdiction data (e.g., data indicating the country or geographic region for which the consent token is valid), any combination thereof, and the like.

[0274] In some non-limiting embodiments or aspects, the consent ledger system 207 may store consent data based on a consent request, a consent token, any combination thereof, etc. For example, the consent ledger system 207 may store the consent data in an immutable ledger, etc.

[0275] like Figure 2C As shown in FIG. 2 , at step 262 , process 200 a can include transmitting the consent token. For example, the consent service system 222 can transmit the consent token to the consent requester system 204 .

[0276] like Figure 2C As shown in FIG. 2 , at step 263 , process 200 a may include transmitting the consent token. For example, the consent requester system 204 may transmit the consent token to the consent beneficiary system 203 .

[0277] like Figure 2C As shown in FIG. 2 , process 200a can include storing the consent token at step 264. For example, consent beneficiary system 203 can store the consent token.

[0278] like Figure 2C As shown in FIG. 2 , process 200a can include transmitting the consent token at step 265 . For example, consent beneficiary system 203 can transmit at least one communication including the consent token to resource provider system 208 .

[0279] In some non-limiting embodiments or aspects, the consent beneficiary system 203 may transmit a get request to the resource provider system 208 including the consent token, additional parameters, any combination thereof, and the like.

[0280] like Figure 2D As shown in , at step 266, process 200a can include transmitting a token verification request. For example, resource provider system 208 can transmit the token verification request to consent service system 222 based on the consent token. In some non-limiting embodiments or aspects, the token verification request can include the consent token.

[0281] like Figure 2D As shown in FIG. 2 , at step 267 , process 200 a can include transmitting a token validation response. For example, the consent service system 222 can transmit the token validation response to the resource provider system 208 .

[0282] In some non-limiting embodiments or aspects, the token validation response may indicate whether the consent token is valid. For example, the token validation response may indicate that the consent token is valid. Alternatively, the token validation response may indicate that the consent token is invalid (e.g., the consent token does not match a consent token previously transmitted by the consent service system 222 and / or stored in the consent ledger system 207).

[0283] like Figure 2D As shown in , process 200a can include transmitting at least one consent value at step 268. For example, resource provider system 208 can transmit at least one consent value to consent beneficiary system 203 based on a communication (e.g., via an API, etc.) including a consent token (e.g., a get request).

[0284] In some non-limiting embodiments or aspects, the consent value may include (at least a portion of) user data stored by the resource provider system 208. For example, the consent value may include user data associated with each consent item. Thus, the resource provider system 208 may transmit at least one consent value for each consent item in at least one consent item, and each consent value may include at least a portion of the user data.

[0285] In some non-limiting embodiments or aspects, actions may be taken on behalf of a user (e.g., in addition to, in lieu of, or as part of sharing and / or using user data). For example, the consent beneficiary system 203 may automatically take action on behalf of a user, for example, in response to receiving a consent token and / or consent value. For example, the consent beneficiary system 203 may instruct and / or control at least one device and / or system (which may be part of and / or separate from the consent beneficiary system 203) to perform an action (e.g., unlocking a smart lock on a door to allow a delivery to be placed inside, allowing a connected car to initiate a proximity-based payment, etc.) based on the user's consent (e.g., a consent token and / or consent value associated with the user). For example, the consent value may include data that enables the consent beneficiary system 203 to communicate with, instruct, and / or control such a device (e.g., an identifier, an account identifier, a payment token, authentication data, Internet address data, etc.).

[0286] refer to Figure 2E, a process 200b for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 200b can be performed by a consent service system 222 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 200b can be performed by another system, another device, another group of systems, or another group of devices that is separate from or includes the consent service system 222, such as the consent ledger system 202, the consent beneficiary system 203, the consent requester system 204, the user device 206, the consent directory service system 207, the resource provider system 208, the identity provider system 210, the consent presenter system 220, the authority system 224, and / or the auditor system 226 (e.g., completely, partially, etc.). Figure 2E The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects.

[0287] like Figure 2E As shown in , at step 270, process 200b may include transmitting a modification request. For example, user device 206 may transmit a modification request (e.g., a revocation request, a renewal request, etc.) to at least one selected system. For example, the selected system may include at least one of consent presenter system 220, consent beneficiary system 203, consent requester system 204, consent service system 222, resource provider system 208, or any combination thereof.

[0288] In some non-limiting embodiments or aspects, the modification request may be associated with at least one consent item to which the user previously granted consent to share. In some non-limiting embodiments or aspects, the modification request may be associated with all consent items to which the user previously granted consent to share. In some non-limiting embodiments or aspects, the modification request may not be specific to any particular consent item.

[0289] In some non-limiting embodiments or aspects, user device 206 may transmit a modification request in response to input from a user (eg, indicating that the user intends to initiate a modification request).

[0290] like Figure 2E As shown in , at step 271 , process 200 b may include identifying a user. For example, the selected system may identify the user based on a modification request received from user device 206 .

[0291] In some non-limiting embodiments or aspects, as described herein, the modification request may include the user's ID token. Additionally or alternatively, the selected system may identify the user based on the ID token.

[0292] In some non-limiting embodiments or aspects, the selected system may identify the user based on the user authenticating with at least one identity provider system 210, as described herein.

[0293] like Figure 2E As shown in , at step 272, process 200b may include retrieving consent tokens and / or consent items. For example, the selected system may retrieve (e.g., search and / or load) consent tokens and / or consent items that the user previously granted consent to share from the local data storage device of the selected system. Additionally or alternatively, the selected system may retrieve (e.g., request and / or receive) consent tokens and / or consent items that the user previously granted consent to share from the consent ledger system 202.

[0294] like Figure 2E As shown in , at step 273, process 200b may include transmitting a consent token and / or consent item. For example, the selected system may transmit to user device 206 a consent token and / or consent item that the user previously granted consent to share.

[0295] like Figure 2E As shown in , at step 274, process 200b can include transmitting a selection of at least one consent token and / or consent item. For example, user device 206 can transmit to the selected system a selection of at least one consent token and / or consent item that the user has selected to modify (e.g., revoke, renew, etc.). Additionally or alternatively, user device 206 can transmit at least one desired modification (e.g., revoke, renew, etc.) to each consent token and / or consent item selected.

[0296] In some non-limiting embodiments or aspects, the user device 206 may transmit a selection request in response to input from a user (eg, instructing the user to select at least one consent token and / or consent item).

[0297] like Figure 2E As shown in , at step 275 , process 200 b may include transmitting the selection (and / or desired modification). For example, the selected system may transmit the selection (and / or desired modification) to the consent service system 222 .

[0298] like Figure 2E As shown in , at step 276 , process 200 b may include transmitting the selection (and / or desired modification). For example, consent service system 222 may transmit the selection (and / or desired modification) to consent ledger system 207 .

[0299] like Figure 2EAs shown in , at step 277, process 200b can include modifying the selected consent token and / or consent item. For example, consent ledger system 207 can modify the selected consent token and / or consent item (e.g., from the selection) based on the desired modification. Additionally or alternatively, if consent ledger system 207 stores the consent token and / or consent item in an immutable ledger, consent ledger system 207 can store additional data records indicating the modification to the previously stored consent token and / or consent item.

[0300] like Figure 2E As shown in , at step 278, process 200b may include transmitting a confirmation message. For example, consent ledger system 207 may transmit a confirmation message to consent service system 222 indicating that the selected consent token and / or consent item has been modified.

[0301] In some non-limiting embodiments or aspects, the consent message may include a consent token and / or a list of consent items and their corresponding statuses.

[0302] like Figure 2E As shown in FIG. 2 , at step 279 , process 200 b may include transmitting the confirmation message. For example, the consent service system 222 may transmit a confirmation message to the selected system.

[0303] like Figure 2E As shown in FIG. 2 , at step 280 , process 200 b may include transmitting the confirmation message. For example, the selected system may transmit a confirmation message to user device 206 .

[0304] Reference now Figure 3 , a diagram showing exemplary components of a computing device 900 for implementing and executing the systems and methods described herein, according to a non-limiting embodiment. The computing device 900 may refer to Figure 1A , the consent database 102, the requestor system 104, the user device 106, or the user data database 108 shown in FIG. 1 , and / or Figure 2A 202, consent beneficiary system 203, consent requester system 204, user device 206, consent directory service system 207, resource provider system 208, identity provider system 210, consent presenter system 220, consent service system 222, authority system 224, or auditor system 226. In some non-limiting embodiments or aspects, Figure 3, the device 900 may include additional components, fewer components, different components, or components arranged in a different manner compared to those shown in . The device 900 may include a bus 902, a processor 904, a memory 906, a storage component 908, an input component 910, an output component 912, and a communication interface 914. The bus 902 may include components that permit communication between components of the device 900. In some non-limiting embodiments or aspects, the processor 904 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 904 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a virtual or augmented reality depiction system and device, etc.). Memory 906 may include random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, optical storage, etc.) that stores information and / or instructions for use by processor 904.

[0305] Continue to refer Figure 3 , the storage component 908 may store information and / or software related to the operation and use of the device 900. For example, the storage component 908 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.) and / or another type of computer-readable medium. The input component 910 may include a component that allows the device 900 to receive information, for example, through user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). In addition or alternatively, the input component 910 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). The output component 912 may include a component that provides output information from the device 900 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). The communication interface 914 may include a transceiver-like component (e.g., a transceiver, a separate receiver and a transmitter, etc.) that enables the device 900 to communicate with other devices, for example, through a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. The communication interface 914 may allow the device 900 to receive information from another device and / or provide information to another device. For example, the communication interface 914 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, Interface, cellular network interface, etc.

[0306] The device 900 can perform one or more processes described herein. The device 900 can perform these processes based on the processor 904 executing software instructions stored by computer-readable media such as memory 906 and / or storage component 908. The computer-readable medium may include any non-transitory memory device. The memory device includes a memory space located inside a single physical storage device or a memory space spread over multiple physical storage devices. The software instructions can be read from another computer-readable medium or from another device to the memory 906 and / or storage component 908 through the communication interface 914. When executed, the software instructions stored in the memory 906 and / or storage component 908 can cause the processor 904 to perform one or more processes described herein. In addition or alternatively, the hard-wired circuit system can replace the software instructions or be used in combination with the software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any specific combination of hardware circuit systems and software. The term "programmed or configured" used herein refers to the arrangement of software, hardware circuit systems, or any combination thereof on one or more devices.

[0307] refer to Figure 4A , shows an exemplary GUI 400a for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter. For purposes of illustration, GUI 400a may be an example of a GUI for granting consent (eg, when consent to a shared consent item has not yet been granted).

[0308] like Figure 4A As shown in , GUI 400a may include an indicia 402 of a consent beneficiary. Text 404 of GUI 400a may identify the consent beneficiary (e.g., ABC App), the resource provider (e.g., XYZ Bank), and / or the primary purpose for requesting consent. Additionally or alternatively, text 404 may also include a link to a data policy that will govern access to user data associated with the consent item.

[0309] Continue to refer Figure 4A , the drop-down menus 406a, 406b may identify the consent item associated with the consent request (e.g., data category 1, data category 2). Selecting the drop-down arrow of the drop-down menus 406a, 406b may provide additional information about the consent item. The text 408 may describe the reason for requesting the consent item (e.g., data required for the ABC App to work), whether the data associated with the consent item will be shared or sold, the time span of the consent item, and / or the frequency of the consent item.

[0310] Continue to refer Figure 4A, check boxes 410a, 410b identify at least one secondary purpose (e.g., secondary purpose 1, secondary purpose 2) to which the user can indicate his or her consent (e.g., by checking a check box, as shown in check box 410a) and / or his or her disagreement (e.g., by unchecking a check box, as shown in check box 410b).

[0311] Continue to refer Figure 4A , the drop-down menu 412 may allow the duration of the consent item to be selected. Buttons 414a, 414b may allow the user to indicate consent (e.g., by selecting button 414a) and / or indicate disagreement (e.g., by selecting button 414b) to share the consent item.

[0312] refer to Figure 4B , shows an exemplary graphical user interface 400b for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter. For purposes of illustration, GUI 400b may be an example of a GUI for modifying consent (e.g., when consent to a shared consent item has previously been granted).

[0313] In some non-limiting embodiments or aspects, Figure 4B As shown in FIG. 4 , the logo 402, text 404, drop-down menus 406a, 406b, text 408, and check boxes 410a, 410b may be similar to those described above with respect to Figure 4A The description is the same or similar.

[0314] Continue to refer Figure 4B , text 416 may describe the effect of modifying (e.g., revoking) consent to the shared consent item. Buttons 418a, 418b may allow the user to select whether to modify / revoke (e.g., by selecting button 418a) and / or not modify / revoke (e.g., by selecting button 418b) a previously granted consent.

[0315] refer to Figure 5 , an exemplary process 500 for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 500 can be performed by consent database 102 (e.g., completely, partially, etc.). In some non-limiting embodiments or aspects, one or more steps of process 500 can be performed by another system, another device, another group of systems, or another group of devices (e.g., requester system 104, user device 106, and / or user data database 108) that is separate from or includes consent database 102 (e.g., completely, partially, etc.). Figure 5 The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects.

[0316] like Figure 5 As shown in , at step 502, process 500 may include receiving a data request. For example, as described herein, consent database 102 may receive a first data request for user data associated with a user from requestor system 104, and the user data may be stored in user data database 108 separate from consent database 102.

[0317] like Figure 5 As shown in , process 500 can include transmitting a consent request at step 504. For example, as described herein, consent database 102 can transmit the consent request to requestor system 104 for display to the user on user device 106 associated with the user.

[0318] like Figure 5 As shown in , at step 506, process 500 may include receiving a consent response. For example, as described herein, consent database 102 may receive a consent response from requester system 104 based on input from user device 106, and the consent response may indicate that the user agrees to share the user data requested in the first data request.

[0319] like Figure 5 As shown in , at step 508, process 500 can include storing consent data. For example, as described herein, consent database 102 can store consent data associated with a consent response to the user data requested in the first data request in an immutable ledger.

[0320] like Figure 5 As shown in , at step 510, process 500 may include receiving a consent verification request. For example, as described herein, consent database 102 may receive a consent verification request from user data database 108, and the consent verification request may be based on a second data request for user data from requester system 104 to user data database 108.

[0321] like Figure 5 As shown in , at step 512, process 500 may include verifying the verification request based on the (stored) consent data. For example, as described herein, consent database 102 may verify the consent verification request based on the consent data stored in the immutable ledger.

[0322] like Figure 5 As shown in , at step 514, process 500 may include transmitting a consent verification response. For example, as described herein, consent database 102 may transmit a consent verification response to user data database 108 based on verifying the consent verification request, and the consent verification response may indicate that the user consents to share user data from user data database 108 with requestor system 104.

[0323] refer to Figure 6 , an exemplary process 600 for consent management according to a non-limiting embodiment or aspect of the presently disclosed subject matter is shown. In some non-limiting embodiments or aspects, one or more steps of process 600 may be performed by the consent service system 222 (e.g., in full, in part, etc.). In some non-limiting embodiments or aspects, one or more steps of process 600 may be performed by another system, another device, another group of systems, or another group of devices that is separate from or includes the consent service system 222, such as the consent ledger system 202, the consent beneficiary system 203, the consent requester system 204, the user device 206, the consent directory service system 207, the resource provider system 208, the identity provider system 210, the consent presenter system 220, the authority system 224, and / or the auditor system 226 (e.g., in full, in part, etc.). Figure 6 The steps shown in are for example purposes only. It should be understood that additional, fewer, different and / or different order steps may be used in non-limiting embodiments or aspects.

[0324] like Figure 6 As shown in , at step 602, process 600 may include receiving a data request. For example, as described herein, consent service system 222 may receive a data request for user data associated with a user from consent requestor system 204. As described herein, the user data may be stored in resource provider system 208. As described herein, the data request may include a consent beneficiary system identifier associated with consent beneficiary system 203.

[0325] like Figure 6 As shown in , at step 604, process 600 can include receiving an identification token. For example, as described herein, the consent service system 222 can receive the identification token, and the identification token can authenticate the identity of the user associated with the data request.

[0326] like Figure 6 As shown in , at step 606, process 600 can include transmitting a consent token request. For example, as described herein, the consent service system 222 can transmit the consent token request to the consent ledger system 202, and the consent token request can include an identification token, a beneficiary system identification, and data associated with the data request.

[0327] like Figure 6 As shown in , process 600 can include generating a consent token at step 608. For example, as described herein, consent ledger system 202 can generate a consent token associated with a consent token request and a user.

[0328] like Figure 6As shown in FIG. 6 , at step 610 , process 600 can include transmitting a consent token. For example, consent ledger system 202 can transmit the consent token to consent requester system 204 .

[0329] like Figure 6 As shown in , process 600 can include receiving a consent token at step 612. For example, as described herein, resource provider system 208 can receive a consent token (eg, from consent beneficiary system 203).

[0330] like Figure 6 As shown in , process 600 can include transmitting user data at step 614. For example, resource provider system 208 can transmit user data associated with the consent token to consent beneficiary system 203 as described herein.

[0331] Although the present invention has been described in detail based on what is currently considered to be the most practical and preferred embodiments or aspects for the purpose of illustration, it should be understood that such details are only for this purpose, and the present invention is not limited to the disclosed embodiments or aspects, but on the contrary, it is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present invention contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A computer-implemented method comprising: receiving, by a consent database from a requestor system, a first data request for user data associated with a user, the first data request including at least one use case, the user data being stored in a user data database separate from the consent database; transmitting, by the consent database to a requestor system, a response to the first data request, the response indicating validation of the first data request based on a determination that the at least one use case complies with consent criteria associated with at least one allowed use case; transmitting, by the consent database, a consent request to the requestor system for display to the user on a user device associated with the user; receiving, by the consent database, a consent response from the requester system based on input from the user device, the consent response indicating that the user consents to sharing the user data requested in the first data request; storing, by the consent database, consent data associated with a consent response to the user data requested in the first data request in an immutable ledger; receiving, by the consent database from the user data database, a consent verification request based on a second data request for the user data from the requestor system to the user data database; verifying, by the consent database, the consent verification request based on consent data stored in the immutable ledger; transmitting, by the consent database, a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user consents to sharing user data from the user data database with the requestor system; receiving, by the consent database from the requestor system, utilization data associated with consent to use user data; storing, by the consent database, utilization data associated with the user data in the immutable ledger; comparing, by the consent database, utilization data associated with the user data and consent data associated with the user data; determining, by the consent database, compliance of the utilization data with the conditions of the consent data; storing, by the consent database, an indication of compliance of the utilization data in the immutable ledger; receiving, by the consent database from the user data database, an audit request associated with the user data; as well as An indication of compliance of utilization data associated with the user data is communicated by the consent database to the user data database.

2. The method according to claim 1, further comprising: receiving, by the consent database from the user data database, allocation data associated with accessing the user data from the requestor system data; as well as Allocation data associated with the user data is stored in the immutable ledger by the consent database.

3. The method according to claim 2, further comprising: comparing, by the consent database, allocation data associated with the user data and consent data associated with the user data; determining, by the consent database, compliance of the allocation data with conditions of the consent data; as well as An indication of compliance of the allocation data is stored by the consent database in the immutable ledger.

4. The method according to claim 1, further comprising: receiving, by the consent database from the user device, a request to revoke consent associated with the user data; updating, by the consent database, the consent response based on the revocation request; as well as The updated consent response is transmitted by the consent database to the user data database.

5. A system for managing consent, the system comprising at least one server computer, the at least one server computer comprising at least one processor, the at least one server computer being programmed and / or configured to: receiving a first data request from a requestor system for user data associated with a user, the first data request including at least one use case, the user data being stored in a user data database separate from a consent database; transmitting a response to the first data request to a requestor system, the response indicating validation of the first data request based on a determination that the at least one use case complies with consent criteria associated with at least one allowed use case; transmitting a consent request to the requestor system for display to the user on a user device associated with the user; receiving a consent response from the requester system based on input from the user device, the consent response indicating that the user consents to sharing the user data requested in the first data request; storing consent data associated with a consent response to the user data requested in the first data request in an immutable ledger; receiving a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verifying the consent verification request based on the consent data stored in the immutable ledger; transmitting a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user consents to sharing user data from the user data database with the requestor system; receiving, from the requestor system, utilization data associated with consent to use user data; storing utilization data associated with the user data in the immutable ledger; comparing utilization data associated with the user data with consent data associated with the user data; determining compliance of said utilization data with the conditions of said consent data; storing an indication of compliance of the utilization data in the immutable ledger; receiving, from the user data database, an audit request associated with the user data; as well as An indication of compliance of utilization data associated with the user data is communicated to the user data database.

6. The system according to claim 5, wherein: The at least one server computer is programmed and / or configured to: receiving, from the user data database, allocation data associated with accessing the user data from the requester system data; and The allocation data associated with the user data is stored in the immutable ledger.

7. The system according to claim 6, wherein: The at least one server computer is programmed and / or configured to: comparing allocation data associated with the user data with consent data associated with the user data; determining compliance of said allocation data with conditions of said consent data; as well as An indication of compliance of the allocated data is stored in the immutable ledger.

8. The system according to claim 5, wherein: The at least one server computer is programmed and / or configured to: receiving, from the user device, a request to revoke consent associated with the user data; updating the consent response based on the revocation request; as well as The updated consent response is communicated to the user data database.

9. A computer program product comprising at least one non-transitory computer readable medium, the at least one non-transitory computer readable medium comprising one or more program instructions that, when executed by at least one processor, cause the at least one processor to: receiving a first data request from a requestor system for user data associated with a user, the first data request including at least one use case, the user data being stored in a user data database separate from a consent database; transmitting a response to the first data request to a requestor system, the response indicating validation of the first data request based on a determination that the at least one use case complies with consent criteria associated with at least one allowed use case; transmitting a consent request to the requestor system for display to the user on a user device associated with the user; receiving a consent response from the requester system based on input from the user device, the consent response indicating that the user consents to sharing the user data requested in the first data request; storing consent data associated with a consent response to the user data requested in the first data request in an immutable ledger; receiving a consent verification request from the user data database, the consent verification request being based on a second data request for the user data from the requestor system to the user data database; verifying the consent verification request based on the consent data stored in the immutable ledger; transmitting a consent verification response to the user data database based on verifying the consent verification request, the consent verification response indicating that the user consents to sharing user data from the user data database with the requestor system; receiving, from the requestor system, utilization data associated with consent to use user data; storing utilization data associated with the user data in the immutable ledger; comparing utilization data associated with the user data with consent data associated with the user data; determining compliance of said utilization data with the conditions of said consent data; storing an indication of compliance of the utilization data in the immutable ledger; receiving, from the user data database, an audit request associated with the user data; as well as An indication of compliance of utilization data associated with the user data is communicated to the user data database.

10. The computer program product of claim 9, wherein the one or more program instructions further cause the at least one processor to: receiving, from the user data database, allocation data associated with accessing the user data from the requester system data; and The allocation data associated with the user data is stored in the immutable ledger.

11. The computer program product of claim 10, wherein the one or more program instructions further cause the at least one processor to: comparing allocation data associated with the user data with consent data associated with the user data; determining compliance of the allocation data with the conditions of the consent data; and An indication of compliance of the allocated data is stored in the immutable ledger.

Images