File management with blockchain

Abstract

A computer-implemented method for recording an electronic file, wherein the method is implemented by a file proof platform, comprising: accessing a folder; executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder; obtaining the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; generating a commitment value based on the electronic file; generating a proof blockchain transaction comprising the commitment value; and causing the proof blockchain transaction to be made available to one or more nodes of a blockchain.

Description

[0001] FILE MANAGEMENT WITH BLOCKCHAIN

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a file proof platform and methods for making commitments to files and / or authorship of files, and for the verification of files and / or authorship of files. The present disclosure also relates to a method of securely linking file contents and authorship.

[0004] BACKGROUND

[0005] When an electronic file is created or modified, metadata associated with the file is also generated and stored. This metadata may provide information such as the authorship of the file, the time of file creation or modification, the file type and size, etc.

[0006] Electronic files may be stored locally on a user device, or remotely on a server which is accessible to all devices in a network. More recently, cloud-based file management systems have become increasingly popular. Such systems enable collaborative work on files by users across multiple locations. These systems store information which allows the modifications made to a file, the user providing the modifications, and the timing of the modifications to be tracked.

[0007] Tracking the timing and authorship of files is of particular importance in the field of Intellectual Property (IP). Taking patents as an example, it can take a significant time from first conception for an invention to be implemented, with many iterations and modifications occurring over that time period. Who provided certain inputs is important for determining both inventorship and ownership of the IP. Timing may also be important for determining ownership, prior use rights, etc. especially in the context of disputes.

[0008] SUMMARY

[0009] Existing file management systems cannot be solely relied on to accurately track the life of a file or its authorship. Modifications / changes to files are lost over time, e.g. as new versions are saved, overwriting previous versions, or as previous versions are lost or deleted. Similarly, whilst existing file management systems may record, at least temporarily, author / modifier data relating to the creation and modification of files, such data may be lost (e.g. as new updates are made to the file to the file is made), or even tampered with. Moreover, whilst existing file management systems can typically timestamp the creation or even last modification of a file, the time associated with intermediate changes may be lost. Again, existing file management systems are susceptible to tampering.

[0010] Existing systems therefore do not provide an immutable record of the life of a file, nor do they provide an immutable and verifiable link between the file content and the content creator.

[0011] Embodiments herein make use of the properties of the blockchain, which provides an immutable, timestamped database.

[0012] Storing a file on-chain does by itself does not provide an accurate representation of the file's life. For example, the stored file may only be the final file, and so does not provide information about modifications or iterations that have occurred over the life of the file which have resulted in the final version. This can lead to a loss of information.

[0013] Moreover, storing solely the file on-chain does not impart any reliable information about authorship of the document. That is, it cannot be guaranteed that the user (e.g. public key) or account, to which the transaction storing the file is linked, has any ownership over the file itself. Even if an author of a final file can be identified, information about contributors over time can be lost, as modifications are made to the documents.

[0014] There is therefore a need for a mechanism that can provide an immutable record of a file's lifecycle, from creation to completion. Similarly, there is a need for a mechanism that can provide an immutable record of the author / modified responsible for authoring / modifying a file.

[0015] According to one aspect disclosed herein, there is provided a computer-implemented method for recording an electronic file, wherein the method is implemented by a file proof platform, comprising: accessing a folder; executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder; obtaining the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; generating a commitment value based on the electronic file; generating a proof blockchain transaction comprising the commitment value; and causing the proof blockchain transaction to be made available to one or more nodes of a blockchain.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method of verifying an electronic file at a file proof platform, the method comprising: receiving a candidate electronic file; generating a candidate file commitment value based on the candidate electronic file; obtaining, from a proof database of the file proof platform, a link to a proof blockchain transaction stored in association with the candidate file commitment value, wherein the proof blockchain transaction comprises a proof commitment value, wherein the proof commitment value is derivable from a target electronic file and first author data of a first author of the target electronic file; obtaining, from the blockchain using the link, a target file commitment value, wherein the target file commitment value is derivable from the target electronic file; generating a candidate proof commitment value based on the candidate electronic file and candidate first author data of a candidate first author of the candidate electronic file; and comparing the candidate proof commitment value and the target proof commitment value, wherein the candidate electronic file is verified if the candidate proof commitment value is equal to the target proof commitment value.

[0017] According to another aspect disclosed herein, there is provided a computer-implemented file proof platform, wherein the file proof platform comprises: an autoscan module configured to access a folder, executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder, and obtain the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; and a proof module configured to generate a commitment value based on the electronic file, generate a proof blockchain transaction comprising the commitment value, and cause the proof blockchain transaction to be made available to one or more nodes of a blockchain.

[0018] According to another aspect disclosed herein, there is provided a computer-implemented file proof platform, wherein the file proof platform comprises: a proof database; and a verification module configured to: receive a candidate electronic file; generate a candidate file commitment value based on the candidate electronic file; obtain, from the proof database, a link to a proof blockchain transaction stored in association with the candidate file commitment value, wherein the proof blockchain transaction comprises a proof commitment value, wherein the proof commitment value is derivable from a target electronic file and first author data of a first author of the target electronic file; obtain, from the blockchain using the link, a target file commitment value, wherein the target file commitment value is derivable from the target electronic file; generate a candidate proof commitment value based on the candidate electronic file and candidate first author data of a candidate first author of the candidate electronic file; and compare the candidate proof commitment value and the target proof commitment value, wherein the candidate electronic file is verified if the candidate proof commitment value is equal to the target proof commitment value.

[0019] Embodiments of the present disclosure may be used to track the creation and authorship of files for the purpose of IP protection. For example, embodiments may be used to confirm inventorship of an invention that is to be patent protected. Example use cases are explained in detail below.

[0020] BRIEF DESCRIPTION OF THE DRAWINGS

[0021] To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

[0022] Figure 1 is a schematic block diagram of a system for implementing a blockchain, Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain,

[0023] Figure 3A is a schematic block diagram of a client application,

[0024] Figure 3B is a schematic mock-up of an example user interface that may be presented by the client application of Figure 3A,

[0025] Figure 4 is a schematic block diagram of some node software for processing transactions,

[0026] Figure 5 provides an example method for generating a file proof;

[0027] Figure 6 provides an alternative method for generating a file proof;

[0028] Figure 7 provides an example method for verifying a file;

[0029] Figure 8 is a schematic block diagram of a file proof platform;

[0030] Figure 9 shows an example home page user interface of the file proof platform;

[0031] Figure 10 shows an example autoscan setup user interface of the file proof platform;

[0032] Figure 11 shows an example active autoscan view user interface of the file proof platform;

[0033] Figure 12 shows an example user interface for uploading a file for generating a proof;

[0034] Figure 13 shows an example user interface for providing author data;

[0035] Figure 14 shows an example document proof user interface of the file proof platform;

[0036] Figure 15 shows an example user interface for uploading a file verifying; Figure 16 provides an example method for generating a proof of a file modification;

[0037] Figure 17 provides an example method for verifying the file modification; and

[0038] Figure 18 schematically illustrates a process for recording a proof commitment on a blockchain.

[0039] DETAILED DESCRIPTION OF EMBODIMENTS

[0040] 1. FILE PROOF PLATFORM

[0041] According to some embodiments of the present disclosure, a platform is provided which improves the credibility and integrity of file storage systems by recording specific data both off and on-chain. The platform enables the creation and changes of files to be tracked, and the authorship / editorship of the file / change to be accurately recorded. The platform interacts with a blockchain to immutably record commitments which allow for later verification of accurate records.

[0042] Figure 8 shows an example platform 504, also referred to herein as a file proof platform. The platform may be a dedicated application stored and executed on a user device, or hosted on and run via a web browser. The file proof platform 504 comprises four modules: an autoscan module 802, an authorship module 804, a proof module 808, and a verify module 810. The platform also comprises two databases: an author database 806 and a file proof database 812. It will be appreciated that, in certain embodiments as discussed below, the platform 504 may comprises a subset of these modules and databases. In some examples, the file proof platform 504 may also comprise a file database, e.g. a file management system.

[0043] The modules illustrate functionalities of the platform 504. The steps executed by each module may vary depending on the embodiment.

[0044] The proof module 808 is configured to generate a file proof. The file proof comprises a commitment to the file at a given time, and may further include a commitment to the authorship of the file at that time. Other data may be included in the proof, such as a file identifier and the time at which the proof is generated. The proof module 808 is also responsible for generating a proof transaction for storing data on-chain, and for storing data off-chain in the file proof database 812. The data stored both on- and off-chain allows a file to later be verified.

[0045] The verify module 810 is configured to verify a file. The verify module 810 receives a file to be verified, obtains information associated with the file from the file proof database 812 and the blockchain. It performs computations which allow the verify module 812 to determine if the received file is accurate. The verify module 810 may also verify the associated authorship of the file.

[0046] The authorship module 804 determines the author(s) of a file. This may be achieved using metadata of the file or based on an input from a trusted party. For instance, as explained further below, the application used to generate the file and / or the file storage platform may generate metadata that tracks who authored / modified a file and when. The authorship module may generate and / or store a unique identifier of an author with personal data of the author, such as a name or email address, in the author database 806. The authorship module 804 may request authorship information or verification of the authorship information from a trusted third party. The authorship module 804 may also store verified authors of a file in the author database 806. The authorship module 804 provides author data to the proof module 808.

[0047] Within the context of the present disclosure, the term "author" may refer to any user who provides content to a file. It is not limited to an original author of the file. For example, a first user may generate a document and a second user may provide a new section to the document. Both of these users are considered authors of the document. In some examples, "author" may also refer to an editor of a document.

[0048] Note that examples will primarily be described in terms of the electronic file being a "document", e.g. a Word or PDF document. However this is merely for illustrative purposes and the electronic file may take any suitable form, such as an image file (e.g. JPEG, PNG, BMP, etc.) , video file (e.g. MPEG4, MOV., WMV. etc.), audio file (e.g. MP3, WAV., AAC., etc.) program code (e.g. JAVA, C++, Python, Visual C#, etc.).

[0049] The autoscan module 802 is configured to scan a document storage folder 502, remote to the platform 504. The document storage folder 502 may be a cloud document management system, such as OneDrive, SharePoint, GoogleDrive, or Dropbox. The autoscan module 802 may be connected to the document storage folder 502 via an application programming interface (API). Alternatively, the document storage folder 502 may be a folder stored locally on a user device or within a network (e.g. a shared drive or document management system accessible to users of the network). The autoscan module 802 scans the document storage folder 502 to identify any modifications to the data stored in the folder since a last scan. Such modifications include the storage of new files and modifications to previously stored files. The autoscan module 802 may identify modifications based on metadata associated with the file(s) and / or folder. For example, one or more files and / or folders may have an associated date and / or time of creation, an associated date and / or time of last modification, etc. In some examples, one or more files and / or folders may be marked as newly created or modified by a user. In some examples, one or more files and / or folders may have an associated status set and updated by the document management system. The status may indicate whether any changes have been recently made. The autoscan module 802 may identify modifications based on the status.

[0050] The autoscan module 802 obtains files which have been identified in the scan as new / modified. The autoscan module 802 also obtains file metadata of the identified file, which may include personal data of the author(s) and a timestamp. The autoscan module 802 passes the new / modified file to the authorship module 804, where authorship is determined, after which the file and authorship information is passed to the proof module 808. The autoscan module 802 may pass the file directly to the proof module 808.

[0051] Figure 5 provides a first example method for generating a file proof. In this example, a trusted third party, referred to herein as a notary 506, provides the authorship details for a file. The file proof platform 504 requests access to a folder 502 at step 1, and executes the folder scan at step 2. The platform 504 may request access to the folder 502 at predefined time intervals, for example every minute, or it may request access in response to receiving a notification from the folder 502 that a modification has occurred, or it may request access in response to a user input initiating a scan. In another embodiment, the platform 504 may have continuous access to the folder 502, with the scan be executed at the predefined time interval or in response to a notification or user input.

[0052] When scanning the folder 502, the platform 504 determines if there are any modifications since the immediately previous scan. Modifications include both modifications to individual files stored in the folder 502, such as amendments to a document, and new files being stored in the folder 502. If there has been a modification to the folder 502 since the last scan, the modified file or new file, whichever is applicable, is obtained by the file proof platform 504, step 3. The metadata of the new / modified file may also be sent with the file. This metadata may comprise authorship information, timing information, etc. The authorship data may define specific sections of the file which have been authored by specific authors. For example, the file may comprise metadata that associates particular changes with particular authors. E.g. the metadata may identify a creator of the document, a most recent editor of the document, etc. In some cases, the application used to create and modify the file may have functionality for tracking changes to the document, and for linking those changes to an author (i.e. user). Said linking may be stored in metadata of the file.

[0053] Steps 1 to 3 of Figure 5 may be referred to a "monitoring". The mechanism of monitoring depends on what is supported by the system hosting the folder. Some systems offer notifications, while in other cases scheduled polling must be used. The hosting system is trusted for correctness of provided data.

[0054] At step 4, a request for authorship details is sent to the notary 506. The notary is a trusted entity who is able to confirm authorship of a file. The notary 506 provides the authorship details to the file platform 504 at step 5. In some embodiments, the notary 506 provides the authorship data independently of any other inputs.

[0055] In other embodiments, the file metadata is used to determine the author of the file. The notary 506 provides confirmation that the author determined from the file metadata is an author of the file. Confirmation of author may be stored in the authorship database 806 along with an identifier of the file. The platform 504 may refer to the data stored in the author database 806 when a file is obtained from the folder 502 to determine if the author as determined from the file metadata is already confirmed as an author of the file. If so, the notary 506 need not perform the confirmation again, and as such steps 4 and 5 of Figure 5 are not executed. If, however, the determined author has not been confirmed, the notary 506 is notified, and steps 4 and 5 executed.

[0056] File authors are one type of file contributors. Contributors can also be people who do not provide any substantial additions to the file, but instead act to check or refine the content, such as editors or proofreaders. In some instances, it may be that the identity of author only are required, so the first step of the notary 506 is to establish the identity of the contributors and authors. Establishing identity is external to the platform 504, but an approved identity can be linked to the contributor.

[0057] Every contributor identified as an author is assigned an internal unique identifier which is used in proofs. The unique identifier is stored in the author database 806 with personal data of the author, such as a name or email address. This personal data allows the unique identifier of the author to be obtained based on file metadata and / or an input from the notary 506.

[0058] Once authorship has been determined, the file proof can be generated.

[0059] At step 6, a commitment to the file is computed. In some examples provided herein, the commitment is a hash value computed by applying a hash function to the file, such as a SHA256 hash function. Any suitable hash function may be used. In other examples, the commitment may be a Pedersen commitment. At step 7, a proof commitment value is computed. Similar, herein, this commitment value may be a hash value, e.g. a SHA256. Other commitments may be used. The proof commitment commits to both the file and the authorship of the file. The proof commitment may be computed by hashing a concatenation of the file and the unique identifier of the author. Alternatively, the unique identifier of the author may be hashed to compute an author commitment value, which is then concatenated or otherwise merged with the file commitment value before being input to a commitment function (e.g. before being hashed again). Committing to data in this way provides anonymity. It will be appreciated that the file and the author identifier may be combined in other suitable ways to compute the proof commitment. If there are multiple authors, the identities of each author are included in the proof commitment. Note the terms commitment value and hash value may be used interchangeably herein, unless the context requires otherwise.

[0060] In some embodiments, the proof commitment includes timing data. For example, a time at which the file was obtained from the folder 502 or a time of a modification may be provided as input when computing the proof commitment.

[0061] Once the proof commitment has been computed, a proof transaction is generated, step 8, comprising the proof commitment. The proof transaction may be a transaction of an account-based blockchain, in which case the proof commitment is stored in a payload of the transaction. Alternatively, the proof transaction may be transaction of an output-based blockchain, e.g. blockchain 150 of Figure 1. The proof commitment may be included in a locking script of the proof transaction, e.g. using an OP_RETURN opcode. Storing the proof hash on chain provides timestamping, such that it is possible to prove in the future that certain file contents were linked with a certain author at a specific point in time.

[0062] The proof transaction is made available to (e.g. sent to) a node 104 of the blockchain 150, step 9, which stored the proof transaction once verified by the node 104, step 10. Storing the proof in this way may be referred to as on-chain proofing. The platform 504 obtains a transaction identifier of the proof transaction once stored, step 11. The transaction identifier may be sent to the platform 504 by the node 104 once the transaction is stored. Alternatively, the platform 504 may monitor the blockchain 150 to determine that the proof transaction has been stored, and access the stored transaction to obtained the transaction identifier.

[0063] The platform 504 generates an off-chain proof for the file. The off-chain proof comprises the file hash, the proof hash, and a link to the proof transaction stored on chain. The off-chain proof may further comprise authorship data, such as the author's name and / or email address, a file identifier of the file, and timing data. The off-chain proof is stored at the proof database 812.

[0064] The proof commitment and proof transaction allows data which links the author to the file to be stored without revealing the identity of the author. That is, the author cannot be derived from the proof transaction alone. However, a given author can be verified as the author of the file using the proof commitment. The proof commitment therefore provides a mechanism for obfuscating the author data.

[0065] Figure 6 provides an alternative method for generating a file proof. In the example of Figure 6, there is no notary 506 performing an external confirmation of the authors. However, it will be appreciated that the notary 506 may be included in the method, and the method steps as set out with reference to Figure 5, steps 4 and 5, executed in this method.

[0066] A user 103 uploads a file to the file proof platform 504 at step 1. This is an alternative method for the platform 504 obtaining the file that does not require the autoscan module 802.

[0067] The file proof platform 504 extracts the author data from the file metadata at step 2, and then determine the unique author identifier at step 3 by accessing the author database 812.

[0068] Steps 4 to 10 of Figure 6 correspond to steps 6 to 12 of Figure 5. That is, the file commitment and the proof commitment are computed, the proof commitment provided in a proof transition which is stored on-chain, and an off-chain proof stored, comprising the commitments, the transaction link, and the authors.

[0069] In both examples, the file content is only made accessible to a secure environment within the file proof platform 504. The content is not stored in persistent memory. This ensures security of the file.

[0070] For example, the contents of the file are provided to the platform 504 as bytes along with information about the author / contributor of the change and time of change. In some examples, only a specially designated component of platform 504 is allowed to access the contents and only for the purpose of creating a commitment (e.g. SHA256 hash). In these examples, the contents are read as bytes, kept in runtime memory and discarded immediately after creating the hash. They are never persisted to any permanent storage.

[0071] The file hash, otherwise referred to as the hash of contents, may be recorded with file origin, file name, size and type, author id and timestamp of modification as an immutable file version. This immutable file version may be provided as input to the proof commitment function.

[0072] The off-chain record allows the platform 504 to verify if file contents have been proofed before. It also creates a ledger of file changes which can contain input from multiple scanned sources or manually uploaded files.

[0073] Figure 7 provides an example method for verifying a file using the file proof platform 504.

[0074] At step 1, a user 103 uploads a candidate file to the file proof platform 504. In this context, the term "candidate" is used to refer to an item which is not known to be valid, while "target" is used to refer to items which are known to be valid.

[0075] The platform 504 generates a candidate file hash based on the received candidate file, by applying the same hash function as that used in proof generation, step 2. Using the candidate file hash, the platform obtains from the proof database 812 the candidate proof transaction link, step 3.

[0076] Using the candidate proof transaction link, the target proof hash is obtained from the blockchain. The platform 504 requests the target proof hash in step 4, and receives the target proof hash in step 5.

[0077] In order to verify the candidate file, the platform compares the obtained target proof hash to a candidate proof hash computed based on the received candidate file.

[0078] To compute the candidate proof hash, candidate author identifiers are first obtained at step 6. The candidate author identifiers may be determined in a number of different ways. In some embodiments, the candidate author identifiers may be derived from metadata of the candidate file. In other embodiments, the author data stored in the off-chain proof with the candidate file hash is used to derive the candidate author identifiers. In each instance, the author data is used to obtain the corresponding author identifiers from the authorship database 806.

[0079] The candidate proof hash is then computed as step 7 using the same computation as that used to generate the proof hash proof generation. For example, the candidate file hash may be concatenated or otherwise merged with a hash of the candidate author identifier, and this value hashed again.

[0080] At step 8, the platform 504 compares the candidate proof hash and the target proof hash. If the values are the same, the candidate file is valid. That is, the candidate file is an accurate representation of the file that was used to generate the proof.

[0081] In the methods set out above, the unique author identifier is provided as input for generating the proof commitment. However, it will be appreciated that other author data may be used instead. For example, the author name, email address, or other identifying data may be used. The file proof platform 504 may be used more broadly to track changes to files. This method may be used where the authorship of the file is not of importance, but where having an accurate record of the iterations of the file is. Figures 16 and 17 provide example methods for generating a proof of the document at a given time and verifying the document respectively.

[0082] To generate the proof, the file platform 504 requests access to the folder (Figure 16 - step 1), scans the folder 502 (step 2) and retrieves or otherwise receives the new or modified file from the folder 502 (step 3). This corresponds to steps 1 to 3 of Figure 5.

[0083] At step 4, a commitment to the obtained new or modified file is generated. The commitment may be a hash or salted hash of the file, for example. The file platform generates a proof transaction comprising the commitment to the obtained file, in step 5, which it makes available to a node 104 of the blockchain 150 for storing, steps 6 and 7.

[0084] The file proof platform 504 obtains the proof transactions identifier at step 8, from which a link to the proof transactions is derived. This link is stored at the proof database 812 with data which associates the link with the file, step 9.

[0085] The data which associates the link with the file may be the file commitment value, the file identifier, a timestamp associated with the file such as the date and time of the most recent modification of the file, the file size, the file type, file authorship information, etc. While some of these data items may not be sufficient in isolation that the files being references are the same, a combination of the data items would in most cases provide sufficient information for the verification process.

[0086] Figure 17 illustrates an example verification process.

[0087] In a similar manner to that of Figure 7, the user 103 uploads the candidate file to the file proof platform 504, step 1, which generates a candidate file commitment value, step 2. Using the received candidate file, the file proof platform 504 obtains the candidate proof transaction link from the proof database 812. For example, the file proof platform 504 may use the metadata of the candidate file to determine a file identifier and a file time stamp which can be used to identify the candidate link. It will be appreciated that other data associated with the candidate file may be used to identify the candidate link, and depends on the data stored in the proof database 812 associated with the link.

[0088] Once the candidate link has been obtained, the file proof platform 504 requests the target file commitment from the blockchain 150, step 4, and receives the target file commitment from the blockchain 150, step 5.

[0089] The file proof platform 504 compares the computed candidate commitment with the obtained target file commitment. If the two values match, the candidate file is verified.

[0090] In some embodiments, a modified version of the methods set out in Figures 5 to 7 may be used in the event that the authorship of the file is not of importance. In these embodiments, the author data which is used to derive the proof commitment in Figures 5 to 7 may be replaced with other data associated with the file. For example, a file timestamp may be used, such that the proof hash is computed by hashing a combination of the file hash and a hashed timestamp of the file. The methods of Figures 5 to 7 in this example would be modified in that author data is replaced with the file timestamp. It will be appreciated that other data may be used in place of the author data, as is important within the context of the application for verifying correctness.

[0091] Figures 9 to 15 provide example user interfaces that may be rendered by the file proof platform 504 at a user device of a user.

[0092] Figure 9 provides an example home page 900 of the platform 504. The home page 900 provides three user selectable options: "create proof" 902, "verify proof" 904, and "autoscan "906. The user may select any of the user selectable option 902, 904, 906 to initiate the associated action.

[0093] Figure 10 provides a user interface for setting up an autoscan. In this example of Figure 10, the document file system which is to be autoscanned is SharePoint, but it will be appreciated that other document file systems may be used.

[0094] The user may provide the folder to be scanned in one of two ways. The first is by selecting from a dropdown menu 1002, and the second is by providing a link, or URL, in a text box 1004.

[0095] It will be appreciated that, within the context of the platform, the term "folder" may refer to a single folder or a collection of folders. The folders may be arranged in a hierarchical manner. The autoscan is run over all folders within the collection of folders.

[0096] Once the user has selected or input the folder for scanning, the user selects an autoscan initiation icon 1006, which causes the autoscan to be configured and initiates the autoscan.

[0097] Figure 11 provides another autoscan user interface. This user interface provides the user with the autoscans which have been configured, and data about the autoscans. A user is provided with information about each autoscan, such as a name, file type, author, last upload date, and status of last upload. The user may select a configured autoscan to find out further information about the autoscan, such as viewing stored document proofs associated with the autoscan.

[0098] Figure 12 provides an example user interface for creating a proof for a file uploaded by the user.

[0099] The user can provide the candidate file by dragging and dropping an icon representing the file into the drag-and-dop area 1202 of the user interface. Alternatively, the user can select a file from files stored on their user device using the browse files selectable icon 1204. Once the user has selected the candidate file, an icon identifying the candidate file is rendered in a document display area 1206. The user selects a create proof icon 1208 to initiate the proof generation process.

[0100] Historic file verifications are shown in an upload history area 1210 of the user interface. Data associated with each historic upload may be displayed, such as file name, file type, author, upload date and time, and status. The user may be able to select one of the historic uploads to see more data associated therewith.

[0101] Figure 13 provides a user interface for providing authorship data. This user interface may be rendered in response to the user selecting the create proof icon 1208. This user interface may alternatively be rendered at a user device of the notary 506.

[0102] The user interface provides the document name, the file hash, and other data about the file such as the file type and the file size. The user provides author details in a text box 1302, and selects the submit icon 1304 to cause the platform to generate the proof.

[0103] Figure 14 provides an example file proof user interface. The file proof comprises the file details and author details. The file details comprise the file hash, the proof hash, the link to the proof transaction, the file identifier, the file type, the file size, the file upload date, and the file record date. The author details comprise the name, email address, and unique author identifier.

[0104] Figure 15 provides an example verification user interface. The user can upload a candidate file for verifying by dragging and dropping a file icon into the drag and drop area 1502 or by selecting a file from storage using the browse files icon 1504. The user can alternatively provide a checksum via text box 1506. Once the user has provided the candidate file, the user selects the verification initiation icon 1508 to cause the platform 506 to verify the candidate file.

[0105] The file proof platform 504 provided herein improves the credibility of a cloud based file storage system, or other file storage system, by keeping track of changes and recording specific data both off and on-chain. The additional manual step of confirmation by a human notary enhances the data by creating an immutable and verifiable timestamp of the fact that notary verified external data. The records are hashed and salted, making the contents of the files "unreadable", and at the same time proofing the contents of the file, alongside with authorship data (UUID). Only the final hash is recorded on-chain, which creates an immutable record, which can be verified by having access to original file and author data (UUID). The source of truth remains the external system and the notary.

[0106] The platform provided herein streamlines storing document changes on-chain, not just the final content. It generates private, not anonymised, immutable records. The immutable records are transaction records on-chain, which include hash. That hash is salted hash of the document and hash of the author making it unreadable to "outside" user, while safely storing it on public blockchain and distributed ledger.

[0107] By generating proofs of content, without storing the files, the process is very robust and highly secure, as no one system needs to store the original file (system independence). This allows file verification by only having identity of the author and access to the original file without any dependency on any system.

[0108] Most known systems require user authentication, action, and payment (on-chain) to happen in order for transaction to be generated. The file proof platform enables abstraction of these actions making it possible to automate everything on behalf of user. Users need to pay, need to authenticate and need to act, however, this needs to happen at the "setup" and "monthly", while in-between, the platform application automatically streamlines records from one system (i.e. Document storage system such as Sharepoint) to blockchain (with the platform in between).

[0109] According to some embodiments of the present disclosure, there is provided a method for securely linking file content to an associated author. The examples described below may be used together with or separately from any of the examples described above. For instance, the method may be performed by the proof platform. Whilst examples will be described as being performed by the proof platform, in general any entity or system may perform said examples. For example, the described embodiments may be implemented internally by a company or other organisation, or by individual users.

[0110] The proof platform obtains an electronic file to be linked to an author. As described above, the electronic file may be provided by a user (who may or may not be the author) via a user interface, or by scanning a (folder of) a file / document management system. The scan be executed automatically (e.g. at set intervals or in response to detecting a new / modified file) or in response to a user input. The folder management system may be internal to the proof platform or stored on the same device on which the proof platform is executed / run. Alternatively, the management system may be external to the proof platform, e.g. a cloud based folder system.

[0111] In some examples, the proof platform encrypts the electronic file.

[0112] The proof platform also obtains author data identifying an author of the electronic file. As discussed above, "author" may refer to an original creator or an editor of the file. The author may be identified by name, username, email address, authority-issued credential (e.g. passport or driving license number, or government identifier), digital identity, etc.

[0113] The proof platform generates a file commitment value based on the electronic file or the encrypted file. The commitment value may also be based on a salt value. In some examples, the file commitment value is a hash value generated by hashing the (encrypted) file and optionally, the salt. Any suitable hash functions may be used, such as a SHA-based hash function, e.g. SHA256. Other commitments may be used, e.g. Pedersen commitment, Elliptic Curve Pedersen Commitments, Bulletproof commitments, etc.

[0114] Similarly, the proof platform generates an author commitment value based on the author data and optionally, a salt. The commitment value may also be a hash value.

[0115] In some examples, the file commitment value is also based on file metadata. The file metadata may form part of, or be separate from, the electronic file. The file metadata may include any or all of an origin, type, file name, and size of the electronic file, a timestamp of creation or modification of the electronic file, author data.

[0116] Having generated the file commitment value and the author commitment value, the proof platform generates a proof commitment value based on the file commitment value and the author commitment value. For example, the file commitment value and the author commitment value may be combined (e.g. concatenated) and input to a commitment function (e.g. a hash function). The proof commitment value therefore links the contents of the file to the author.

[0117] The proof platform includes the proof commitment in a blockchain transaction and submits the transaction to the blockchain network 106. Alternatively, the blockchain transaction may be sent to a third party for submitting to the network 106. As another alternative, the proof platform may provide the proof commitment value to a third party for including a transaction to be sent to the blockchain by the third party. Storing the proof commitment value on the blockchain creates an immutable record of the link between the file contents and the author.

[0118] In some examples, the proof platform may require a trusted entity (e.g. a notary, lawyer, authorised user, etc.) to authorise / authenticate the author data. The generation of the proof transaction may at least in part be conditional on receiving user input from the trusted entity.

[0119] The proof platform may provide the proof commitment and / or the proof transaction to a user, e.g. a user wishing to verify the link between a file and an author. The proof platform may provide a link / reference to the proof transaction in addition to or instead of the proof transaction itself. The link may be a URL to website that tracks blockchain activity. The reference may be a transaction identifier.

[0120] The proof platform may store, in accessible storage, one or more of the file commitment, the author commitment and the proof commitment. The proof platform may store the link / reference in association with the commitment(s), e.g. in a look-up table. Figure 18 illustrates an example flow for generating a proof commitment and transaction. In this example, the commitment values are SHA256 hash values. In the example of Figure 18, file content is obtained from a SharePoint file and hashed to generate a file hash (SHA256_File Content)). Metadata is obtained from SharePoint data to obtain / generate a user identifier (UUID) associated with the file content. The user identifier is hashed to generate an author hash (SHA256_UUID). The file hash and the author hash are then combined and hashed to generate a proof hash (Final_SHA256). The proof hash is then stored on-chain to create an on-chain record of the proof hash.

[0121] 2. IP APPLICATION

[0122] IP protection is a complex process. It can take a significant time from first conception for an invention to be implemented, with many iterations and modifications occurring over that time period. It may only be at this stage that the concept is fit to be legally protected as actual asset, and the idea is filed in a patent application. At that time, it becomes extremely difficult to collect all the past material, and prove with any certainty the accuracy of the material.

[0123] There are few main issues with IP tracking today:

[0124] • Only final recording of consolidated IP is tracked through official institutions. In reality, inventions and IP are generated over a period of time. Throughout this process, there is no simple way today to efficiently track IP.

[0125] • IP recordings need to be recorded via an authority, that can legally prove person / author (or authors), hence, beyond physical notary deposits and records, recording become extremely hard to track.

[0126] • Systems are easy to manipulate with and change documentation - there is a need for immutable records, that do not allow changes, after the record has been made (of IP / invention).

[0127] The current process for securing IP is fraught with inefficiencies and risks, particularly in the following areas: • Time-consuming documentation: As inventors develop their ideas over several years, it becomes challenging to track and store every iteration, modification, and related documentation. By the time they are ready to file for IP protection, retrieving all necessary records is cumbersome and often incomplete.

[0128] • Lack of trust and verification: Establishing the originality of an idea and its subsequent changes is crucial for IP protection. However, without a reliable system to document every step, disputes over ownership and authorship can arise, undermining the trust in the IP filing process.

[0129] • Inefficient document tracking: Existing document storage solutions are not designed to automatically capture every change made during a document's lifecycle. As a result, there is no reliable way to generate immutable records of these changes, leaving IP claims vulnerable to challenges.

[0130] • Legal vulnerability: Without a robust mechanism to prove the authenticity and ownership of each fragment of an invention, the IP protection process is susceptible to legal disputes, potentially leading to the loss of valuable intellectual property.

[0131] The provide file proof platform 504 offers several distinct advantages over existing document storage and IP management solutions:

[0132] • Automated Documentation and Tracking: o Unlike traditional storage solutions that require manual tracking and updating of documents, the platform automatically monitors and records every change made to IP-related documents. This eliminates the need for inventors to manually organize and archive each iteration, significantly reducing the time and effort required to maintain accurate records.

[0133] • Immutable Records on Blockchain: o The platform utilizes blockchain technology to create immutable records of every document change, including content, modifications, and authorship. This ensures that once a record is created, it cannot be altered or tampered with, providing a secure and trustworthy audit trail that can be relied upon in legal disputes.

[0134] • Real-time Snapshot Generation: o The platform continuously generates snapshots of documents throughout their lifecycle, capturing every significant change. This feature ensures that all versions of a document are preserved in a verifiable manner, making it easier to establish the evolution of an idea or invention over time.

[0135] • Enhanced Trust and Legal Security: o By providing a transparent and verifiable record of document history, the platform strengthens the legal standing of IP claims. The clear chain of custody and authorship helps prevent disputes and reinforces the inventor's position in case of challenges, thus enhancing overall trust in the IP protection process.

[0136] • Streamlined IP Filing Process: o With all relevant documentation automatically organized and securely stored, the process of preparing and filing for IP protection becomes more efficient. Inventors can quickly retrieve all necessary evidence without worrying about missing or incomplete records, accelerating the path to IP registration.

[0137] • Seamless Integration with Existing Solutions: o The platform is designed to integrate with existing document storage systems, allowing organizations to adopt the platform without overhauling their current workflows. This seamless integration ensures that the benefits of the invention can be realized without significant disruption or additional complexity.

[0138] • Scalability and Flexibility: o The platform is scalable to accommodate the needs of both individual inventors and large organizations. Whether managing a single invention or an entire portfolio of IP, the platform can efficiently handle the documentation and tracking requirements, offering flexibility to users at various scales.

[0139] 3. EXAMPLE USE CASES

[0140] Example: IP Law Firm Collaboration with Clients Scenario: An IP lawyer is working with a company to protect a new invention. To streamline communication and documentation, the lawyer creates a shared folder where both the legal team and the company can upload documents, drafts, and other relevant materials throughout the development process.

[0141] Application of the file proof platform: As documents are added or modified in the shared folder, the platform automatically records every change, including the content, timestamps, and authorship. Both the IP lawyer and the company have access to a real-time, immutable record of all interactions and document revisions.

[0142] Advantages:

[0143] • Automated Documentation and Tracking: The lawyer and the company can focus on strategic decisions without worrying about manually tracking every document change. The platform ensures that all materials are securely documented as they are developed.

[0144] • Enhanced Trust and Legal Security: The platform provides both parties with a verifiable record of all communications and document versions, which is crucial in building a strong IP case and preventing disputes over contributions or ownership.

[0145] • Streamlined IP Filing Process: When it's time to file for IP protection, all necessary documents and evidence are already organized and securely stored, making the process faster and more efficient.

[0146] • Seamless Collaboration: The shared folder facilitates easy and secure collaboration between the lawyer and the client, with the platform ensuring that all contributions are accurately recorded and preserved.

[0147] This example illustrates how the platform can enhance collaboration between IP lawyers and their clients by automating the documentation process, ensuring the integrity of records, and providing a secure, legally robust system for managing the evolution of intellectual property. Example: R&D in Technology Companies

[0148] Scenario: A tech company is developing a new software algorithm that involves multiple teams working on different components over several years. Each team contributes to the codebase, documentation, and design specifications.

[0149] Application of the file proof platform: The platform automatically tracks every change made to the code, documentation, and design files, recording each version and the author responsible. As the project evolves, the platform generates immutable snapshots of the entire development process.

[0150] Advantages:

[0151] • Automated Documentation and Tracking: The company no longer needs to manually manage version control and documentation for IP purposes.

[0152] • Real-time Snapshot Generation: Every stage of the algorithm's development is securely documented, making it easier to prove the originality and authorship of the final product.

[0153] • Enhanced Trust and Legal Security: If the company needs to prove the originality of its algorithm in a patent application or legal dispute, it has a robust, verifiable record of the entire development process.

[0154] Example: Pharmaceutical Research

[0155] Scenario: A pharmaceutical company is developing a new drug. The research involves multiple phases, including chemical synthesis, clinical trials, and regulatory submissions. Each phase generates a vast amount of data, including lab notes, test results, and trial outcomes.

[0156] Application of the file proof platform: The platform listens to changes in dedicated document storage folders, capturing every update to lab notes, test results, and other critical documents. It creates immutable records of each phase of the drug's development, including who made each contribution.

[0157] Advantages: • Immutable Records on Blockchain: The company can secure all research data in an unalterable format, protecting its IP from tampering or disputes.

[0158] • Streamlined IP Filing Process: When the company is ready to file for patent protection, all relevant data and documentation are easily accessible, ensuring a smooth and efficient filing process.

[0159] • Seamless Integration with Existing Solutions: The platform integrates with the company's existing research management tools, allowing researchers to continue working without disruption while benefiting from enhanced IP protection.

[0160] Example: Creative Industries - Film and Media Production

[0161] Scenario: A film production company is working on a new movie script. Over the course of development, the script undergoes numerous revisions, with contributions from multiple writers and editors. The company needs to ensure that each contributor's work is properly documented and credited.

[0162] Application of the file proof platform: The platform automatically tracks every revision of the script, capturing each change and identifying the author responsible. It generates snapshots of the script at various stages, preserving a clear record of its evolution.

[0163] Advantages:

[0164] • Enhanced Trust and Legal Security: The company can easily verify who contributed to each version of the script, reducing the risk of disputes over authorship and credit.

[0165] • Automated Documentation and Tracking: The production team doesn't need to manually track script revisions, freeing up time and resources for creative work.

[0166] • Scalability and Flexibility: Whether it's a small indie project or a major studio production, the platform can handle the documentation needs, ensuring that the IP is protected regardless of the project's scale.

[0167] 4. EXAMPLE SYSTEM OVERVIEW

[0168] A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below.

[0169] Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.

[0170] The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data.

[0171] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0172] In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0173] An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

[0174] Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104. Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive.

[0175] The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.

[0176] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output. In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

[0177] Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0178] The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these. Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g. proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations.

[0179] Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104).

[0180] Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively.

[0181] The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

[0182] The client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0183] The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0184] Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

[0185] The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106.

[0186] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

[0187] Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contact" refers to a transaction that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0188] 5. UTXO-BASED MODEL

[0189] Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

[0190] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.

[0191] Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled " TxT. It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “ Txo" in Figure 2. TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0192] The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour.

[0193] One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

[0194] The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions. So in the example illustrated, UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA] contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0195] When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria).

[0196] Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain.

[0197] Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

[0198] The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

[0199] 6. SIDE CHANNEL

[0200] As shown in Figure 1, the client application on each of Alice and Bob's computer equipment 102a, 120b, respectively, may comprise additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For instance this may be used to exchange a transaction 152 between Alice and Bob without the transaction (yet) being registered onto the blockchain network 106 or making its way onto the chain 150, until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". A transaction template may lack one or more inputs and / or outputs that are required in order to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction related data, such as keys, negotiated amounts or terms, data content, etc.

[0201] The side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 as referred to anywhere herein may comprise any one or more links via one or more networking technologies or communication media for exchanging data "off-chain", i.e. separately from the blockchain network 106. Where more than one link is used, then the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Note therefore that if it is said that Alice and Bob exchange certain pieces of information or data, or such like, over the side channel 107, then this does not necessarily imply all these pieces of data have to be send over exactly the same link or even the same type of network.

[0202] 7. CLIENT SOFTWARE

[0203] Figure 3A illustrates an example implementation of the client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 comprises a transaction engine 401 and a user interface (Ul) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and / or send transactions and / or other data over the side channel 301, and / or send transactions to one or more nodes 104 to be propagated through the blockchain network 106, in accordance with the schemes discussed above and as discussed in further detail shortly. In accordance with embodiments disclosed herein, the transaction engine 401 of each client 105 may comprise a function 403 for generating the proof transaction and causing the proof transaction to be sent to the blockchain network 106.

[0204] The Ul layer 402 is configured to render a user interface via a user input / output (I / O) means of the respective user's computer equipment 102, including outputting information to the respective user 103 via a user output means of the equipment 102, and receiving inputs back from the respective user 103 via a user input means of the equipment 102. For example the user output means could comprise one or more display screens (touch or nontouch screen) for providing a visual output, one or more speakers for providing an audio output, and / or one or more haptic output devices for providing a tactile output, etc. The user input means could comprise for example the input array of one or more touch screens (the same or different as that / those used for the output means); one or more cursor-based devices such as mouse, trackpad or trackball; one or more microphones and speech or voice recognition algorithms for receiving a speech or vocal input; one or more gesture-based input devices for receiving the input in the form of manual or bodily gestures; or one or more mechanical buttons, switches or joysticks, etc.

[0205] Note: whilst the various functionality herein may be described as being integrated into the same client application 105, this is not necessarily limiting and instead they could be implemented in a suite of two or more distinct applications, e.g. one being a plug-in to the other or interfacing via an API (application programming interface). For instance, the functionality of the transaction engine 401 may be implemented in a separate application than the Ul layer 402, or the functionality of a given module such as the transaction engine 401 could be split between more than one application. Nor is it excluded that some or all of the described functionality could be implemented at, say, the operating system layer.

[0206] Where reference is made anywhere herein to a single or given application 105, or such like, it will be appreciated that this is just by way of example, and more generally the described functionality could be implemented in any form of software.

[0207] Figure 3B gives a mock-up of an example of the user interface (Ul) 500 which may be rendered by the Ul layer 402 of the client application 105a on Alice's equipment 102a. It will be appreciated that a similar Ul may be rendered by the client 105b on Bob's equipment 102b, or that of any other party.

[0208] By way of illustration Figure 3B shows the Ul 500 from Alice's perspective. The Ul 500 may comprise one or more Ul elements 501, 502, 502 rendered as distinct Ul elements via the user output means.

[0209] For example, the Ul elements may comprise one or more user-selectable elements 501 which may be, such as different on-screen buttons, or different options in a menu, or such like. The user input means is arranged to enable the user 103 (in this case Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the Ul element on-screen, or speaking a name of the desired option (N.B. the term "manual" as used herein is meant only to contrast against automatic, and does not necessarily limit to the use of the hand or hands). The options enable the user (Alice) to upload a file for proof creation, request verification of a proof, initiate an autoscan, etc.

[0210] Alternatively or additionally, the Ul elements may comprise one or more data entry fields 502, through which the user can ... These data entry fields are rendered via the user output means, e.g. on-screen, and the data can be entered into the fields through the user input means, e.g. a keyboard or touchscreen. Alternatively the data could be received orally for example based on speech recognition.

[0211] Alternatively or additionally, the Ul elements may comprise one or more information elements 503 output to output information to the user. E.g. this / these could be rendered on screen or audibly.

[0212] It will be appreciated that the particular means of rendering the various Ul elements, selecting the options and entering data is not material. The functionality of these Ul elements will be discussed in more detail shortly. It will also be appreciated that the Ul 500 shown in Figure 3 is only a schematized mock-up and in practice it may comprise one or more further Ul elements, which for conciseness are not illustrated.

[0213] 8. NODE SOFTWARE

[0214] Figure 4 illustrates an example of the node software 450 that is run on each blockchain node 104 of the network 106, in the example of a UTXO- or output-based model. Note that another entity may run node software 450 without being classed as a node 104 on the network 106, i.e. without performing the actions required of a node 104. The node software 450 may contain, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that contains one or more of: a consensus module 455C (for example, proof-of-work), a propagation module 455P and a storage module 455S (for example, a database). The consensus module 455C may contain a validation module (not shown) configured to validate transactions according to the blockchain protocol. The validation module may instead be separate from the consensus module 455C. One or more of the modules may operate in parallel. A node 104 may contain additional modules. The protocol engine 401 is typically configured to recognize the different fields of a transaction 152 and process them in accordance with the node protocol. When a transaction 152j (Txj) is received having an input pointing to an output (e.g. UTXO) of another, preceding transaction 152i (Txm-), then the protocol engine 451 identifies the unlocking script in Txj and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Txtbased on the pointer in the input of Txj. Txtmay be published on the blockchain 150, in which case the protocol engine may retrieve Txtfrom a copy of a block 151 of the blockchain 150 stored at the node 104. Alternatively, Txtmay yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Txtfrom the ordered set 154 of unpublished transactions maintained by the nodel04.

[0215] Either way, the script engine 451 identifies the locking script in the referenced output of Txtand passes this to the script engine 452.

[0216] The script engine 452 thus has the locking script of Txtand the unlocking script from the corresponding input of Txj. For example, transactions labelled Tx0and Tx are illustrated in Figure 2, but the same could apply for any pair of transactions. The script engine 452 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 453 in accordance with the stack-based scripting language being used (e.g. Script).

[0217] By running the scripts together, the script engine 452 determines whether or not the unlocking script meets the one or more criteria defined in the locking script - i.e. does it "unlock" the output in which the locking script is included? The script engine 452 returns a result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result "true". Otherwise it returns the result "false".

[0218] In an output-based model, the result "true" from the script engine 452 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 451 that must be met as well; such as that the total amount of digital asset specified in the output(s) of Txj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Txthas not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction TXj. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on condition that Txj is indeed validated, the decision engine 454 may select to control both of the consensus module 455C and the propagation module 455P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 455C adding Txj to the node's respective ordered set of transactions 154 for incorporating in a block 151, and the propagation module 455P forwarding Txj to another blockchain node 104 in the network 106. Optionally, in embodiments the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. E.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee.

[0219] Note also that the terms "true" and "false" herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, "true" can refer to any state indicative of a successful or affirmative outcome, and "false" can refer to any state indicative of an unsuccessful or non-affirmative outcome. For instance in an account-based model, a result of "true" could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true).

[0220] 9. FURTHER REMARKS

[0221] Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims. For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.

[0222] In preferred embodiments of the invention, the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred bitcoin network 106).

[0223] In other embodiments of the invention, the blockchain network 106 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0224] Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104. Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof- of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof- of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator.

[0225] It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements.

[0226] Statement 1. A computer-implemented method for recording an electronic file, wherein the method is implemented by a file proof platform, comprising: accessing a folder; executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder; obtaining the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; generating a commitment value based on the electronic file; generating a proof blockchain transaction comprising the commitment value; and causing the proof blockchain transaction to be made available to one or more nodes of a blockchain.

[0227] Statement 2. The method of statement 1, wherein the commitment value is a proof commitment value based on the electronic file, wherein the method further comprises: generating a file commitment value based on the electronic file; obtaining first author data identifying a first author of the electronic file, wherein the proof commitment value is generated based on the electronic file and the first author data; and storing, in a proof database of the file proof platform, the file commitment value in association with a link to the proof blockchain transaction stored on the blockchain.

[0228] Statement 3. The method of statement 2, wherein the method further comprises storing at least one of the proof commitment value and the first author data in the proof database in association with the file commitment value.

[0229] Statement 4. The method of statement 1 or statement 2, wherein the folder is not a component of the file proof platform.

[0230] Statement 5. The method of statement 4, wherein the folder is stored on a remote file management system.

[0231] Statement 6. The method of statement 4, wherein the folder is stored on a user device.

[0232] Statement 7. The method of any of statements 4 to 6, wherein the file proof platform is configured to execute the scan at predefined time intervals.

[0233] Statement 8. The method of any of statements 4 to 6, wherein the file proof platform is configured to execute the scan in response to receiving a user input for initiating a scan.

[0234] Statement 9. The method of statement 5, wherein the method further comprises receiving a modification notification from the remote file management system indicating a modification to the folder; wherein the file proof platform is configured to execute the scan in response to receiving the modification notification.

[0235] Statement 10. The method of any preceding statement, wherein the electronic file is not stored at the file proof platform in persistent storage. Statement 11. The method of statement 2, wherein obtaining the first author data comprises obtaining file metadata of the electronic file, wherein the first author data is derivable from the file metadata.

[0236] Statement 12. The method of statement 11 when dependent on statement 2, wherein the electronic file is the modified electronic file, wherein the first author data is associated with modifications of the modified electronic file.

[0237] Statement 13. The method of statement 2, wherein obtaining the first author data comprises receiving an authorisation of the first author from a trusted entity.

[0238] Statement 14. The method statement 2, wherein the proof commitment value is generated using the file commitment value and an author commitment value of the first author data.

[0239] Statement 15. The method of statement 2, wherein the file commitment value and the proof commitment value are hash values.

[0240] Statement 16. The method of any preceding statement, wherein the method further comprises obtaining a proof transaction identifier of the proof blockchain transaction, wherein the link comprises the proof transaction identifier.

[0241] Statement 17. The method of statement 2, wherein the method further comprises: obtaining second author data identifying a second author of the electronic file; wherein the proof commitment value is further based on the second author identifier.

[0242] Statement 18. The method of statement 2, wherein the method further comprises obtaining a time associated with the electronic file; wherein the proof commitment value is further based on the time. Statement 19. A computer-implemented method of verifying an electronic file at a file proof platform, the method comprising: receiving a candidate electronic file; generating a candidate file commitment value based on the candidate electronic file; obtaining, from a proof database of the file proof platform, a link to a proof blockchain transaction stored in association with the candidate file commitment value, wherein the proof blockchain transaction comprises a proof commitment value, wherein the proof commitment value is derivable from a target electronic file and first author data of a first author of the target electronic file; obtaining, from the blockchain using the link, a target file commitment value, wherein the target file commitment value is derivable from the target electronic file; generating a candidate proof commitment value based on the candidate electronic file and candidate first author data of a candidate first author of the candidate electronic file; and comparing the candidate proof commitment value and the target proof commitment value, wherein the candidate electronic file is verified if the candidate proof commitment value is equal to the target proof commitment value.

[0243] Statement 20. The method of statement 19, wherein the method further comprises receiving the candidate first author data via a user interface of the file proof platform.

[0244] Statement 21. The method of statement 19, wherein the method further comprises obtaining file metadata of the candidate electronic file, wherein the file metadata comprises an indication of the candidate first author data.

[0245] Statement 22. The method of statement 19, wherein the method further comprises obtaining the candidate first author data stored in association with the candidate file commitment value from the proof database of the file proof platform.

[0246] Statement 23. The method of any of statements 19 to 22, wherein obtaining the candidate electronic file comprises: receiving a user input at a user interface of the file proof platform, wherein the user input causes the candidate electronic file to be uploaded to the file proof platform.

[0247] Statement 24. The method of any preceding statement, wherein the electronic file is not stored at the file proof platform in persistent storage.

[0248] Statement 25. The method of any of statements 19 to 24, wherein the candidate proof commitment value is generated using the candidate file commitment value and a candidate author commitment value of the candidate first author data.

[0249] Statement 26. The method of any of statements 19 to 25, wherein the target and candidate commitment values and the target and candidate proof commitment values are hash values.

[0250] Statement 27. The method of any of statements 19 to 26, wherein the method further comprises obtaining a candidate time associated with the candidate electronic file; wherein the candidate proof commitment value is further based on the time.

[0251] Statement 28. A computer-implemented file proof platform, wherein the file proof platform comprises: an autoscan module configured to access a folder, executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder, and obtain the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; and a proof module configured to generate a commitment value based on the electronic file, generate a proof blockchain transaction comprising the commitment value, and cause the proof blockchain transaction to be made available to one or more nodes of a blockchain.

[0252] Statement 29. A computer-implemented file proof platform, wherein the file proof platform comprises: a proof database; and a verification module configured to: receive a candidate electronic file; generate a candidate file commitment value based on the candidate electronic file; obtain, from the proof database, a link to a proof blockchain transaction stored in association with the candidate file commitment value, wherein the proof blockchain transaction comprises a proof commitment value, wherein the proof commitment value is derivable from a target electronic file and first author data of a first author of the target electronic file; obtain, from the blockchain using the link, a target file commitment value, wherein the target file commitment value is derivable from the target electronic file; generate a candidate proof commitment value based on the candidate electronic file and candidate first author data of a candidate first author of the candidate electronic file; and compare the candidate proof commitment value and the target proof commitment value, wherein the candidate electronic file is verified if the candidate proof commitment value is equal to the target proof commitment value.

[0253] Statement 30. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 28.

[0254] Statement 31. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 28.

Claims

1. CLAIMS1. A computer-implemented method for recording an electronic file, wherein the method is implemented by a file proof platform, comprising: accessing a folder; executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder; obtaining the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; generating a commitment value based on the electronic file; generating a proof blockchain transaction comprising the commitment value; and causing the proof blockchain transaction to be made available to one or more nodes of a blockchain.

2. The method of claim 1, wherein the commitment value is a proof commitment value based on the electronic file, wherein the method further comprises: generating a file commitment value based on the electronic file; obtaining first author data identifying a first author of the electronic file, wherein the proof commitment value is generated based on the electronic file and the first author data; and storing, in a proof database of the file proof platform, the file commitment value in association with a link to the proof blockchain transaction stored on the blockchain.

3. The method of claim 2, wherein the method further comprises storing at least one of the proof commitment value and the first author data in the proof database in association with the file commitment value.

4. The method of any preceding claim, wherein the file proof platform is configured to execute the scan at predefined time intervals.

5. The method of any of claims 1 to 3, wherein the file proof platform is configured to execute the scan in response to receiving a user input for initiating a scan.

6. The method of claims 1 to 3, wherein the method further comprises receiving a modification notification from the folder indicating a modification to the folder; wherein the file proof platform is configured to execute the scan in response to receiving the modification notification.

7. The method of claim 2, wherein obtaining the first author data comprises obtaining file metadata of the electronic file, wherein the first author data is derivable from the file metadata.

8. The method of claim 2, wherein obtaining the first author data comprises receiving an authorisation of the first author from a trusted entity.

9. A computer-implemented method of verifying an electronic file at a file proof platform, the method comprising: receiving a candidate electronic file; generating a candidate file commitment value based on the candidate electronic file; obtaining, from a proof database of the file proof platform, a link to a proof blockchain transaction stored in association with the candidate file commitment value, wherein the proof blockchain transaction comprises a proof commitment value, wherein the proof commitment value is derivable from a target electronic file and first author data of a first author of the target electronic file; obtaining, from the blockchain using the link, a target file commitment value, wherein the target file commitment value is derivable from the target electronic file; generating a candidate proof commitment value based on the candidate electronic file and candidate first author data of a candidate first author of the candidate electronic file; and comparing the candidate proof commitment value and the target proof commitment value, wherein the candidate electronic file is verified if the candidate proof commitment value is equal to the target proof commitment value.5410. The method of claim 9, wherein the method further comprises receiving the candidate first author data via a user interface of the file proof platform.

11. The method of claim 9, wherein the method further comprises obtaining file metadata of the candidate electronic file, wherein the file metadata comprises an indication of the candidate first author data.

12. The method of claim 9, wherein the method further comprises obtaining the candidate first author data stored in association with the candidate file commitment value from the proof database of the file proof platform.

13. A computer-implemented file proof platform, wherein the file proof platform comprises: an autoscan module configured to access a folder, executing a scan of the folder to identify a new or modified electronic file stored in the folder relative to a previous scan of the folder, and obtain the new or modified electronic file from the folder, wherein the new or modified electronic file is the electronic file; and a proof module configured to generate a commitment value based on the electronic file, generate a proof blockchain transaction comprising the commitment value, and cause the proof blockchain transaction to be made available to one or more nodes of a blockchain.

14. A computer-implemented file proof platform, wherein the file proof platform comprises: a proof database; and a verification module configured to: receive a candidate electronic file; generate a candidate file commitment value based on the candidate electronic file; obtain, from the proof database, a link to a proof blockchain transaction stored in association with the candidate file commitment value, wherein the proof blockchain transaction comprises a proof commitment value, wherein the proofcommitment value is derivable from a target electronic file and first author data of a first author of the target electronic file; obtain, from the blockchain using the link, a target file commitment value, wherein the target file commitment value is derivable from the target electronic file; generate a candidate proof commitment value based on the candidate electronic file and candidate first author data of a candidate first author of the candidate electronic file; and compare the candidate proof commitment value and the target proof commitment value, wherein the candidate electronic file is verified if the candidate proof commitment value is equal to the target proof commitment value.

15. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 12.

Images