Data retention attestation using blockchain

Abstract

A computer-implemented method of providing attestation of a data retention policy using a blockchain wherein a smart contract defines one or more respective data retention requirements for storing a data item at a storage location, and wherein the method comprises: receiving a data item and / or an encrypted version of the data item, and one or more data retention details of the retention policy; providing the data item and / or the encrypted version of the data item and the data retention details to a smart contract; and executing the smart contract, wherein the smart contract is configured to determine whether the data retention details meet the data retention requirements or not when the smart contract is executed; and if so, submitting a transaction to the blockchain, where the transaction includes the data retention details and at least one of the following: the data item; the encrypted version of the data item; a reference to the data item is stored at the storage location.

Description

Technical Field

[0001] The present disclosure relates to a method of providing proof of data retention policy using blockchain. Background Art

[0002] Data retention policies or record retention policies define how data should be stored to meet operational or regulatory compliance. Data retention policies are often part of the overall data management strategy of organizations such as companies and government agencies. Such policies are becoming increasingly important due to the increasing amount of data that organizations need to store and process. Therefore, data retention policies are needed to define the duration for which organizations must retain certain data to prevent data from being stored indefinitely. Through this targeted application of digital policies and retention protocols, organizations can also control how data is stored for compliance or regulatory reasons and how it is disposed of after it is no longer needed. Data retention policies typically contain an explanation of the different types of data and records to be stored, an explanation about formatting the data, retention periods, and a description of the systems in which the data will be stored. The elements included in the policy are often based on the rules of the regulatory body that governs the industry. Retention policies sometimes specify that historical data should be kept after the end of its usefulness period, such as by archiving to a tertiary data warehouse. Organizations must demonstrate that they selectively retain and delete data based on the specific regulatory requirements of their industry.

[0003] When the information to be stored includes personal data, additional requirements are often set by implementing the General Data Protection Regulation (GDPR). GDPR requires organizations to demonstrate that personal data is managed appropriately and how it is stored throughout its lifecycle, especially at the end of its lifecycle. Failure to comply with these regulations can result in significant fines for organizations, as observed by end users. Summary of the invention

[0004] Existing techniques for storing data retention policies have several problems and can be difficult to retrieve data. The situation becomes particularly complicated if data corruption occurs.

[0005] One issue is data access. Accessing current and previous information has become a challenge. The rapidly growing volume of data makes finding personal data records a daunting task. Another issue is cost. Although the cost of data storage has dropped significantly, the overall cost of storing data also includes other factors. For example, the labor costs incurred in finding and retrieving data should also be considered. In addition, there are infrastructure costs, migration costs, and professional archiving costs. Another issue is risk. Since data must be stored somewhere, it depends on the ability of the storage provider to store said data securely. Data breaches due to inadequate data policies are a burden for most organizations because they lead to direct revenue losses, damage to reputation, and often incur huge fines.

[0006] Current systems for managing data retention policies at the data file level roughly resemble decentralized systems, as in many cases the retention process is beyond the control of the IT department and is not controlled by management, and the links between the parties in the system can be very weak. For more structured retention policies, data is currently stored only by the relevant parties in the organization or regulatory body. This in turn describes a centralized rather than decentralized approach.

[0007] Therefore, a fully decentralized approach is needed to manage data retention policies that can be easily implemented by organizations and is transparent to all parties involved.

[0008] According to a first aspect disclosed herein, a computer-implemented method is provided, the computer method using a blockchain to provide a data retention policy proof. A smart contract defines one or more corresponding data retention requirements for storing a data item at a storage location. The method includes receiving a) a first data item and / or an encrypted version of the first data item from a party, wherein the first data item is to be stored at the storage location, and b) one or more corresponding data retention details of a first retention policy associated with the first data item. The method also includes providing the smart contract with a) the encrypted version of the first data item and / or the first target data item, and b) the one or more corresponding data retention details of the first retention policy. Execute the smart contract. When executed, the smart contract is configured to determine whether the one or more corresponding data retention details of the first retention policy meet the one or more corresponding data retention requirements. If it is determined that the one or more corresponding data retention details of the first retention policy meet the one or more corresponding data retention requirements, the smart contract is configured to submit a first blockchain transaction to the blockchain. The first blockchain transaction includes the one or more data retention details of the first retention policy and at least one of: i) the first data item; ii) the encrypted version of the first data item; iii) a reference to the first data item being stored at the storage location.

[0009] A retention policy provider (e.g., a blockchain node) executes a smart contract (i.e., a self-executing code). The smart contract defines a set of data retention requirements. The data retention requirements specify the information that must be provided in order to issue a retention policy for the purpose of storing a data item (data item is generally used to refer to any type of data). For example, the smart contract may require the file type and / or format of the data to be stored, the storage location of the data, the effective date when the data will be deleted, the retention period, etc. The data item is sent to one or more storage service providers. A party (e.g., a user or user group, such as an organization) sends a data item and / or an encrypted version of the data item to the provider. In addition, one or more data retention details are sent, one data retention detail for each data retention requirement specified by the smart contract. The one or more data retention details form a data retention policy for the data. The data retention details and the data item (or encrypted data item) are provided to the smart contract. The smart contract verifies whether the provided data retention details meet the requirements, and if so, the smart contract sends a transaction to the blockchain. The transaction includes the data retention policy. The transaction may also include the data item or the encrypted data item. Additionally or alternatively, the transaction may include a reference to the storage location of the data item.

[0010] Using blockchain to record data retention policies has several benefits. First, the policy can be accessed at any time, as the decentralized network does not suffer any downtime. Access to the policy is location-independent and can be accessed globally. No single individual or entity is responsible for storing the policy, making it difficult (if not impossible) for a third party to manipulate it. An immutable link is created between the data and the associated retention policy, which means that the retention policy for a given data record cannot cause any disputes. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to facilitate the understanding of the present disclosure and to show how embodiments may be implemented, reference will now be made by way of example to the accompanying drawings, in which:

[0012] Figure 1A Schematically illustrating an exemplary method for mining new blocks to a blockchain;

[0013] Figure 1B A pair of blockchain transactions are schematically shown;

[0014] Figure 2 schematically illustrates an exemplary system for recording a data retention policy on a blockchain; and

[0015] Figure 3 An exemplary process for recording a data retention policy on a blockchain is schematically illustrated. DETAILED DESCRIPTION

[0016] Exemplary blockchain systems

[0017] Figure 1A Schematically illustrated is an exemplary method for mining a new block 101n on a blockchain 102. The blockchain 102 is a form of a distributed database (or ledger) that serves as a record of all valid transactions 103 transmitted to the blockchain network.

[0018] Valid transactions 103 broadcasted on the blockchain network are recorded in the form of blocks by miners (also called mining nodes) on the blockchain 102. The blockchain transaction 103 is used to transfer custody of a certain number of digital tokens. Figure 1B A pair of transactions 103 are shown in FIG. As shown, each transaction 103 includes, among other things, at least one input and at least one output. An input is a reference to an unspent transaction output (UTXO) of a previous transaction. For example, in Figure 1B In, Tx 1 Contains reference Tx 0The input of a UTXO of a transaction 103. Transaction 103 uses an unspent transaction output (UTXO) as an input and assigns its value to a new output. The output typically includes a locking condition that locks the value of that output, requiring certain data (e.g., a set of keys or other information) to be provided in the input of the new transaction 103 in order to unlock it. The output can also be used to post data to the ledger. The input of transaction 103 typically includes a digital signature that signs the transaction 103. Therefore, the chain of transactions 103 includes a chain of digital signatures that depicts the entire history of valid exchanges of digital tokens, tracing back to their creation.

[0019] Return now Figure 1A , blockchain 102 begins with a "genesis block" 101g, which is the first block 101 ever created. Each block on blockchain 102 references the previous block, all the way back to the genesis block. That is, the nth block 101 references the n-1th block 101, the n-1th block references the n-2th block 101, and so on, all the way to genesis block 101g.

[0020] Block 101 contains an ordered list of blockchain transactions 103 and a block header 104. Block header 104 includes a Merkle root 105 generated by hashing the ordered list of blockchain transactions 103 into a Merkle tree, a timestamp, a reference 106 to the previous block 101 upon which the current block 101 is built, and a means of verifying that other miners have accepted block 101 as a valid block. The means of verification is the answer to a hash puzzle that is unique to each block 101. The blockchain protocol run by the nodes of the blockchain network uses a hashing algorithm that requires miners to pre-build candidate blocks 101c before attempting to solve the puzzle. Without the correct answer, the new block 101n cannot be submitted to the network, and the process of "mining" is essentially a process of competing to be the next to find the answer to "solve" the current block 101. The hash puzzle in each block 101 is difficult to solve, but once a valid solution is found, it is easy for the rest of the network to confirm that the solution is correct. There are multiple valid solutions for any given block 101, only one of which needs to be found for the block 101 to be solved.

[0021] The process of attempting to mine a new block 101n into the blockchain 102 is briefly described below. When a blockchain transaction 103 is transmitted to a mining node, it is first verified according to the consensus rules of the blockchain network. If the transaction 103 is valid, it is added to a pool 107 of unconfirmed transactions 103. The pool 107 is sometimes called a "mempool". The mempool 107 acts as a temporary storage pool for transactions 103 to be mined into the next block 101n. Each mining node has its own mempool 107, and any given transaction 103 can be included in multiple mempools 107 if it has been broadcast to multiple mining nodes.

[0022] A hash function is a function that converts a string of data of arbitrary length into a fixed-length value, called a hash value or hash digest. Hashes are one-way functions, which means that it is not feasible to determine the input data by looking at the hash value it produces. On the other hand, it is very simple to run the same input data through the same hash function and regenerate the same hash. Some blockchain protocols use the SHA-256 hashing algorithm, while some use the SHA-256 hashing algorithm twice, i.e., the candidate block header is passed through the same hashing algorithm twice.

[0023] The Merkle tree is a data structure in the form of a hash value tree. In the blockchain 102 environment, the transaction 103 is hashed to form the leaf nodes of the tree. Figure 1A As shown, transaction Tx1 is hashed to form leaf node D1, transaction Tx2 is hashed to form leaf node D2, and so on. Leaf node pairs are hashed after being concatenated to form nodes in higher layers of the tree. For example, leaf nodes D1 and D2 are concatenated and hashed to provide nodes in a higher layer. Node pairs in this layer are then concatenated and hashed to form nodes in higher layers of the tree. This process is repeated until only one node remains, called the root node or Merkle root 105.

[0024] The miner obtains the transactions 103 that it intends to include in the next block 101, then hashes these transactions into a Merkle tree structure and includes the resulting Merkle root 105 in a candidate block header 104. The miner then hashes the candidate block header 104 in an attempt to find a valid proof of work.

[0025] The candidate block header 104 (in combination with other data, as described below) is hashed until the result is less than another value (called a target value) so that a valid proof of work can be found. The target value is automatically adjusted by the blockchain protocol, so that it takes an average of 10 minutes for the blockchain network to find a valid proof of work.

[0026] In order to change the hash value, the mining node must add additional information to the candidate block header 104. Mining nodes typically use two "nonce fields" to change the value to be hashed, thereby changing the resulting hash value. The first nonce field 108 is contained in the block header itself, and the second nonce field is contained in the "Coinbase transaction." A Coinbase transaction is a transaction created by a mining node and included in a candidate block. Each field includes a counter parameter that can be incremented. The hash function loops through all values ​​of the first nonce field 108, then increments (or otherwise changes) the second nonce field, and then loops through all permutations of the first nonce field 108 again. Incrementing the second nonce field involves recalculating the Merkle root 105 when modifying the hash of the Coinbase transaction contained in the Merkle tree.

[0027] When a mining node finds a valid proof-of-work hash for a block 101 (i.e., a candidate block header 104 that hashes to a value less than the target value), the new block 101n is broadcast to the rest of the blockchain network. Other nodes on the network accept the new block only if all transactions 103 in the new block 101n are valid and not already included in a block. Each block 101 is timestamped and references the hash of the previous block 101, thereby forming a blockchain (i.e., blockchain 102).

[0028] The above is a description of the "output-based" transaction model. Another transaction model is the "account-based" model. In this model, each transaction 103 does not define the number of digital tokens to be transferred by reference to unspent transaction outputs, but rather by reference to absolute account balances. The current state of all accounts is stored separately by miners in the blockchain 102 and continuously updated. In such a system, transactions 103 are sorted using the account's running transaction record (also known as a "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation.

[0029] Figure 2An exemplary system 200 for passing a hash value from a set of hash processing devices 201a, 201b to a hash processing pool 202 is schematically shown. In the exemplary system 200, there are two hash processing devices 201a, 201b, but the system 200 may generally include any number of hash processing devices 201. The system also includes a set of blockchain client applications 203a, 203b, 203c. Although only three client applications 203a, 203b, 203c are shown, the system may include any number of client applications 203. Typically, the client application 203 is configured to submit a blockchain transaction to the hash processing pool 202. The hash processing pool is configured to build a block template 101c and send the block template 101c (or at least a candidate block header 104 of the block template 101c) to the hash processing devices 201a, 201b. Each hash processing device 201 is configured to generate a candidate PoW solution based on the candidate block header 104. The system also includes a blockchain network 204, which includes a plurality of blockchain nodes.

[0030] Data Retention Certificate

[0031] Figure 2 An exemplary system 200 for recording a retention policy on a blockchain 102 is shown. As shown, the system 200 includes a smart contract provider (also referred to as a retention policy provider) 201. The retention policy provider can be a blockchain node. That is, the smart contract can be executed by the blockchain node. In general, the retention policy provider can be any party (e.g., a regulator, a company, an organization, a standard setting body, etc.) responsible for executing the smart contract described herein. The system 200 also includes a party 202 that is configured to send data to be stored at a storage service provider 203. The party can take any suitable form, such as a user, a user group, a company, an organization, a university, a charity, a medical group, etc. The storage service provider 203 is configured to store the data at a storage location. The storage can take any suitable form, such as local storage, cloud storage, etc.

[0032] System 200 also includes one or more nodes of the blockchain network. For example, these nodes can be configured to implement Figure 1A and Figure 1B The blockchain system described.

[0033] like Figure 2As shown, user 202 is configured to send data to be stored by storage service provider 203. The data can take any suitable form, such as an electronic file, such as a company or personal record, a media (e.g., audio or video) file, a non-fungible token, etc. User 202 wishes to record a data retention policy on blockchain 150. Retention policy provider 201 executes a smart contract that is configured to publish a retention policy in the form of a blockchain transaction if a set of requirements (i.e., conditions) are met. More specifically, the smart contract defines a set of data retention requirements that must be met before the data retention policy can be published. These data retention requirements can be defined by retention policy provider 201 or by a third party (not shown). For example, these requirements can be provided by a separate regulatory body, a standards committee, a government organization, etc. In some examples, user 202 is an employee or department of a company, and these requirements are set by the company.

[0034] A smart contract can be in the form of an executable program that can be written in a high-level computer programming language. In this case, the smart contract imposes conditions on the payload containing the data retention details. If these conditions are met, a retention transaction is sent to the blockchain.

[0035] User 202 submits a set of retention details to retention policy provider 201. The set of retention details corresponds to a retention requirement. That is, user 202 sends the retention details for each retention requirement so that the requirements specified by the smart contract are met. The smart contract verifies whether these requirements are met. If these requirements are not met, the retention policy is not issued. The smart contract (or more generally, retention policy provider 201) can notify user 202 that the verification failed. If these requirements are met, the smart contract submits a blockchain transaction to blockchain 102. In the case where the smart contract is executed by a blockchain node, the blockchain node can record the transaction directly on blockchain 102.

[0036] The transaction ("retention transaction") includes a retention policy that contains the set of data retention details. The retention policy may also include data retention requirements. The retention transaction also includes the data item itself or an encrypted version of the data item. The data item may be encrypted by hashing or cryptography (e.g., using a public key owned by the user 102 or the retention policy provider 201). Additionally or alternatively, the retention transaction may include a reference to the storage location of the data item.

[0037] In some examples, the smart contract is configured to generate a reservation transaction from scratch. In other examples, user 202 can send a transaction template to the smart contract, where the transaction template includes reservation details. The smart contract can verify that these details meet the requirements and submit the transaction template as a reservation transaction to the blockchain. This can include signing the transaction template with a digital signature.

[0038] As described above, user 202 may send data to retention policy provider 201 (i.e., in raw form). The smart contract may be configured to encrypt the data (e.g., hash the data) and include the encrypted data in the retention transaction. In other examples, user 202 may encrypt the data (e.g., by hashing or using public key encryption) and then send the encrypted data to retention policy provider 201.

[0039] In addition to sending the reservation transaction to the blockchain 102, the smart contract may also be configured to send the reservation transaction to one or more storage service providers 203 and / or the user 202 storing the data. Additionally or alternatively, the smart contract may generate an identifier for the reservation transaction and send the identifier to the user 202 and / or the one or more storage service providers 203. The identifier may be a hash or double hash of the reservation transaction.

[0040] As discussed, the smart contract verifies whether the set of data retention details provided meets the set of requirements for the published retention policy. These requirements and these details may include one or more of the following: file type and / or format; title; version number; department and / or agency responsible for creating and / or storing data; department and / or agency responsible for approving data retention details; date on which one or more data retention details are approved; retention period for which the storage service provider 203 will store the data; deletion date on which the data will be deleted from the storage location.

[0041] One or more of the data retention requirements may be in the form of data fields to be populated. For example, a requirement may be a "storage location" or a "storage service provider," which would be satisfied by providing the storage location or storage service provider, respectively, of the data item. As another example, a requirement may be an "effective date," which would be satisfied by providing the effective date of the retention policy. One or more of the requirements may provide one or more options to be selected. One or more of the requirements may be "yes" / "no" questions.

[0042] The smart contract can be configured to verify that each retention detail is valid to meet specific retention requirements. This can include determining that the retention detail meets one or more of the following conditions. The retention detail may have to be in a specific form, for example, it may have to be a specific data type, such as a string or a number. In some examples, the retention detail may have to be a specific value, such as a specific number, a specific word or phrase. In some examples, the retention detail may have to be a specific option (e.g., "yes" or "no") from a set of options. The retention detail may have to have a minimum length and / or a maximum length. The retention detail may have to be within a length range. The retention detail may have to meet other requirements.

[0043] The smart contract can be configured to detect when a retention policy expires (i.e., when a retention period specified by user 202 ends, or when a deletion date expires). In response, the smart contract can send a notification to the storage service provider 203, thereby automatically triggering one or more storage service providers 203 to delete the data when the retention policy has expired. In this way, one or more storage service providers themselves do not have to keep track of retention periods, etc.

[0044] The smart contract may also notify the user that the retention policy has expired or is about to expire. In this case (or in the absence of this notification), the user 202 may update the retention policy. The retention policy may be updated by sending a notification to the smart contract, which then publishes a second retention transaction to the blockchain. In some examples, the user 202 sends a new set of retention details to the smart contract, and the smart contract verifies that the new set of retention details meets the requirements for publishing the retention policy. It should be noted that one or more of the retention details in the set of retention details may remain the same. The second retention transaction may reference a previous (first) retention transaction, for example, the second retention transaction may spend the output of the first retention transaction. Storing each retention policy for a given data item creates an immutable history of where and how the data is stored.

[0045] User 202 may send multiple sets of retention details to retention policy provider 201, each set of retention details for a different data item. The retention details (and retention policies) may be the same or different. The smart contract may generate a retention transaction for each data item. In some examples, a single retention transaction may include retention details for multiple different data items.

[0046] Figure 3An exemplary system 300 / process for recording a retention policy on a blockchain 102 is shown. One or more regulatory agencies 302 provide retention requirements to a smart contract 301. A user 202 submits retention details and (encrypted) data to the smart contract 301. The data is sent to be stored by a storage service provider 203. The smart contract verifies the details and sends a first retention transaction (Tx1) to the blockchain 102. Retention transactions can be searched and retrieved, for example, using a blockchain explorer 303. In some examples, the retention transactions are stored in a database 304, which can be queried by users 202 and / or third parties (e.g., storage service providers 203). Figure 3 An exemplary retention policy 305 is shown in FIG. 20. User 202 may send N sets of retention details for N data items to smart contract 301. The smart contract may issue N retention transactions, one for each data item. Similarly, retention details for multiple data items may be stored in the same retention transaction.

[0047] Figure 3 The system 300 shown allows a third party (e.g., an end user 202 such as an IT technician, data administrator, executive, or regulator 302) to review a retention policy (PoR) listing all necessary data. This can be done by directly querying the blockchain browser 303 or by querying the database 304.

[0048] In this way, the risk of erroneous entries in the retention policy can be avoided. This is because smart contracts are self-verifying and self-executing. In addition, data retention can be automated by calling data from the blockchain browser 303 (for example, through a user API) to the operating / production system. In this way, automating the process will avoid the problem of central personnel involvement, thereby saving time and reducing the possibility of errors during execution. In addition, the user API can also be instructed to send action scripts (i.e., the results of executing smart contracts) directly to storage service providers such as cloud data warehouses. Using blockchain to protect retained data can reduce the risk of data loss because no party is allowed to access, delete, or move the data to another medium if the conditions of the smart contract are not met. This can avoid the user's repeated physical query process for the number of backups to be performed because the process is now automated through the smart contract script in the data at the time of recording. This can be checked through the blockchain browser 303.

[0049] Database 304 stores retention policies issued by smart contract 301. These can be policies related to a specific user 202 (e.g., a specific organization). Retention policies can be stored as retention transactions. In other words, the database can store retention transactions from which retention policies can be extracted. Alternatively, the database can only store retention policies. Database 304 allows user 202 to quickly and efficiently find the retention policy of a data item, for example, to provide to a regulator 302 or other third party. In the case where the retention policy is updated one or more times, the database can store a history of the retention policy, or only the most recent policy. Database 304 allows users to find the latest version of the retention policy. Database 304 can store the retention policy together with the transaction identifier of the retention transaction (i.e., map the retention policy to the transaction identifier of the retention transaction). This makes it easy to find the retention transaction.

[0050] Further comments

[0051] The retention policy provider 201 and the user 202 operate corresponding computer devices. The computer device of each of these entities includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, dedicated processors and / or FPGAs. The computer device of each entity also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical drives. The memory on the computer device of each entity can store software, which includes at least one client application that is configured to run on the processing device. It should be understood that any action attributed to a given entity 201, 202 in this article can be performed by software running on the processing device of the corresponding computer device. The computer device of each entity includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device of each entity may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0052] The examples described herein should be understood as illustrative examples of embodiments of the present invention. Further embodiments and examples are contemplated. Any feature described with respect to any one example or embodiment may be used alone or in combination with other features. In addition, any feature described with respect to any one example or embodiment may also be used with one or more features of any other example or embodiment or any combination of any other example or embodiment. In addition, within the scope of the present invention as defined by the claims, equivalents and modifications not described herein may also be adopted.

[0053] More generally, according to one aspect disclosed herein, there is provided a computer-implemented method of providing a data retention policy attestation using a blockchain, wherein a smart contract defines one or more corresponding data retention requirements for storing a data item at a storage location, and wherein the method comprises:

[0054] receiving from a party a) a first data item and / or an encrypted version of the first data item, wherein the first data item is to be stored at the storage location, and b) one or more corresponding data retention details of a first retention policy associated with the first data item;

[0055] providing to a smart contract a) the encrypted version of the first data item and / or the first target data item, and b) the one or more corresponding data retention details of the first retention policy; and,

[0056] Executing the smart contract, wherein the smart contract is configured to, when executed:

[0057] determining whether the one or more corresponding data retention details of the first retention policy satisfy the one or more corresponding data retention requirements; and,

[0058] If it is determined that the one or more corresponding data retention details of the first retention policy satisfy the one or more corresponding data retention requirements, submitting a first blockchain transaction to the blockchain, wherein the first blockchain transaction includes the one or more data retention details of the first retention policy and at least one of the following: i) the first data item; ii) the encrypted version of the first data item; iii) a reference to the first data item being stored at the storage location.

[0059] In an embodiment, said receiving may include receiving said first blockchain transaction, wherein said first blockchain transaction includes a) said first target data item and / or said encrypted version of said first target data item, and b) said one or more corresponding data retention details of said first retention policy, and wherein said providing includes providing said first blockchain transaction to said smart contract.

[0060] In an embodiment, the smart contract may be configured to generate the first blockchain transaction.

[0061] In an embodiment, said receiving may include receiving said first data item, and wherein said smart contract may be configured to generate said encrypted version of said first data item.

[0062] In an embodiment, the encrypted version of the first data item may comprise a hash of the target data item.

[0063] In an embodiment, said encrypted version of said first target data item may be generated using public key cryptography.

[0064] In an embodiment, the method may include sending the first blockchain transaction to the party and / or a storage service provider of the storage location.

[0065] In an embodiment, the smart contract may be configured to generate an identifier of the first blockchain transaction, and wherein the method may include sending the identifier of the first blockchain transaction to the party and / or the storage service provider of the storage location.

[0066] In an embodiment, the one or more corresponding data retention details of the first retention policy may include one or more of the following:

[0067] a file type of the first data item;

[0068] a title of the first data item;

[0069] a version of the first data item;

[0070] The department and / or institution responsible for creating and / or storing the first data item;

[0071] a department and / or agency responsible for approving the one or more corresponding data retention details of the first retention policy;

[0072] the date on which the corresponding data retention detail or details were approved;

[0073] a retention period during which the first data item is to be stored at the storage location;

[0074] A deletion date on which the first data item is to be deleted from the storage location.

[0075] In an embodiment, the one or more corresponding data retention details of the first retention policy may include the retention period and / or the deletion date, and wherein the smart contract may be configured to:

[0076] detecting when the retention period ends and / or when the deletion date expires; and,

[0077] Causes a notification to be sent to the storage service provider to delete the first data item from the storage location.

[0078] In an embodiment, the one or more corresponding data retention details may include the retention period and / or the deletion date, and wherein the method may include:

[0079] receiving one or more corresponding data retention details of an updated first retention policy from the party, and wherein the smart contract is configured to submit a second blockchain transaction to the blockchain, wherein the second blockchain transaction includes the one or more data retention details of the updated first retention policy and at least one of the following: i) the first data item; ii) the encrypted version of the first data item; iii) the reference to the first data being stored at the storage location.

[0080] In an embodiment, the second blockchain transaction may reference the first blockchain transaction.

[0081] In an embodiment, the method may include:

[0082] receiving from the party a) a second data item and / or an encrypted version of the second data item, wherein the second data item is to be stored at the storage location, and b) one or more corresponding data retention details of a second retention policy;

[0083] providing to the smart contract a) the second data item and / or the encrypted version of the second data item, and b) the one or more corresponding data retention details of the second retention policy; and,

[0084] Executing the smart contract, wherein the smart contract is configured to, when executed:

[0085] determining whether the one or more corresponding data retention details of the second retention policy satisfy the one or more corresponding data retention requirements; and,

[0086] If it is determined that the one or more corresponding data retention details of the second retention policy satisfy the one or more corresponding data retention requirements, submitting a third blockchain transaction to the blockchain, wherein the third blockchain transaction includes the one or more data retention details of the second retention policy and at least one of the following: i) the second data item; ii) the encrypted version of the second data item; iii) a reference to the second data being stored at the storage location.

[0087] In an embodiment, the first blockchain transaction and the third blockchain transaction may be the same blockchain transaction.

[0088] In an embodiment, the first retention policy and the second retention policy may be different retention policies.

[0089] In an embodiment, the method may be performed by a blockchain node.

[0090] According to another aspect disclosed herein, a computer device is provided, the computer device comprising:

[0091] a memory, the memory comprising one or more memory cells; and,

[0092] A processing device, the processing device comprising one or more processing units, wherein the memory stores codes configured to be executed on the processing device, and the codes are configured to execute the method described in any of the embodiments described herein when executed on the processing device.

[0093] According to another aspect disclosed herein, a computer program is provided. The computer program is contained on a computer-readable memory and is configured to execute the method described in any one of the embodiments described herein when executed on one or more processors.

Claims

1. A computer-implemented method for providing proof of data retention policy using a blockchain, wherein: The smart contract defines one or more corresponding data retention requirements for storing a data item at a storage location, and wherein the method comprises: receiving, from a party, a) a first data item and / or an encrypted version of the first data item, wherein the first data item is to be stored at the storage location, and b) one or more corresponding data retention details of a first retention policy associated with the first data item; providing, to a smart contract, a) the encrypted version of the first data item and / or the first target data item, and b) the one or more corresponding data retention details of the first retention policy; and Executing the smart contract, wherein the smart contract is configured to, when executed: determining whether the one or more corresponding data retention details of the first retention policy satisfy the one or more corresponding data retention requirements; and If it is determined that the one or more corresponding data retention details of the first retention policy satisfy the one or more corresponding data retention requirements, submitting a first blockchain transaction to a blockchain, wherein the first blockchain transaction includes the one or more data retention details of the first retention policy and at least one of the following: i) the first data item, ii) the encrypted version of the first data item, and iii) a reference to the first data item being stored at the storage location.

2. The method according to claim 1, wherein: The receiving comprises receiving the first blockchain transaction, wherein the first blockchain transaction comprises a) the first target data item and / or the encrypted version of the first target data item, and b) the one or more corresponding data retention details of the first retention policy, and wherein the providing comprises providing the first blockchain transaction to the smart contract.

3. The method according to claim 1, wherein: The smart contract is configured to generate the first blockchain transaction.

4. A method according to any preceding claim, wherein: The receiving includes receiving the first data item, and wherein the smart contract is configured to generate the encrypted version of the first data item.

5. A method according to any preceding claim, wherein: The encrypted version of the first target data item is generated using public key encryption.

6. A method according to any preceding claim, comprising sending the first blockchain transaction to the party and / or a storage service provider of the storage location.

7. A method according to any preceding claim, wherein: The smart contract is configured to generate an identifier of the first blockchain transaction, and wherein the method comprises sending the identifier of the first blockchain transaction to the party and / or the storage service provider of the storage location.

8. A method according to any preceding claim, wherein: The one or more corresponding data retention details of the first retention policy include one or more of the following: a file type of the first data item; a title of the first data item; a version of the first data item; The department and / or institution responsible for creating and / or storing the first data item; a department and / or agency responsible for approving the one or more corresponding data retention details of the first retention policy; the date on which the corresponding data retention detail or details were approved; a retention period during which the first data item is to be stored at the storage location; A deletion date on which the first data item is to be deleted from the storage location.

9. The method according to claim 8, wherein: The one or more corresponding data retention details of the first retention policy include the retention period and / or the deletion date, and wherein the smart contract is configured to: detecting when the retention period ends and / or when the deletion date expires; and Causes a notification to be sent to the storage service provider to delete the first data item from the storage location.

10. The method according to claim 8 or 9, wherein: The one or more corresponding data retention details include the retention period and / or the deletion date, and wherein the method comprises: receiving, from the party, one or more corresponding data retention details of an updated first retention policy, and wherein the smart contract is configured to submit a second blockchain transaction to the blockchain, wherein the second blockchain transaction includes the one or more data retention details of the updated first retention policy and at least one of: i) the first data item, ii) the encrypted version of the first data item, iii) the reference to the first data being stored at the storage location.

11. A method according to any preceding claim, comprising: receiving, from the party, a) a second data item and / or an encrypted version of the second data item, wherein the second data item is to be stored at the storage location, and b) one or more corresponding data retention details of a second retention policy; providing, to the smart contract, a) the second data item and / or the encrypted version of the second data item, and b) the one or more corresponding data retention details of the second retention policy; as well as Executing the smart contract, wherein the smart contract is configured to, when executed: determining whether the one or more corresponding data retention details of the second retention policy satisfy the one or more corresponding data retention requirements; and If it is determined that the one or more corresponding data retention details of the second retention policy satisfy the one or more corresponding data retention requirements, submitting a third blockchain transaction to the blockchain, wherein the third blockchain transaction includes the one or more data retention details of the second retention policy and at least one of the following: i) the second data item, ii) the encrypted version of the second data item, and iii) a reference to the second data being stored at the storage location.

12. The method according to claim 11, wherein: The first blockchain transaction and the third blockchain transaction are the same blockchain transaction.

13. The method according to claim 11 or 12, wherein: The first retention policy and the second retention policy are different retention policies.

14. A method according to any preceding claim, wherein: The method is executed by a blockchain node.

15. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores a code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 14 when executed on the processing device.

16. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 14.

Images