Proof of Data Retention Using Blockchain

Abstract

A computer-implemented method using blockchain to provide proof of a data retention policy, wherein a smart contract defines one or more respective data retention requirements for storing a data item at a memory location, the method comprising the steps of receiving the data item and / or an encrypted version thereof and one or more data retention details of a retention policy, supplying the data item and / or an encrypted version thereof and the data retention details to a smart contract, and executing the smart contract, wherein the smart contract, when executed, is configured to determine whether the data retention details satisfy the data retention requirements and, if so, submit a transaction to the blockchain, the transaction including the data retention details and at least one of the data item, its encrypted version, and a reference to where the data item is stored at the memory location.

Description

[Technical field]

[0001] The present disclosure relates to a method for using blockchain to provide proof of data retention policy. [Background technology]

[0002] A data retention policy, or record retention policy, defines how data should be stored for operational or regulatory compliance purposes. Data retention policies are typically part of an organization's overall data management strategy, e.g., a company, a government agency, etc. Such policies are becoming more important due to the increasing amount of data that organizations need to store and process. Thus, to prevent data from being stored indefinitely, a data retention policy is needed that defines how long an organization must retain certain data. With the application of such a centralized digital strategy and retention protocols, an organization also controls how data is stored or how data is discarded when it is no longer needed for compliance or regulatory reasons. A data retention policy typically includes a description of the different types of data and records that are stored, a description of the format of the data, the retention period, and a description of the system in which the data is stored. The elements included in the policy are usually based on the rules of the regulatory body that governs the industry. A retention policy may specify that historical data should be preserved even after the end of the usage period, for example, by archiving in a tertiary data warehouse. An organization must demonstrate that it performs selective retention and deletion of data in accordance with the specific regulatory requirements of its industry.

[0003] When the information stored contains personal data, additional requirements are often set by the coming into force of the General Data Protection Regulation (GDPR), which requires organizations to prove how personal data is properly managed and stored throughout its lifecycle, and especially at the end of it. From the end user's perspective, non-compliance with these regulations can expose organizations to significant fines. Summary of the Invention

[0004] Existing techniques for storing data retention policies suffer from several problems and can be challenging for data retrieval purposes, which is especially complicated in the event of data corruption.

[0005] One issue is access to data. Having access to both current and old information is already a challenge. The rapid growth in data volumes makes finding individual data records a difficult task. Another issue is cost. Although data storage costs are generally falling, there are other factors in the overall cost of storing data. For example, labor costs to find and retrieve data should also be considered. Also, infrastructure costs, migration costs, and specialist archiving are added. Another issue is that of risk. Data has to be stored somewhere, and so it depends on the storage provider's ability to store it securely. Data leaks due to inadequate data policies are a burden for most organizations, as they result in direct revenue loss, reputational damage, and often large fines.

[0006] Current systems for managing data retention policies at the data file level are roughly similar to decentralized systems in the sense that the retention process is often outside the purview of the IT department, is not controlled by management, and the coordination established between the various parties in the system can be very poor. For more structured retention policies, data is currently only stored by relevant parties in the organization or regulatory body. This represents a centralized rather than a decentralized approach.

[0007] Therefore, there is a need for a fully centralized approach to managing 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 that uses a blockchain to provide proof of a data retention policy. The smart contract defines one or more respective data retention requirements for storing a data item in a storage location. The method includes receiving from a party: a) an encrypted version of the first data item and / or the first data item to be stored in the storage location, and b) one or more respective data retention details of a first retention policy associated with the first data item. The method further includes supplying 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 respective data retention details of the first retention policy. The smart contract is executed. When executed, the smart contract is configured to determine whether the one or more respective data retention details of the first retention policy satisfy the one or more respective data retention requirements. If it is determined that the one or more respective data retention details of the first retention policy satisfy the one or more respective data retention requirements, the smart contract is configured to submit a first blockchain transaction to the blockchain. The first blockchain transaction includes one or more data retention details of a first retention policy and at least one of: i) the first data item, ii) an encrypted version of the first data item, and iii) a reference to where the first data item is stored in a memory location.

[0009] A retention policy provider (e.g., a blockchain node) runs a smart contract, i.e., a self-executable code. The smart contract defines a set of data retention requirements. The data retention requirements specify information that must be provided for a retention policy to be issued for storage of a data item (data item is used generally 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, an effective date after which the data can be deleted, a retention period, etc. The data item is sent to one or more storage providers. A party (e.g., a group such as a user or an organization) sends the data item and / or an encrypted version of the data item to the provider. One or more data retention details are also sent, one 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 the encrypted data item) are supplied to the smart contract. The smart contract verifies that the supplied data retention details meet the requirements, and if so, the smart contract sends the transaction to the blockchain. The transaction includes a data retention policy. The transaction may also include a data item or an encrypted data item. Additionally or alternatively, the transaction may include a reference to a storage location of the data item.

[0010] Using a blockchain to record data retention policies has several advantages. First, policies can be accessed at any time, since a decentralized network does not experience any downtime. Access to policies is location independent, providing global access. There is no single individual or entity responsible for recording the policies, making it difficult (or even impossible) for policies to be manipulated by third parties. An immutable link is created between the data and the associated retention policy, which means that the retention policy of a given data record cannot be contested. [Brief description of the drawings]

[0011] To facilitate an understanding of the present disclosure and to show how embodiments may be carried into effect, reference is made by way of example to the accompanying drawings, in which: [Figure 1A] 1 illustrates generally an exemplary method for mining new blocks into a blockchain. [Figure 1B] 1 illustrates a schematic diagram of a pair of blockchain transactions. [Diagram 2] 1 illustrates a schematic diagram of an exemplary system for recording data retention policies on a blockchain. [Diagram 3] 1 illustrates generally an exemplary process for recording data retention policies in a blockchain. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] An exemplary blockchain system 1A illustrates generally an exemplary method for mining new blocks 101n into a blockchain 102. The blockchain 102 is a form of distributed database (or ledger) that serves as a record of all valid transactions 103 ever submitted to the blockchain network.

[0013] Valid transactions 103 broadcast on the blockchain network are recorded on the blockchain 102 in blocks by miners (also called mining nodes). Blockchain transactions 103 are used to transfer control of an amount of digital tokens. A pair of transactions 103 is shown in FIG. 1B. 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) from a previous transaction. For example, in FIG. 1B, Tx1 includes an input that references the UTXO of Tx0. A transaction 103 uses unspent transaction outputs (UTXOs) as inputs and distributes their values ​​to new outputs. An output typically includes a locking condition that locks the value of that output, and in order to be unlocked, certain data (e.g., a set of keys or other information) must be provided to the input of the new transaction 103. An output may also be used to write data onto the ledger. A transaction 103 input typically includes a digital signature that signs the transaction 103. The chain of transactions 103 thus includes a chain of digital signatures that maps the entire history of valid exchanges of digital tokens back to their creation.

[0014] Returning now to FIG. 1A, the blockchain 102 begins with a genesis block "101g," which is the first block 101 ever created. Each block on the 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 back to the genesis block 101g.

[0015] A block 101 includes an ordered list of blockchain transactions 103 and a block header 104. The block header 104 includes a Merkle root 105, which is generated by hashing the ordered list of blockchain transactions 103 into a Merkle tree, a timestamp, a reference 106 to the previous block 101 on which the current block 101 is constructed, and a means of validating the "proof-of-work" required for other miners to accept the block 101 as valid. The validation means is the answer to a hash puzzle that is unique to each block 101. The blockchain protocol, executed by nodes in the blockchain network, uses a hashing algorithm that requires miners to pre-construct their candidate blocks 101c before attempting to solve the puzzle. A new block 101n cannot be submitted to the network without the correct answer, and the process of "mining" is essentially a process of competing to next find an answer that "solves" the current block 101. The hash puzzle within each block 101 is difficult to solve, but once a valid solution is found, it is very easy to verify that the solution is correct for the rest of the network. There are multiple valid solutions for any given block 101, and one only needs to find one of those solutions to solve the block 101.

[0016] Below, we briefly describe the process of attempting to mine a new block 101n into the blockchain 102. When a blockchain transaction 103 is sent to a mining node, it is first validated 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 "mem pool." The mem pool 107 serves as a temporary store of transactions 103 that will be mined into the next block 101n. Each mining node has its own mem pool 107, and any given transaction 103 may be included in more than one mem pool 107 if it has been broadcast to more than one mining node.

[0017] A hash function is a function that converts a string of data of any length into a fixed-length value called a hash value or hash digest. Hashing is a one-way function, which means that it is impossible to determine what the input data is by looking at the hash value generated from it. On the other hand, it is trivial to run the same input data through the same hash function and reproduce the same hash. Some blockchain protocols use the SHA-256 hashing algorithm, and some protocols use the SHA-256 hashing algorithm twice, i.e., the candidate block header is passed through the same hashing algorithm twice.

[0018] A Merkle tree is a data structure in the form of a tree of hash values. In the context of a blockchain 102, transactions 103 are hashed to form leaf nodes of the tree. As shown in FIG. 1A, transaction Tx1 is hashed to form leaf node D1, transaction Tx2 is hashed to form leaf node D2, and so on. Pairs of leaf nodes are concatenated and then hashed to form nodes in higher layers of the tree. For example, leaf nodes D1 and D2 are concatenated and hashed to generate nodes in the higher layers. Pairs of nodes in that layer are then concatenated and hashed to form nodes in the higher layers of the tree. The process is repeated until only a single node remains, called the root node or Merkle root 105.

[0019] A miner takes the transactions 103 that they intend to include in the next block 101, hashes them into a Merkle tree structure, and includes the resulting Merkle root 105 in a candidate block header 104. The miner then hashes this candidate block header 104 and attempts to find a valid proof of work.

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

[0021] To change the hash value, a mining node must add additional information to the candidate block header 104. Mining nodes typically use two "nonce fields" to change the value being hashed, and therefore the resulting hash value. A first nonce field 108 is included in the block header itself, and a second nonce field is included 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 cycles through all values ​​of the first nonce field 108, then increments (or otherwise changes) the second nonce field before going through all permutations of the first nonce field 108 again. Incrementing the second nonce field involves recalculating the Merkle root when the Merkle root 105 modifies the hash of the coinbase transaction included in the Merkle tree.

[0022] When a mining node finds a valid proof-of-work hash of a block 101 (i.e., a candidate block header 104 that hashes to a value less than the target value), it broadcasts the new block 101n to the rest of the blockchain network. Other nodes on the network will only accept this new block 101n if all transactions 103 in it are valid and not already included in a block. Because every block 101 is timestamped and references the hash of the block 101 that precedes it, a chain of blocks (i.e., blockchain 102) results.

[0023] The above has been described in relation to an "output-based" transaction model. Another type of transaction model is the "account-based" model. In this model, each transaction 103 defines the amount of digital tokens to be transferred by referencing absolute account balances, rather than by referencing back to unspent transaction outputs. The current state of every account is stored separately from the blockchain 102 and constantly updated by miners. In such a system, transactions 103 are ordered using the running transaction tally (also called "position") of the account. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation.

[0024] FIG. 2 illustrates a schematic diagram of an exemplary system 200 for distributing hash values ​​from a set of hash devices 201a, 201b to a hash pool 202. In this exemplary system 200, there are two hash devices 201a, 201b, but the system 200 may generally include any number of hash 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. In general, the client applications 203 are configured to submit blockchain transactions to the hash pool 202. The hash pool is configured to construct a block template 101c and transmit the block template 101c (or at least the candidate block header 104 of the block template 101c) to the hash devices 201a, 201b. Each hash device 201 is configured to generate a candidate PoW solution based on the candidate block header 104. The system further includes a blockchain network 204 including a plurality of blockchain nodes.

[0025] Proof of Data Retention FIG. 2 illustrates an exemplary system 200 for recording a retention policy in the blockchain 102. As illustrated, the system 200 includes a smart contract provider (also referred to as a retention policy provider) 201. The retention policy provider may be a blockchain node. That is, a smart contract may be operated by a blockchain node. In general, the retention policy provider may be any party (e.g., a regulator, a company, an organization, a standard-setting body, etc.) responsible for the operation of a smart contract as described herein. The system 200 also includes a party 202 configured to transmit data to be stored in a storage provider 203. The party may take any suitable form, for example, a user, a group of users, a company, an organization, a university, a charity, a medical group, etc. The storage provider 203 is configured to store the data in a storage location. The storage may take any suitable form, for example, local storage, cloud storage, etc.

[0026] The system 200 also includes one or more nodes of a blockchain network. For example, the nodes may be configured to implement a blockchain system such as that described with reference to Figures 1A and 1B.

[0027] As shown in FIG. 2, a user 202 is prompted to submit data to be stored by a storage provider 203. The data may take any suitable form, such as, for example, electronic documents such as company or personal records, media (e.g., audio or video) files, non-fungible tokens, etc. The user 202 wishes to record a retention policy for the data on the blockchain 150. The retention policy provider 201 operates a smart contract configured to issue 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 for a data retention policy to be issued. The data retention requirements may be defined by the retention policy provider 201 or by a third party (not shown). For example, the requirements may be provided by a separate regulatory body, a standards committee, a government agency, etc. In some examples, the user 202 is an employee or department of a company and the requirements are set by the company.

[0028] A smart contract may take the form of an executable program, which may be written in a high-level computer programming language, where the smart contract imposes conditions on a payload that contains data retention details, and if the conditions are met, a retention transaction is sent to the blockchain.

[0029] A user 202 submits a set of retention requirements to a retention policy provider 201. The set of retention details corresponds to a retention requirement. That is, the user 202 sends retention details for each retention requirement such that the requirement specified by the smart contract is satisfied. The smart contract verifies that the requirements are satisfied. If not, the retention policy is not issued. The smart contract (or more generally the retention policy provider 201) may inform the user 202 that the validation failed. If the requirements are satisfied, the smart contract submits (102) the blockchain transaction to the blockchain. If the smart contract is operated by a blockchain node, the blockchain node may record the transaction directly on the blockchain 102.

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

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

[0032] As described above, the user 202 may send data to the 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, the user 202 may encrypt the data (e.g., via hashing or using public key encryption) before sending it to the retention policy provider 201.

[0033] In addition to sending the retained transaction to the blockchain 102, the smart contract may be configured to send the retained transaction to the user 202 and / or storage provider(s) 203 that store the data. Additionally or alternatively, the smart contract may generate an identifier for the retained transaction and send the identifier to the user 202 and / or storage provider(s) 203. The identifier may be a hash or double hash of the retained transaction.

[0034] As mentioned above, the smart contract verifies that a set of data retention details is provided that meets a set of requirements for issuing a retention policy. The requirements, and thus the details, may include one or more of the following: file type and / or format, title, version number, department and / or authority responsible for creating and / or storing the data, department and / or authority responsible for approving the data retention details, date on which one or more data retention details were approved, retention period for which the data should be stored by the storage provider 203, deletion date for which the data should be deleted from the storage location.

[0035] One or more of the data retention requirements may take the form of a data field to be populated. For example, a requirement may be a "storage location" or a "storage provider," which is satisfied by providing a storage location or storage provider for the data item, respectively. As another example, a requirement may be an "effective date," which is satisfied by providing a date on which the retention policy is effective. One or more of the requirements may provide one or more options to be selected. One or more of the requirements may be a yes / no question.

[0036] The smart contract may be configured to verify that each retention detail effectively meets certain retention requirements. This may include determining that the retention detail meets one or more of the following conditions: The retention detail may be required to take a particular form, e.g., be a particular data type, such as a string or number. In some examples, the retention detail may be required to be a particular value, e.g., a particular number, or a particular word, or phrase. In some examples, the retention detail may be required to be a particular one of a set of options (e.g., "yes" or "no"). The retention detail may be required to have a minimum and / or maximum length. The retention detail may be required to fall within a certain length range. The retention detail may be required to meet other requirements.

[0037] The smart contract may be configured to detect when a retention policy has expired (i.e., when a retention period specified by the user 202 has ended or when a deletion date has arrived). In response, the smart contract may send a notification to the storage provider(s) 203, automatically triggering the storage provider(s) 203 to delete the data whose retention policy has expired. In this way, the storage provider(s) themselves do not need to keep track of retention periods, etc.

[0038] 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 in turn issues a second retention transaction to the blockchain. In some examples, the user 202 sends a new set of retention details to the smart contract, which verifies that the new set of retention details meets the requirements for issuing the retention policy. Note that one or more of the sets of retention details may remain the same. The second retention transaction may reference a previous (first) retention transaction, e.g., the second retention transaction may use the output of the first retention transaction. By storing each retention policy for a given data item, an immutable history of where and how the data is stored is created.

[0039] A user 202 may send multiple sets of retention details to the retention policy provider 201, one for each different data item. The retention details (and therefore the retention policies) may be the same or different. A 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.

[0040] FIG. 3 illustrates an exemplary system 300 / process for recording a retention policy on the blockchain 102. One or more regulatory agencies 302 provide retention requirements to the smart contract 301. The user 202 submits retention details and (encrypted) data to the smart contract 301. The data is sent to be stored by the storage provider 203. The smart contract verifies the details and sends a first retention transaction (Tx1) to the blockchain 102. The retention transaction can be searched and retrieved, for example, using the blockchain explorer 303. In some examples, the retention transaction is stored in a database 304 that can be queried by a third party, such as the user 202 and / or the storage provider 203. An exemplary retention policy 305 is illustrated in FIG. 3. The user 202 may send the smart contract 301 N sets of retention details for N data items. The smart contract may issue N retention transactions, one per data item. Similarly, retention details for two or more data items may be stored in the same retention transaction.

[0041] 3 allows a third party (e.g., an end user 202 such as an IT technician, data manager, executive, or a regulator 302) to review the listed retention policies (PoRs) along with all required data by querying the blockchain explorer 303 directly or via a database 304.

[0042] In this way, the risk of inaccurate inputs to the retention policy is avoided. This is because smart contracts are self-verifying and self-enforcing. Furthermore, data retention can be automated by calling the data from the blockchain explorer 303 (e.g., via the user API) to the operating / production system. In this way, the automation of the process avoids the problem of the participation of a central person who may consume time and make errors in the execution process. The user API can also be instructed to send the action script (i.e., the result of executing the smart contract) directly to the storage provider, e.g., a cloud data warehouse. Using the blockchain to protect the retained data reduces the risk of data loss, since it does not allow access to the data, deletion of the data, or movement of the data to another medium unless the conditions of the smart contract are met. The repetition of the process of the user physically querying the number of times the backup has been performed is avoided, since it is handled by automation from the smart contract script on the data at the time it was recorded. This can be checked through the blockchain explorer 303.

[0043] The database 304 stores retention policies issued by the smart contract 301. These may be policies related to a particular user 202 (e.g., a particular organization). Retention policies may be stored as retention transactions. In other words, the database may store retention transactions from which retention policies may be extracted. Alternatively, the database may store only retention policies. The database 304 allows the user 202 to quickly and efficiently find the retention policy of a data item, for example, to provide to a regulatory agency 302 or other third party. If the retention policy is updated one or more times, the database may store a history of the retention policy, or only the most recent policy. The database 304 allows the user to find the most recent version of the retention policy. The database 304 may store the retention policy along with (i.e., mapped to) the transaction identifier of the retention transaction. This allows the retention transaction to be easily found.

[0044] Further notes The retention policy provider 201 and the user 202 operate respective computing devices. The computing devices of each of these entities comprise respective processing devices that comprise one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing devices of each entity further comprise memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing devices of each entity may store software including at least one client application configured to execute on the processing devices. It will be understood that any action attributed to a given entity 201, 202 herein may be performed using software executed on the processing devices of the respective computing devices. The computing devices of each entity comprise at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. Each entity's computing equipment may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

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

[0046] More generally, according to one aspect disclosed herein, there is provided a computer-implemented method for using a blockchain to provide proof of a data retention policy, wherein a smart contract defines one or more respective data retention requirements for storing a data item at a storage location, the method comprising: receiving from a party a) a first data item and / or an encrypted version of the first data item to be stored in a storage location and b) one or more respective data retention details of a first retention policy associated with the first data item; providing a smart contract with a) an encrypted version of the first data item and / or the first target data item, and b) one or more respective data retention details of a first retention policy; executing a smart contract, the smart contract, when executed, determining whether one or more respective data retention details of the first retention policy satisfy one or more respective data retention requirements; if it is determined that the one or more respective data retention details of the first retention policy satisfy the one or more respective data retention requirements, submitting a first blockchain transaction to the blockchain, the first blockchain transaction including the one or more data retention details of the first retention policy and at least one of: i) the first data item; ii) an encrypted version of the first data item; and iii) a reference to where the first data item is stored in a storage location. configured to perform the steps of: A method is provided that includes:

[0047] In an embodiment, the receiving step may include receiving a first blockchain transaction, the first blockchain transaction including a) the first target data item and / or an encrypted version of the first target data item and b) one or more respective data retention details of the first retention policy, and the providing step includes providing the first blockchain transaction to the smart contract.

[0048] In embodiments, the smart contract may be configured to generate a first blockchain transaction.

[0049] In an embodiment, the receiving step may include receiving a first data item, and the smart contract may be configured to generate an encrypted version of the first data item.

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

[0051] In an embodiment, the encrypted version of the first target data item may be generated using public key encryption.

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

[0053] In embodiments, the smart contract may be configured to generate an identifier for the first blockchain transaction, and the method may include transmitting the identifier for the first blockchain transaction to a party and / or a storage provider of the memory location.

[0054] In an embodiment, the one or more respective data retention details of the first retention policy include: The file type of the first data item, The title of the first data item, The version of the first data item, the department and / or authority responsible for the creation and / or storage of the first data item, the department and / or authority responsible for approving the data retention details of each of the first retention policy or policies; the date on which each data retention detail or details were approved; a retention period for which the first data item should be stored in the storage location; The deletion date on which the first data item should be deleted from the storage location. may include one or more of:

[0055] In embodiments, the one or more respective data retention details of the first retention policy may include a retention period and / or a deletion date, and the smart contract: Detect when the retention period has expired and / or the deletion date has arrived; causing a storage provider to send a notification to delete the first data item from the storage location; The signal processing unit may be configured to perform the following steps.

[0056] In an embodiment, the one or more respective data retention details may include a retention period and / or a deletion date, and the method further comprises: receiving from the party one or more respective data retention details of the updated first retention policy, wherein the smart contract is configured to submit a second blockchain transaction to the blockchain, the second blockchain transaction including the one or more data retention details of the updated first retention policy and at least one of: i) the first data item; ii) an encrypted version of the first data item; iii) a reference to where the first data is stored in a memory location; may include.

[0057] In some embodiments, a second blockchain transaction may reference a first blockchain transaction.

[0058] In an embodiment, the method comprises: receiving from the party a) a second data item and / or an encrypted version of the second data item to be stored in the storage location and b) one or more respective data retention details of a second retention policy; providing a) a second data item and / or an encrypted version of the second data item, and b) respective data retention details of one or more of the second retention policies to the smart contract; executing a smart contract, the smart contract, when executed, determining whether the one or more respective data retention details of the second retention policy satisfy the one or more respective data retention requirements; if it is determined that the one or more respective data retention details of the second retention policy satisfy the one or more respective data retention requirements, submitting a third blockchain transaction to the blockchain, the third blockchain transaction including the one or more data retention details of the second retention policy and at least one of: i) the second data item; ii) an encrypted version of the second data item; and iii) a reference to where the second data is stored in a storage location. configured to perform the steps of: may include.

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

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

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

[0062] According to another aspect disclosed herein, there is provided a computing device comprising: a memory comprising one or more memory units; and a processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code, when on the processing device, being configured to perform a method of any of the embodiments described herein.

[0063] According to another aspect disclosed herein, there is provided a computer program embodied on a computer readable storage and configured to, when executed on one or more processors, perform the method of any of the embodiments described herein.

Claims

1. 1. A computer-implemented method of using a blockchain to provide proof of a data retention policy, wherein a smart contract defines one or more respective data retention requirements for storing a data item at a storage location, the method comprising: receiving from a party: a) a first data item stored in said storage location and / or an encrypted version of said first data item; and b) one or more respective data retention details of a first retention policy associated with said first data item; providing a 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 respective data retention details of the first retention policy; executing the smart contract, the smart contract, when executed, determining whether the one or more respective data retention details of the first retention policy satisfy the one or more respective data retention requirements; if it is determined that the one or more respective data retention details of the first retention policy satisfy the one or more respective data retention requirements, submitting a first blockchain transaction to the blockchain, the first blockchain transaction including 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, and iii) a reference to where the first data item is stored in the storage location; configured to perform the steps of: The method includes:

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

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

4. 2. The method of claim 1 , wherein the receiving step includes receiving the first data item, and the smart contract is configured to generate the encrypted version of the first data item.

5. The method of claim 1 , wherein the encrypted version of the first target data item is generated using public key encryption.

6. 2. The method of claim 1, comprising transmitting the first blockchain transaction to the party and / or a storage provider of the memory location.

7. 2. The method of claim 1 , wherein the smart contract is configured to generate an identifier for the first blockchain transaction, the method comprising: transmitting the identifier for the first blockchain transaction to the parties and / or a storage provider of the memory location.

8. the one or more respective data retention details of the first retention policy; the file type of the first data item; A title for the first data item; A version of the first data item, departments and / or authorities responsible for the creation and / or storage of said first data items, departments and / or authorities responsible for approving the data retention details of each of the one or more first retention policies; the date on which each of said one or more data retention details was approved; a retention period for which the first data item should be stored in the storage location; a deletion date on which the first data item should be deleted from the storage location; The method of claim 1 , comprising one or more of:

9. The one or more respective data retention details of the first retention policy include the retention period and / or the deletion date, and the smart contract: detecting when said retention period has expired and / or when said deletion date has occurred; causing a storage provider to send a notification to delete the first data item from the storage location; The method of claim 8 , configured to:

10. wherein the one or more respective data retention details include the retention period and / or the deletion date, and the method further comprises: receiving from the party one or more respective data retention details of an updated first retention policy, wherein the smart contract is configured to submit a second blockchain transaction to the blockchain, the second blockchain transaction including 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; and iii) the reference to where the first data item is stored in the storage location. The method of claim 8 , comprising:

11. receiving from said party: a) a second data item to be stored in said storage location and / or an encrypted version of said second data item; and b) one or more respective data retention details of a second retention policy; providing said smart contract with a) the second data item and / or the encrypted version of the second data item, and b) data retention details of each of the one or more of the second retention policies; executing the smart contract, the smart contract, when executed, determining whether the one or more respective data retention details of the second retention policy satisfy the one or more respective data retention requirements; if it is determined that the one or more respective data retention details of the second retention policy satisfy the one or more respective data retention requirements, submitting a third blockchain transaction to the blockchain, the third blockchain transaction including the one or more data retention details of the second retention policy and at least one of: i) the second data item, ii) the encrypted version of the second data item, and iii) a reference to where the second data item is stored in the storage location; configured to perform the steps of: The method of claim 1 , comprising:

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

13. The method of claim 11 , wherein the first retention policy and the second retention policy are different retention policies.

14. The method of claim 1 , wherein the method is performed by a blockchain node.

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

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

Images