Patent Description:
A recipient apparatus of a file, and/or a creator of the file may, in some examples, wish to link further data with a received file. For example such further data may indicate that the file has been processed or transmitted to a further recipient. Providing such data in a way that the data is linked to the correct file and is not, for example, used against a different file (through error or malicious intent) may be beneficial.

<CIT> discloses systems and methods for facilitating the verification of the integrity of digital content. Embodiments of the disclosed systems and methods may provide mechanisms for generating a secure and unambiguous record of the creation and/or modification of digital content and/or other media associated with events. Further embodiments may provide for a ledger configured to capture a record of creation and/or modification actions performed in connection with digital content. <CIT> discloses A system and process for securing digital media file content for persistence. Aspects of the system and process protect content from being altered or embedded with malicious code during distribution through a network. A digital media file is embedded with a hash function. In some embodiments, successive frames may be hashed. A copy of the hash function may be retrieved from a trusted source which may be located within a distributed ledger network. Copies of the digital media file and hash function are checked at network member nodes to verify authenticity of the content. During verification, the media file may be checked to verify if successive frames (for example <NUM> or more) comply with the trusted hash function. Metadata for authenticated media files may provide trusted information about the original media file. discloses a novel watermarking based Multimedia Blockchain framework that can address media tampering issues. The unique watermark information contains two pieces of information: a) a cryptographic hash that contains transaction histories (blockchain transactions log) and b) an image hash that preserves retrievable original media content.

The term "computer" may be understood to encompass a single computing entity/device or a distributed computer system comprising a plurality of computing entities/devices which may be located at substantially the same geographic location, or at substantially different geographical locations. One or more computing entities/devices in a distributed system may be located in the "computing cloud".

Embodiments will now be described by way of example only, with reference to the accompanying figures, in which:.

Examples disclosed herein may provide means for secure verification of a sender of an electronic file. Examples disclosed herein may provide means for secure addition or linking of further data to a file in a way which is immutably linked to the true data provider.

For example, apparatus as disclosed herein may allow verification of an origin of a transmitted file, by: obtaining a hash of a file to be transmitted to a second apparatus and an indication of a creator of the hashed file; retrieving an identifier associated with the file creator; storing the hash of the file, associated with the identifier of the file creator, in an immutable ledger; obtaining the hash of the file from a second apparatus; verifying that the hash of the file is stored in the immutable ledger; retrieving one or more assertions recorded in the immutable ledger and associated with the hashed file from the immutable ledger; retrieving the stored associated identifier of the file creator using the hash of the file; and transmitting, to the second apparatus: a confirmation that the file is from the file creator; and at least one of the one or more assertions associated with the hashed file.

Such apparatus may, thereby, provide proof of the provenance of a file (i.e. who created the file), the existence of the file (i.e. that it existed at the point in time it was recorded in an immutable ledger), integrity of the file (i.e. that its content wasn't tampered by any rogue actor), or one or more assertions recorded against the file by the creator, recipient, or authorised third party. In some examples, such apparatus may be able to provide proof of the integrity of the file and creator without knowing the content of a file. For example, the file may contain confidential information.

The terms "file", "document", "electronic document" may be used interchangeably, unless the context suggests otherwise, to mean an electronic data item. The terms "ledger apparatus" and "apparatus" may also be used interchangeably. The terms "recipient apparatus" and "second apparatus" may also be used interchangeably.

<FIG> shows an apparatus <NUM> according to an embodiment. The apparatus <NUM> may be the apparatus for verifying an original of a transmitted file, a computing apparatus operated by the file sender, a second apparatus operated by the file recipient, or may form a part of any of the apparatus for verifying an original of a transmitted file, a file sender apparatus, or a file recipient second apparatus. Any of the apparatus for verifying an original of a transmitted file, a file sender apparatus, or a file recipient second apparatus, may comprise a plurality of apparatus <NUM> as illustrated.

The apparatus <NUM> may comprise one or more processing units <NUM> (one is shown in <FIG>). Each processing unit comprises a memory <NUM> and processor <NUM>. The apparatus <NUM> may comprise one or more processors <NUM> arranged to operably execute computer software/computer program code thereon, where the computer software/computer program code is stored in a computer-readable medium accessible to the one or more processors <NUM>. The computer-readable medium may be one or more memory devices, where the memory may also store data for use by the software/program code (e.g. memory <NUM> or a separate memory store external to the apparatus <NUM>). It will be appreciated that the memory <NUM> in which, for example, a creator ID, file hash, timestamp of file storage in an immutable ledger, creator assertions and/or recipient assertions may be stored, may in some examples be part of a physically distinct computer system than the one or more computers implementing the processing, such as creating a file hash, transmitting requests to the immutable ledger, receiving information from the immutable ledger or from a recipient second apparatus.

The apparatus <NUM> can receive data (e.g. a file or file hash from a sender, a file or file hash from a second apparatus, data from the immutable ledger) as input <NUM> and can provide data (e.g. a file hash to the immutable ledger, a query to the immutable ledger, a confirmation of file origin and/or assertions to the second apparatus) as output <NUM>.

It will be appreciated that the one or more processors <NUM> do not necessarily need to be formed as part of the same physical server apparatus <NUM> and that at least a portion of the processors <NUM> may form a virtual machine implementing the system <NUM> i.e. as a cloud computer. Embodiments may be implemented by a plurality of distributed computers <NUM>, with each of the computers <NUM> performing one or more processing steps.

<FIG> illustrates a file <NUM> which may be considered an electronic file or electronic document. The file <NUM> may be, for example, a Portable File Format A, PDF/A, file, a Microsoft Office (RTM) file or an Apache (RTM) OpenOffice file. The file <NUM> comprises a human-readable file portion <NUM> (such as a word processing document) and a machine-readable file portion <NUM> (such as a data payload). The machine-readable portion may comprise embedded JavaScript Object Notation, JSON, content, and/or embedded eXtensible Mark-Up Language, XML, content, for example. A sending apparatus may wish to send the file <NUM> to a second receiving apparatus. The second receiving apparatus may wish to check that the origin of the file <NUM> is genuine (i.e. the sender is who they appear to be from the file). As part of example processes described herein providing ways to verify the origins of a file <NUM>, an apparatus such as apparatus <NUM> may receive, or may create, a hash of the file <NUM> transmitted to the second receiving apparatus. The hash of the file <NUM> may be a hash of the machine-readable portion <NUM> of the file <NUM>; a hash of the human-readable portion <NUM> of the file <NUM>; or a hash of both the machine-readable portion <NUM> and the human-readable portion <NUM> of the file <NUM>. The hash may be calculated over a canonicalized representation of at least a portion of the file.

<FIG> shows an example system <NUM> comprising a sending apparatus <NUM> (e.g. an application or domain service), ledger apparatus <NUM>, an immutable ledger <NUM>, and a receiving apparatus <NUM> (which may be termed a second apparatus <NUM>).

The ledger apparatus <NUM> is configured to verify an origin of a transmitted file. The ledger apparatus <NUM> first obtains a hash of a file <NUM> to be transmitted to a second apparatus <NUM>, and obtains and an indication of a creator <NUM> of the hashed file. In this example, the apparatus <NUM> obtains the hash of the file <NUM> to be transmitted to the second apparatus <NUM> by receiving the hash of the file from the sending apparatus <NUM> (i.e. the sending apparatus <NUM> has hashed the file).

The ledger apparatus <NUM> retrieves an identifier <NUM> ("Creator ID") associated with the file creator. The identifier associated with the file creator may be retrieved from, for example, storage at the apparatus <NUM>, accessible by the apparatus <NUM>, or at cloud storage. The hash of the file <NUM> may be cryptographically associated with the identifier of the file creator <NUM>. The ledger apparatus <NUM> then stores 216a the hash of the file <NUM> associated with the identifier of the file creator <NUM>, in an immutable ledger <NUM>. The immutable ledger <NUM> may be based on a blockchain in some examples. For added security the stored hashed file may be cryptographically signed by the apparatus <NUM>, for example with a generic X. <NUM> signature, indicating a certificate of the apparatus <NUM> as a verified source. <NUM> is a standard defining the format of a public key certificate, and may be used as an electronic signature.

In examples where the file comprises a canonicalized JSON document potion, the JSON document portion may be rendered from another representation "on the fly" (for instance from data stored in a relational database). Thus JSON may provide a more flexible file type than other files which comprise a more permanent structure. To help ensure the integrity of a file comprising a PDF portion with an embedded JSON portion (that is, to help ensure that the human readable part <NUM> of a PDF file says the same as the machine readable JSON part <NUM> of the file), the hash of the non-JSON part of the file may be included in the JSON file. Another approach may be to store two hashes in the immutable ledger <NUM>. In examples where a "double" hash (or double digest) is recorded in the immutable ledger <NUM>, a first hash may be calculated over the machine readable portion (e.g. the canonicalized JSON portion) of the file and thereby create a fingerprint of the file, and a second hash may be produced by the immutable ledger <NUM>, thereby making the file fingerprint immutable and cryptographically verifiable (i.e. the fingerprint rather than the document behind the fingerprint). Doing so may increase the security of the file (i.e. reduce the possibility of tampering with the file).

In some examples, a hash of a machine-readable part of the file is recorded in the immutable ledger <NUM>, possibly with additional information such as who created it and/or the file type. The file itself (e.g. including a human-readable portion) or details of the content of the file may not necessarily be recorded in the immutable ledger <NUM> in some examples. By recording the hash in the immutable ledger <NUM>, a given file can be verified by recalculating the hash and checking the immutable ledger for a record with a corresponding hash. The file content need never be exposed to the ledger apparatus, because the recipient/second device <NUM> can do the hash calculation prior to sending the hash to the ledger apparatus <NUM> to request verification of the identity of the file sender.

The ledger apparatus <NUM> may issue a unique member ID/creator ID <NUM> for each network member (i.e. for the sending apparatus <NUM> and the receiving apparatus <NUM>). The member ID <NUM> issued by the ledger apparatus <NUM> may be immutable. Thus, the ledger apparatus <NUM> may guarantee the 'parentage' of a file by using the immutable ID <NUM> for the file sender.

The sending apparatus <NUM> may then send the file <NUM>, of which the hash as transmitted <NUM> to the ledger apparatus <NUM>, to a second receiving apparatus <NUM>. The receiving apparatus <NUM> may wish to know that the file purporting to be from the sender <NUM> is actually from the sender <NUM>, and if not, for example, a fraudulent document or a file from a spoofed address.

The ledger apparatus <NUM> obtains the hash of the file <NUM> from the second receiving apparatus <NUM>, in this example by receiving the hash of the file from the second apparatus (i.e. the second apparatus <NUM> has hashed the file prior to sending it to the apparatus <NUM>). The apparatus <NUM> may be configured to obtain the hash of the file <NUM> from the second apparatus <NUM> in response to a request from the second apparatus <NUM> (not shown) following receipt of the file <NUM> by the second apparatus <NUM> from the sending apparatus <NUM>.

The receiving apparatus <NUM> may transmit a request the ledger apparatus <NUM> to verify that the received file is actually from the sender indicated a the sender of the file. The ledger apparatus <NUM> verifies that the hash of the file <NUM> is stored in the immutable ledger <NUM>, for example by the apparatus <NUM> querying <NUM> the immutable ledger <NUM> and, following the immutable ledger <NUM> identifying that the hash <NUM> of the file is stored at the immutable ledger <NUM>, receiving an indication <NUM> from the immutable ledger <NUM> that the hash <NUM> is recorded thereon. By verifying that the hash of the file <NUM>, which is associated with the creator indicator <NUM>, is stored in the immutable ledger <NUM>, matches the hash of the file <NUM> obtained from the receiving apparatus <NUM>, it can be said that the file received <NUM> at the receiving apparatus <NUM> is indeed from the creator having the creator ID <NUM>. Because the storage of the file hash 216a at the immutable ledger <NUM> cannot be tampered with or overwritten by virtue of the immutability (non-changing, or fixed, nature) of the data storage in the immutable ledger, a secure way of proving the creator origin of a file is provided.

The ledger apparatus <NUM> then retrieves one or more assertions <NUM> recorded in the immutable ledger <NUM> and associated with the hashed file, from the immutable ledger <NUM>. At least one of the one or more assertions <NUM> may be cryptographically associated with the with the hashed file. For example, the apparatus <NUM> may query <NUM> the immutable ledger <NUM> and, following the immutable ledger <NUM> identifying that one or more assertions <NUM> are stored at the immutable ledger <NUM>, receiving an indication <NUM> from the immutable ledger <NUM> that the assertion(s) <NUM> are recorded thereon. The one or more assertions may indicate, for example, that: the file has been received at the second computer; the file has been transmitted from the second computer to a third computer; a note has been recorded associated with the file; content of a note recorded associated with the file; a change of status related to the file (for example, that ownership of the file has been transferred, that an action indicated by the file has been carried out, or another material change has taken place); or a cross-reference to another file recorded in the immutable ledger.

The ledger apparatus <NUM> retrieves the stored associated identifier <NUM> of the file creator using the hash of the file. The ledger apparatus <NUM> then transmits, to the second apparatus <NUM>, a confirmation that the file is from the file creator <NUM>, and at least one of the one or more assertions <NUM> associated with the hashed file. In some examples, the apparatus <NUM> may transmit, to the second apparatus <NUM>, profile information about the file creator.

The data recorded by the ledger apparatus <NUM> may be according to a 'need to know' principle. For example, the content of a file may not necessarily be recorded at the ledger apparatus <NUM>, and only the hash may be recorded (only the hash of the file may ever be received by the ledger apparatus <NUM> if both the sender apparatus <NUM> initially sends a hashed file, and the recipient apparatus <NUM> sends the hashed file as well. This may reduce the transmission (and therefore the risk of unauthorised interception) of sensitive file data. The ledger apparatus <NUM> may not record to whom a file was sent in some examples. The recipient apparatus may record that they are the recipient through storage of an assertion at the immutable ledger <NUM>.

Assertions may be used to allow the assertion recording apparatus (e.g. sending apparatus <NUM> or receiving apparatus <NUM>) to control how much additional information to disclose in association with the file (or file hash). Third party apparatus may also, in some examples, be permitted to record assertions against a file or file hash. The third party may be authorised to record assertions if the file creator indicates the third party is permitted to do so. Such assertions may be available to access by any apparatus having a valid copy of the file (i.e. they are permitted to possess or access the file).

<FIG> shows an example system <NUM> comprising a sending apparatus <NUM>, ledger apparatus <NUM>, an immutable ledger <NUM>, and a receiving apparatus <NUM>. Features in common with the system of <FIG> will not be discussed in detail again. One or more of the features of <FIG> additional to those of <FIG> may be included in an example system <NUM> in isolation without requiring the one or more other features of <FIG> not included in <FIG>.

The ledger apparatus <NUM> is configured to verify an origin of a transmitted file. The ledger apparatus <NUM> first obtains a hash of a file <NUM> to be transmitted to a second apparatus <NUM>. In this example, the apparatus <NUM> obtains the hash of the file <NUM> to be transmitted to the second apparatus <NUM> by receiving the file <NUM> to be transmitted from the sending apparatus <NUM>, and hashing the file <NUM> to obtain the hash of the file. The ledger apparatus <NUM> also obtains an indication of a creator ("creator identifier") <NUM> of the file, and obtains one or more file creator assertions <NUM> associated with the file creator, from the sender apparatus <NUM>.

The ledger apparatus <NUM> then stores 216b the hash of the file <NUM> associated with the identifier <NUM> of the file creator <NUM>, the creator indication/ID <NUM>, one or more creator assertions <NUM>, and a timestamp indicating when the file hash <NUM> was originally recorded in the immutable ledger <NUM>, at the immutable ledger <NUM>. In other examples the apparatus may store only one or more of the one or more creator assertions <NUM>, and the timestamp indicating when the file hash <NUM> was originally recorded in the immutable ledger <NUM> at the immutable ledger <NUM>.

Following transmission of a file (i.e. of which the hash is stored at the immutable ledger 216b) to the receiving apparatus <NUM> (not shown here), the receiving apparatus <NUM> may wish to know that the file purporting to be from the sender <NUM> is actually from the sender <NUM>.

In this example, the receiving apparatus <NUM> transmits the received file <NUM> to the ledger apparatus <NUM> for verification. The ledger apparatus <NUM> obtains the hash of the file <NUM> from the second receiving apparatus <NUM> (in this example by receiving the file <NUM> from the second apparatus <NUM>, and hashing the file <NUM> to obtain the hash of the file).

The ledger apparatus <NUM> verifies that the hash of the file <NUM> is stored in the immutable ledger <NUM> as described in relation to <FIG>. The ledger apparatus <NUM> may also then retrieves one or more assertions <NUM> recorded in the immutable ledger <NUM> and associated with the hashed file, for example by querying <NUM> the immutable ledger <NUM> and, following the immutable ledger <NUM> identifying that one or more assertions <NUM> are stored at the immutable ledger <NUM>, receiving an indication <NUM> from the immutable ledger <NUM> that the assertion(s) <NUM> are recorded thereon. These assertion(s) <NUM> may be recorded by the receiving apparatus <NUM>, or by a third party, against the hashed file <NUM> at the immutable ledger <NUM>, for example indicating that an action relating to the hashed file has been performed (and therefore does not need to be performed again), such as a software update.

The apparatus <NUM> in this example is also configured to retrieve a timestamp <NUM> indicating when the file hash <NUM> was originally recorded 216b in the immutable ledger <NUM> from the immutable ledger <NUM>. For example, the apparatus <NUM> may query <NUM> the immutable ledger <NUM> for a timestamp <NUM> indicating when the hash file was stored 216b at the immutable ledger <NUM>. Following the immutable ledger <NUM> identifying that a timestamp <NUM> is stored at the immutable ledger <NUM>, the apparatus <NUM> may receive the timestamp <NUM> from the immutable ledger <NUM>. The apparatus <NUM> may later transmit <NUM> the retrieved timestamp <NUM> to the second apparatus <NUM>.

The apparatus <NUM> in this example is also configured to retrieve one or more assertions <NUM> associated with the file creator which are recorded in the immutable ledger <NUM>, from the immutable ledger <NUM>. For example, the apparatus <NUM> may query <NUM> the immutable ledger <NUM> for any creator assertions <NUM> stored at the immutable ledger <NUM> associated with the creator of the hashed file <NUM>. Following the immutable ledger <NUM> identifying that one or more creator assertions <NUM> are stored at the immutable ledger <NUM>, the apparatus <NUM> may receive at least one of the one or more creator assertions <NUM> from the immutable ledger <NUM>. The apparatus <NUM> may later transmit <NUM> an indication of the one or more assertions <NUM> associated with the file creator to the second apparatus <NUM>. The one or more assertions <NUM> associated with the file creator may indicate a security level of the file creator, for example, so the receiving device <NUM> is provided with an indication of how safe the file from the creator is to open and/or process (that is, how trustworthy the sender of the file is). The creator assertions <NUM> may be amended or added to in the immutable ledger <NUM> as additional assertion data becomes available about the file creator.

The ledger apparatus <NUM> facilitates the transmission of files in a way which allow the recipient to verify the sender. Since assurances may be recorded against the file over time, and such assurances are recorded in the immutable ledger, a security or "trust" profile may be formed of the sender which may change over time. For example, assurances indicating positive or safe actions taken by the sender may act to increase the security profile of the sender, and conversely, assurances indicating unsafe or unexpected/untrustworthy actions taken by the sender may act to decrease the security profile of the sender. Thus the security profile of the sender may dynamically vary as assurances are recorded against files transmitted by that sender and/or by assurances recorded against the sender. In this way, assertions may be considered a mechanism by which computing entities can "comment" on something (e.g. a file, sender, third party).

Alongside the provision of a timestamp <NUM> and creator assertion data <NUM>, the ledger apparatus <NUM> in this example also provide a confirmation that the file is from the file creator <NUM>, and at least one of the one or more assertions <NUM> (e.g. recorded by the recipient or a third party) associated with the hashed file. These provisions to the receiving apparatus <NUM> are performed after the ledger apparatus <NUM> has retrieved the stored associated identifier <NUM> of the file creator using the hash of the file <NUM>.

<FIG> shows an example system <NUM> and illustrates that a sending apparatus <NUM> and receiving apparatus <NUM> may be paired. Paired apparatuses <NUM>, <NUM> may permit file transmission directly from one to the other apparatus <NUM>, <NUM> through a shared software platform or application. The shared software or platform may be associated with the ledger apparatus and may be registered as a verified or secure platform through which files may be transmitted and verified using the ledger apparatus <NUM>. Apparatuses which are not paired may still be used, but in such cases, files may be transmitted through email or filesharing, for example.

In <FIG>, the apparatus <NUM> is configured to determine that the second apparatus <NUM> has an associated identifier <NUM> stored at the apparatus <NUM>. The associated identifier <NUM> may be termed a receiving apparatus ID <NUM>, or apparatus ID <NUM>. The apparatus <NUM> provides a pairing invitation <NUM> to the file creator (e.g. at the sending apparatus <NUM>) to create a pairing link with the second apparatus <NUM>. If the sending apparatus <NUM>/creator approves the pairing request <NUM>, then a pairing approval message / invitation approval message <NUM> is received at the apparatus <NUM> from the sending apparatus <NUM>/creator. That is, the apparatus <NUM> receives an approval indication <NUM> from the file creator <NUM> to create the pairing link with the second apparatus <NUM>. The apparatus <NUM> then can create the pairing link <NUM> between the file creator <NUM> and the second apparatus <NUM>. The pairing link <NUM> is configured to permit file transmission <NUM> between the file creator <NUM> and the second receiver apparatus <NUM>.

That is, pairing allows two parties to directly exchange files/documents without using a public messaging service like email. Pairing may be initiated by the recipient of a document for a given sender identity. First, it may be determined whether the sender has a recorded sender ID at the apparatus <NUM>. Then the pairing request may be confirmed with the sender. The pairing request can itself be a file recorded on the ledger apparatus <NUM>, with the confirmation stored as a document assertion, for example. In some examples, a sender may be required to provide a recipient reference, and the recipient requesting pairing may be required to provide a sender reference.

Once the pairing is completed, the sender may directly transmit files through the pairing connection instead of using a public messaging service. The recipient knows where the document came from, and how it correlates internally, because the sender and the transmission connection are formed through the ledger apparatus. While individual file (file hashes) may still be recorded in the immutable ledger, it is no longer necessary for the recipient apparatus to verify every single document received through the pairing connection. Both parties in the pairing connection may be able to revoke a pairing arrangement. It may also be possible to revoke all paring agreements for a given identity at once.

<FIG> illustrates an example system <NUM> comprising a sending apparatus <NUM>, ledger apparatus <NUM>, an immutable ledger <NUM>, and a receiving apparatus <NUM> (which may be termed a second apparatus <NUM>). Features in common with <FIG> and <FIG> will not be discussed again in detail here.

<FIG> illustrates the sender <NUM> generating an eDocument file <NUM> to be transmitted and sending it as an email <NUM> to a recipient <NUM>. An eDocument is an example type of file illustrated in <FIG> and <FIG>, but it could be any type of file which is transmitted. The sender <NUM> in this example also hashes <NUM> the eDocument <NUM> before instructing the apparatus <NUM> to record the eDocument hash <NUM>, which is linked to the creator ID of the eDocument creator.

Following transmission 216a and immutable recordal <NUM> of the hash (linked/chained to the creator) 216a in the immutable ledger <NUM>, the immutable ledger <NUM> provides a confirmation <NUM> to the apparatus <NUM> that the hash has been successfully recorded in the immutable ledger <NUM>. The apparatus <NUM> in this example then confirms <NUM> the hash recordal <NUM> in the immutable ledger <NUM> to the sender apparatus <NUM>.

Following transmission <NUM> of the eDocument to the recipient apparatus <NUM>, the receiver wishes to check <NUM> the originating sender <NUM> to check they are who they say they are. This is performed as described in the above example of <FIG>. The apparatus <NUM>, once the sender of the eDocument has been verified using the supplied hash <NUM>, retrieves the details of the sender from the immutable ledger <NUM> and provides a verification to the receiving apparatus that the sender of the eDocument is who they purport to be. In this example, the verification comprises key details such as the time of eDocument creation <NUM>, the creator identity <NUM> (or an indicator that the creator identity is as expected), and assertions <NUM>, <NUM> recorded against the eDocument in the immutable ledger (creator assertions <NUM>, recipient assertions <NUM> and/or third party assertions).

<FIG> illustrates an example system <NUM> comprising a sending apparatus <NUM>, ledger apparatus <NUM>, an immutable ledger <NUM>, and a receiving apparatus <NUM> (which may be termed a second apparatus <NUM>). Features in common with <FIG> (and <FIG> and <FIG>) will not be discussed again in detail here.

Compared with <FIG>, the system of <FIG> illustrates the sender <NUM> generating an eDocument file <NUM> to be imported directly into a recipient's software <NUM>. This may occur if the sender <NUM> and receiver <NUM> are previously paired as discussed in relation to <FIG>.

Following export <NUM> of the eDocument from the sender's software and import to the recipient apparatus' software <NUM>, the receiver wishes to check <NUM> the originating sender <NUM> to check they are who they say they are. This is performed as described in the above examples of <FIG>, <FIG> and <FIG>, and in addition, <FIG> illustrates the making <NUM> and adding <NUM> of an assertion by the recipient apparatus <NUM>. Following receipt of the confirmation that the identity of the eDocument sender <NUM> is as expected, the recipient apparatus <NUM> makes as assertion <NUM> against the eDocument. For example, the received file may be a software update, and the assertion may be a note that the received file software update has been implemented at the receiver apparatus. As another example, the received file may be a communication from a third party requesting action, and the assertion may be that the action has been taken. Such assertions may be made to verify as action has been taken, to help avoid unnecessary repeat of the same action being taken.

Once the assertion has been made <NUM>, it is added <NUM> to the document by recording the assertion, linked to the document, at the apparatus <NUM>. The apparatus <NUM> the transmits the document assertion <NUM> to the immutable ledger <NUM> for recordal, which is then recorded <NUM> by the immutable ledger <NUM> against the document. Confirmation of the recordal <NUM> may then be sent from the immutable ledger <NUM> to the apparatus <NUM>, and in turn the apparatus <NUM> may transmit a notification <NUM> of a new assertion being recorded against the document to the document sender <NUM>.

<FIG> shows a method <NUM> according to an embodiment. The method <NUM> comprises: obtaining a hash of a file to be transmitted to a second apparatus and an indication of a creator of the hashed file <NUM>; retrieving an identifier associated with the file creator <NUM>; storing the hash of the file, associated with the identifier of the file creator, in an immutable ledger <NUM>; obtaining the hash of the file from a second apparatus <NUM>; verifying that the hash of the file is stored in the immutable ledger <NUM>; retrieving one or more assertions recorded in the immutable ledger and associated with the hashed file from the immutable ledger <NUM>; retrieving the stored associated identifier of the file creator using the hash of the file <NUM>; and transmitting <NUM>, to the second apparatus: a confirmation that the file is from the file creator; and at least one of the one or more assertions associated with the hashed file. The method may be performed by a computer readable medium comprising computer program code / software which, when executed, is configured to perform the method. Such computer program code / software may be executed using an application program operating on a computing apparatus.

It will be appreciated that embodiments of the present invention can be realised in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage such as, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs that, when executed, implement embodiments of the present invention. Accordingly, embodiments provide a program comprising code for implementing a system or method as claimed in any preceding claim and a machine readable storage storing such a program. Still further, embodiments of the present invention may be conveyed electronically via any medium such as a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Claim 1:
An apparatus (<NUM>) for verifying an origin of a transmitted file, the apparatus configured to:
obtain a hash of a file (<NUM>) to be transmitted to a second apparatus and an indication of a file creator of the file (<NUM>) from a sender apparatus;
retrieve an identifier (<NUM>) associated with the file creator from storage at the apparatus or cloud storage;
store the hash of the file associated with the identifier of the file creator, and the retrieved identifier (216a), and one or more assertions provided by an authorised third party, in an immutable ledger (<NUM>);
obtain the hash of the file (<NUM>) from a second apparatus (<NUM>);
verify that the hash of the file is stored (<NUM>) in the immutable ledger;
retrieve one or more assertions (<NUM>) recorded in the immutable ledger and cryptographically associated with the file from the immutable ledger, the one or more assertions comprising the one or more assertions provided by the authorised third party;
retrieve the stored associated identifier of the file creator (<NUM>) using the hash of the file; and
transmit, to the second apparatus:
a confirmation that the file is from the file creator (<NUM>); and
at least one of the one or more assertions cryptographically associated with the file (<NUM>).