Systems and methods for data transfer management

Abstract

A computer-implemented method of securing data transmissions is provided. The method comprises the following steps: defining two or more condition sets for performing data transmission as a sequence of user agreement steps in the form of a corresponding smart contract; receiving a data transmission request; determining a security required for the data transmission request; selecting one of the defined condition sets according to the determination; requesting user agreement according to the sequence defined by the smart contract about the selected condition set; the requested data transmission is performed after the user agreement of all requests is approved. Further, a system for securing data transmissions is provided.

Description

Technical Field

[0001] The present invention relates to a computer implemented method and system for protecting data transmission. Background Art

[0002] Protecting data and its transmission against unintended access is a major goal of modern data management. The explosive rise in the amount of data, their value in terms of generation cost and potential impact, and the accelerating regulatory and technical demands on their security have stimulated recent interest in systematic yet flexible and future-proof solutions for data management. In particular, the management of sensitive data such as medical data under additional regulatory requirements, such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), etc., poses a challenge for technical solutions: how to balance technical requirements and additional demands imposed by evolving regulatory standards while ensuring the security integrity of the inherently valuable data content.

[0003] A technical solution is found in blockchain technology, which employs a distributed ledger, which inherently brings the properties of decentralization, immutability, and tamper-proof verification to a consolidated data management system - properties that help address the challenges presented above.

[0004] While early generation of blockchain solutions, such as those around the Bitcoin use case, specifically when the proof-of-work consensus algorithm was employed, were considered too technically demanding and too rigid for application in blockchain-assisted data management, modern solutions, especially those based on the proof-of-stake consensus algorithm, offer the required flexibility for practical use.

[0005] Recent approaches to data management that incorporate distributed ledgers have recognized that, for security and efficiency reasons, sensitive data is best not stored on the ledger, but rather utilizes smart contracts, the algorithms implemented by the blockchain, to mediate off-chain data transactions. This combines the benefits of blockchain technology with conventional data management approaches, while reducing both the need for still resource-intensive processing within the blockchain environment and the potential exposure of sensitive data in distributed systems.

[0006] In contrast to the widely used proprietary blockchain-implemented data management systems, several applications of blockchain regulation are known in the prior art. Specifically, with regard to the application to sensitive medical data, US patent application US2018082023 AA discloses a blockchain-based method and system for protecting the transmission of off-chain data using specifications implemented as smart contracts stored on a blockchain. Specifically, it discloses the implementation of smart contracts in a transaction manager to provide supervision and control of transactions involving data exchange, such as controlling data isolation, when and how control is implemented, and how long an entity can access and / or store data.

[0007] Definitions of technical terms in the field of blockchain technology described in the cited publications are considered to be examples of known prior art, and they are deemed to be incorporated into this application by reference.

[0008] Despite the flexible use of smart contracts in the prior art to implement various off-chain data transfer specifications, even most modern blockchain solutions face inherent technical requirements for blockchain systems; namely, each transaction that complies with the smart contract specification requires dedicated resources inherent to the blockchain's consensus algorithm, such as processing time, energy, etc. For practical applications in large-scale data transmission that potentially incorporates countless transactions, the reducible and scalable requirements of the system that balances the increased security standards are considered to be an unmet need for an exhaustive solution that has not yet been anticipated in the prior art. Summary of the invention

[0009] The present invention solves the existing problem by means of the features of the independent claims 1 and 10. The features of the dependent claims present preferred embodiments of the invention.

[0010] The present invention discloses a computer-implemented method for protecting data transmission, comprising the following steps: defining two or more condition sets for performing data transmission as a sequence of user consent steps in the form of corresponding smart contracts; receiving a data transmission request; determining the required security for the data transmission request; selecting one of the defined condition sets based on the determination; requesting user consent based on the sequence defined by the smart contract regarding the selected condition set; and executing the requested data transmission after all requested user consents are approved.

[0011] The present invention also discloses a system for protecting data transmission, comprising: an interface to one or more user systems; one or more interfaces to a database; and one or more interfaces to a distributed ledger system, wherein the system is configured to create two or more condition sets for performing data transmission from / to the database based on input from the user interface, as a sequence of user consent steps in the form of corresponding smart contracts to be stored on the distributed ledger component, and wherein the system is also configured to determine the required security for the requested data transmission.

[0012] The problem is solved by the features of the present invention in the following ways:

[0013] More than one specification for a data transfer is generated for storage on a distributed ledger. In this way, the flexibility of the system can be technically implemented in a variety of ways that are suitable for the specific kind of data transfer to be performed.

[0014] Additionally, a determination of a desired security level for the requested data transfer request is performed. This allows, following a subsequent selection based on the determination, the use of a smart contract to regulate the data transfer based primarily on achieving a particular security level; e.g., as inferred from the request and / or underlying data.

[0015] The implementation of smart contracts as a sequence of user consent requests and approvals ensures that potential parties involved in data transfers can influence the execution of all transactions incorporated into the data transfer through unavoidable specifications. The requested data transfer is only executed when all required consent requests are approved.

[0016] The problem is explicitly addressed by not overshooting security provisions (ie, translating to required system resources) but still satisfying the required approvals for users and data at all levels of granularity involved.

[0017] The disclosed system facilitates a problem solution by providing an intermediary layer between the components of a blockchain-mediated data management system. In this intermediary layer, the disclosed method of protecting data transmission can be implemented while ensuring that there is no direct contact between the components of the wider system regarding data transmission specifications. This serves as a necessary filtering component for requests entering the system to prevent external influences on data transmission. This also serves as an independent buffer component that prevents any data leakage that may be possible in direct component-to-component contact. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Hereinafter, preferred embodiments of the present invention will be explained with reference to the accompanying drawings:

[0019] Figure 1: A schematic diagram depicting components of a system according to the present invention.

[0020] Figure 2 : A flow chart depicting the processing steps of the method according to the present invention. DETAILED DESCRIPTION

[0021] Specific embodiments of the present disclosure will be described below.

[0022] It will be apparent to those skilled in the art that such embodiments are provided as examples only, and that various changes, modifications and substitutions may be envisioned by those skilled in the art without departing from the present invention. When implementing the present invention, several alternatives to the described embodiments of the present invention may be employed.

[0023] exist Figure 1 A schematic diagram of the general architecture of a blockchain-mediated data management system 100 is depicted in FIG. Also included is a system 110 of the present invention implemented as an intermediate layer connecting other system components.

[0024] The basic system components are a distributed ledger subsystem 130 on which smart contracts 131 are executed to mediate data transfers between other system components; one or more localized or distributed databases 120, which serve as repositories for data to be transferred, regulated by smart contracts 131; and user subsystems 140, 150 as system access points for parties involved in data transfers. Typically, if the system 100 is used only as a single-party storage system, one such user subsystem is sufficient. The applicability of the data transfer system makes two or more such user subsystems reasonable, and the number of different user subsystems can be arbitrarily expanded to achieve multi-party data transfers.

[0025] According to the present invention, a subsystem 110 (middle layer) is provided to connect the database 120, the user subsystems 140, 150 and the distributed ledger component 130. The middle layer 110 includes interfaces 114, 115 to the user components 140, 150 of the system 100, respectively. It also includes an interface 112 to the database 120 and an interface 113 to the distributed ledger 130.

[0026] The middle layer 110 is implemented as a computer-implemented system having the ability to process data using resources of an implemented computer according to the configuration of the middle layer 110. Such configuration includes controlling data input / output between the middle layer 110 and system components 120, 130, 140, 150 via respective interfaces 112, 113, 114, 115. Implementation in personal computing devices, servers (local and / or distributed), mobile computing devices, and other computer systems is considered a matter of preference known to those skilled in the art.

[0027] The middle layer 110 is also configured to create two or more sets of conditions for performing data transmission from / to the database 120 based on input from the user interfaces 114, 115 as a sequence of user consent steps in the form of corresponding smart contracts 131 to be stored on the distributed ledger component 130. Such a set of conditions can be implemented by a set of unique identifiers assignable to different users (e.g., IP addresses) and / or a set of unique identifiers assignable to data packets (e.g., its location on a specific database 120, metadata, etc.). In addition, the set of conditions can include a specific sequence for the conditions to be met, or conversely, a parallel sequence of independent fulfillment of the conditions can be implemented. It is essential to the present invention that the middle layer 110 is configured to generate two or more sets of such conditions that are converted to multiple smart contracts 131. The availability of multiple smart contracts 131 provided in this way allows the system to be adapted with respect to its data transmission by selecting a more suitable smart contract 131 defined.

[0028] The middle layer 110 is also configured to determine the required security for the requested data transfer. This determination is performed by processing requests received via the user interfaces 114, 115. In one embodiment, such a request directly includes an indication of the required security. In a further or additional embodiment, such a request includes an indication of the requested data, wherein the database 120 stores further information about the requested data related to security requirements, which is provided to the middle layer 110 via the interface 112 for the determination. In a preferred embodiment, the determination is intended to adopt a minimum, maximum or average value of different quantifiable security requirements by different user subsystems 140, 150 and / or database 120.

[0029] In a preferred embodiment, the middle layer 110 is also configured to create a smart contract 131 by balancing the determined required data transmission security with the total complexity of the transactions included in the data transmission. To this end, the requested data transmission is understood as a plurality of transactions to be performed, wherein the transaction may require approval for the smart contract 131, and wherein one transaction in the case of the highest granularity involves two specific users and a specific data set. Since each transaction to be regulated by the smart contract 131 implemented in the distributed ledger 130 increases the total demand on the ledger 130 system, a trade-off between the maximum number of possible transactions (which is equal to the highest security) and the minimum number of required transactions (which is equal to the highest system 130 efficiency) will be considered, which is technically implemented in this embodiment. The balancing involves a comparison of the security level determined by the middle layer 110 as required and the security level attributable to the plurality of defined condition sets created by the middle layer 110 as a smart contract 131 on the distributed ledger 130. In the most direct implementation, the balancing identifies a condition set in the plurality of defined condition sets that can be attributed to a minimum security level higher than the security defined as required.

[0030] In a preferred embodiment, the middle layer 110 is also configured to prompt the execution of a data transfer from / to the database 120 after receiving a prompt from the distributed ledger system 130 from the interface 113. Preferably, such a prompt from the ledger 130 is the result of the successful execution of a set of conditions implemented as a smart contract 131. In contrast to a direct connection between the ledger 130 and the database 120, routing the data transfer prompt to the database 120 via the interface 113 on the middle layer 110 and via the interface 112 brings about a number of advantageous effects consistent with the present invention. First, the middle layer acts as a filtering component that prevents prompts from causing data transfers that are not wanted by users of the system. Considering that the ledger 130 is a potentially open system, this reduces the risk of unauthorized data access. In addition, in the case of a distributed database 120, only one interface between the ledger 130 and the data storage component needs to be provided. This reduces the demand on the ledger system 130 because the prompt for the data transfer generated by any successfully executed smart contract 131 becomes an invariant of the data location. Furthermore, any definition of users and processing required for the execution of the data transfer may be implemented within the middle tier 110, thereby reducing the requirements on the database 120. Following the data transfer prompt received by the database 120, the requested data is preferably processed in a manner similar to the data transfer prompt; i.e., via the interface 112 on the middle tier 110 via the user interfaces 114, 115 to the receiving user 140, 150, which allows additional data validation and processing to be performed within the middle tier 110 independently of the user systems 140, 150.

[0031] In one aspect of the present invention, the middle layer 110 is also configured to send consent request data from the distributed ledger system 130 to one or more users 140, 150 via respective interfaces 114, 115, and to send consent approval data from one or more users 140, 150 to the distributed ledger system 130 via respective interfaces 114, 115. Since the smart contract 131 is implemented as a set of conditions related to consent (e.g., consent of users participating in a data transfer), and since several different parties are potentially involved in different transactions included in the requested data transfer, it is advantageous to employ the middle layer 110 as a central subsystem for collecting and redirecting relevant consent requests and approvals. The details of the consent required for successful execution of the smart contract 131 may include one or more users, a potential sequence of required user interactions, specific data regarding the need for consent, etc. Implementing the request / approval process within the processing performed by the middle layer 110 reduces the technical requirements of the ledger component 130, as it only has to verify the conditions defined by the smart contract 131 without considering how the consent is approved. Additionally, any changes to the details of the users 140, 150 and metadata related to specific data stored in the database 120 can be reflected by editing the configuration of the middle layer 110 without requiring a transaction on the ledger 130. Similar to avoiding direct connections between the ledger 130 and the database 120, the middle layer 110 contributes to the overall system security by preventing direct connections between the users 140, 150 and the ledger 130.

[0032] In one aspect of the present invention, the intermediate layer 110 is implemented in a hardware environment configured for the specialized execution of the system 110 and for the processes required thereof. Such hardware-implemented layers are known in the prior art. In the specific case of the present invention, the hardware components that are limited in their functionality further reduce the risk of external influences on the system 100 by excluding data connections and / or functions that are not expected by the system 100. Therefore, security can be further improved.

[0033] The intermediate layer 110 is preferably further configured to perform a method according to the present invention, which is further described below.

[0034] exist Figure 2 The computer-implemented method and preferred embodiments of the present invention are schematically depicted in the flowchart of FIG.

[0035] The computer-implemented method according to the present invention comprises the following steps: defining 210 two or more condition sets 270 for performing a data transfer as a sequence of user consent steps in the form of a corresponding smart contract; receiving a data transfer request 220; determining the required security for the data transfer request; selecting 230 one of the defined condition sets according to the determination; requesting user consent 240 according to a sequence defined by the smart contract with respect to the selected condition set; and executing 250 the requested data transfer after all requested user consents are approved. If the condition set is not met in whole or in part, for example if one consent request is not approved, the method blocks 250b the requested data transfer instead of executing it. The definition 210 of multiple condition sets as smart contracts strictly limits the content and form of general smart contracts. The defined conditions directly relate to the defined sequence of consent process steps to be performed for the smart contract to be considered successfully executed. In general, the consent process is performed by triggering a consent request to be transmitted to the corresponding user based on the smart contract, and after the consent, the consent approval is transmitted from the user back to the smart contract for verification. The smart contract defined in this way distinguishes between the approver of the consent and the object of the different data assets that constitute the requested data transfer, for example, according to the condition set. The granularity of both the user and the consent object is flexible and is a distinguishing factor between at least two defined condition sets. Since in general, each consent process requires interaction with the smart contract, it is advantageous to reduce the granularity to a minimum (the minimum consent process required). This is contrary to the purpose of maximizing the security of the requested data transfer. Therefore, providing the feature of multiple condition sets defined in this way directly helps to provide a flexible method suitable for security and efficiency requirements. In general, the required security for the requested data transfer can be quantified according to any but comparable measure of the granularity of user interaction and the degree of detail in data control. Although providing two or more defined condition sets allows the selection of a smart contract to meet the required security options, the selection process preferably further includes the determination of a smart contract that best fits the requirements in the defined smart contracts as measured by the mathematical distance of the quantifiable security level.

[0036] In a preferred embodiment, the determination of the required security for the requested data transmission is based on the data transmission request and / or on the data to be transmitted. Although in general, the required security can be selected only manually 230, i.e., by additional user interaction via data transmission to / from the user, without including any additional information in the data transmission request 220, in a preferred aspect of the present invention, data related to the required security level is included directly or indirectly in the received 220 data transmission request. This data may include a direct relationship to the security level previously defined as a condition set 210. This data may also include only a granularity level, according to which the appropriate security level defined 210 can be matched in an additional step 230. Additionally or alternatively, the determination of the required security level may depend on the data to be transmitted when the requested transmission is performed 250a. To this end, the request 220 includes information about the requested data, i.e., metadata, from which the required security level can be determined directly or indirectly. This can be the sensitivity of the underlying data, its (monetary) value, a benchmark against other (meta) data, and other factors. This can also be / contain information about the encryption and / or de-identification of the underlying data. A link to the requested data, for example at a storage database, with further information about the corresponding data relating to the required security level is also a possible embodiment.

[0037] In a further preferred aspect of the present invention, the method further comprises a step of recording 260 the approval of the user's consent after requesting the user's consent, i.e., during the execution of the smart contract 240, and before the execution 250a / b of the data transfer, and / or further comprises a step of recording the execution of the data transfer after the execution 250a / b of the data transfer. As inherent to smart contracts, each such complete execution will be stored on the underlying ledger system. For reasons of traceability and audit, it is preferred to optionally include a record 260 of a single consent-request / approval and / or the result of the execution 250a / b. The record 260 of a single consent or a series of consents constituting the entire smart contract is additionally beneficial for the case in which the smart contract 240 is executed, wherein a portion of the requested consent request is not approved, i.e., a block is generated for the requested data transfer 250b. Then, the repetition of the same contract can utilize the partially approved smart contract recorded 260 in this way to request additional consents only based on what is left to be approved after the first execution. Smart contracts that were mistakenly not approved can then be repeated / corrected in a very efficient manner, saving interactions with the ledger and therefore with system resources.

[0038] In an additional aspect of the invention, the method step of selecting 230 a defined set of conditions is performed by balancing the security of the data transfer with the total complexity of the transactions included in the requested data transfer. The balancing involves a comparison of the security level determined according to the needs with the security level attributable to the plurality of defined 210 condition sets 270 created as smart contracts. In the most straightforward implementation, the balancing identifies one of the plurality of defined condition sets that can be attributed to a minimum security level that is higher than the security defined according to the needs.

[0039] Preferably, multiple defined 210 and subsequently selected 230 security levels 210 are implemented in a manner that allows for a reduction in the required security of data transmission to scale with the reduction in process requirements on the ledger 130 components. To this end, the following multiple security levels 270 that can be implemented by the smart contract 131 are considered to be preferred embodiments of the present invention. They can be used in combination to synergize the efficiency, flexibility and security of the overall system.

[0040] A specifically defined security level 271, which can be selected from a plurality of defined security levels 270 according to the method of the present invention, reflects a multi-consent single asset transaction, in which all single sub-data units constituting the total data transfer need to be agreed to by multiple user parties for transfer. This is achieved by the method by specifying a sequence of user consent steps 271 to include requests for corresponding independent consents of two or more users for each single data transaction included in the requested data transfer. Only when all user consent requests (i.e., independent of each user to each asset transaction) are approved, the smart contract defined in this way is executed 250a and prompted to execute the transfer. In the event that a single consent request of a single user is not approved, the requested transfer is not executed, i.e. blocked 250b. This security level is considered to be the most secure one that gives all parties total control over what data is exchanged at what granularity level. Since each consent required by the smart contract 131 requires interaction with the ledger 130, the sequence of system processes implied by this security level is also considered to place the highest technical demands on the ledger component 130.

[0041] A further specifically defined security level 272, which can be selected from a plurality of defined security levels 270 according to the method of the present invention, reflects a single-consent single-asset transaction, in which all single sub-data units constituting the total data transfer need to be consented to by one user party for transfer, while the other user party of the transfer only needs to consent to transfer all their data once, which is independent of granularity. This is achieved by the method by specifying a sequence of user consent steps 272 to include a corresponding independent consent for each single data transaction included in the requested data transfer by one user and a request for a single consent for all transactions included in the requested data transfer by one or more other users. This security level 272 is considered to be less secure than the security level reflecting multiple consent single-asset transactions 271, because for one user, the control of consenting to the data transfer is limited to one interaction. The restriction on the interaction is beneficial to reduce system requirements. In particular, in data transfers in which one user contributes a large portion of the transactions as part of the transfer and one other party has a choice as to which of the transactions in the transaction are to be executed on a case-by-case basis, the implementation of such a security level 272 described increases the flexibility and efficiency of the process. For the realization of such a security level 272, it is further preferred if only a partial data transfer of the transaction according to the agreement 240 is carried out in step 250a.

[0042] A further specifically defined security level 273, which can be selected from a plurality of defined security levels 270 according to the method of the present invention, reflects a single consent multi-asset transaction, in which all single sub-data units constituting the total data transfer need to be agreed to by all user parties only once for the transfer. This is achieved by the method by specifying a sequence 273 of user consent steps to include a request for a single corresponding consent for all transactions included in the requested data transfer for two or more users. This security level 273 is considered to be less secure than the previously described security levels 271, 272 because the control of the consent to the data transfer is limited to one interaction for all users. The limitation on interactions is beneficial in reducing system requirements. Specifically, in data transfers in which one user contributes a large number of transactions as part of the transfer and one other party has no choice as to which of the transactions in the transaction are to be executed on a case-by-case basis, the implementation of such a security level 273 described significantly increases the efficiency of the process.

[0043] A further specifically defined security level 274, which can be selected from a plurality of defined security levels 270 according to the method of the present invention, reflects batch transactions, wherein all single sub-data units constituting the total data transfer need only be agreed to be transferred once by only one user party. This is achieved by the method by specifying a sequence 274 of user consent steps to include a request for a single consent for all transactions included in the requested data transfer for a single user. This security level is considered to provide the lowest security of the discussed levels 271, 272, 273, because only one user can affect the control of the data via consent to the data transfer. The availability of data in the database is considered to find a specific use case in the scenario where the data provides the consent of the user to transfer. Therefore, the data transfer specification process can be limited to a minimum interaction with the system, that is, a single consent approval of one other user within the smart contract execution 240. Any combination of the defined security levels 271, 272, 273, 274 can be included in the plurality of definitions 270.

[0044] In a preferred aspect of the present invention, consent approval is a passive process. In contrast to active approval that requires user interaction for verification, passive consent approval is implemented by only verifying the existence of a historical active consent of the corresponding user. If the user does not actively withdraw a historical consent at the time of data transmission request and / or execution, each consent request approval after the first consent is considered to be approved. This implementation allows reducing redundancy in sequential data transmission involving at least one of the same users, translating into technical efficiency.

[0045] The methods and systems of the present invention are particularly advantageous in the management of the transmission of medical data. Medical data has an inherent value to its providers and users, since non-negligible effort, measurements, research, etc. are required to obtain such data. In addition, medical data is widely regarded as being particularly sensitive, which places certain requirements on security when handling such data. Since medical systems are typically subject to interaction with and access to medical data by various interested parties (patients, practitioners, data analysts, insurance companies, etc.), the requirements placed on data transmission systems and methods are particularly high. Finally, the handling of medical data is subject to regulatory constraints, which are implemented differently at the regional / national level and are subject to changes over time.

[0046] The provided systems and methods provide solutions for the above-mentioned aspects in medical data management by disclosing a flexible, secure and efficient scheme that enables scalability to user needs.

Claims

1. A computer-implemented method for protecting data transmission, comprising the following steps: defining two or more sets of conditions for performing a data transfer as a sequence of user consent steps in the form of corresponding smart contracts, Receive data transfer request, determining the required security for the data transfer request, selecting one of the defined condition sets according to the determination, requesting user consent according to the sequence defined by the smart contract with respect to the selected set of conditions, The requested data transfer is performed after all requested user consents are granted.

2. The method according to claim 1, wherein: The determination of the required security for the requested data transmission is based on the data transmission request and / or on the data to be transmitted.

3. The method according to claim 1 or 2 further includes a step of recording approval of the user consent after requesting the user consent and before the execution of the data transfer, and / or further includes a step of recording the execution of the data transfer after the execution of the data transfer.

4. The method according to any one of claims 1 to 3, wherein: The selection of the defined set of conditions is performed by balancing the security of the data transmission with the overall complexity of the transactions involved in the data transmission.

5. The method according to claim 4, wherein: One sequence of user consent steps includes requests for respective independent consents from two or more users for each single data transaction included in the requested data transfer.

6. The method according to any one of claims 4 or 5, wherein: A sequence of user consent steps includes a request for a respective separate consent from one user for each single data transaction included in the requested data transfer and a single consent from one or more other users for all transactions included in the requested data transfer.

7. The method according to any one of claims 4 to 6, wherein: One sequence of user consent steps includes a request for a single respective consent from two or more users for all transactions included in the requested data transfer.

8. The method according to any one of claims 4 to 7, wherein: A sequence of user consent steps includes a request for a single consent from a single user for all transactions included in the requested data transfer.

9. The method according to any one of claims 5 to 8, wherein: The consent described is passive consent.

10. A system 110 for protecting data transmission, comprising: an interface 114 , 115 to one or more user systems 140 , 150 ; one or more interfaces 112 to a database 120; and one or more interfaces 113 to a distributed ledger system 130, wherein the system 100 is configured to create two or more sets of conditions for performing a data transfer from / to the database 120 based on input from the user interfaces 114, 115, 112 as a sequence of user-agreed steps in the form of corresponding smart contracts 131 to be stored on the distributed ledger component 130, and wherein the system 110 is further configured to determine the required security for the requested data transfer.

11. The system 110 according to claim 10 is further configured to create the smart contract 131 by balancing the determined required data transmission security with the total complexity of transactions included in the data transmission.

12. The system 110 according to any one of claims 10 or 11, further configured to prompt execution of data transfer from / to the database 120 after receiving a prompt to the distributed ledger system 130 from the interface 113.

13. The system 110 according to any one of claims 10 to 12 is further configured to send consent request data from the distributed ledger system 130 to one or more users 140, 150 via the corresponding interfaces 114, 115, and to send consent approval data from the one or more users 140, 150 to the distributed ledger system 130 via the corresponding interface 113.

14. The system 110 according to any one of claims 10 to 13, further configured to perform the method according to claims 1 to 9.

15. A hardware environment, which is configured to exclusively execute the system 110 according to any one of claims 10 to 14.

Images