Technical Field

The present invention relates to methods for storing data in a verifiable manner and to methods for data verification.

Background

Data may be tampered with or otherwise altered by malicious parties. This can render the data unreliable or untrustworthy. It is therefore desirable to store data securely. It is further desirable to be able to verify data, to identify whether the data has been changed or otherwise interfered with, for example by a malicious party.

Brief Description of the Drawings

Features of examples described herein will become apparent from the following description, given by way of example only, which is made with reference to the accompanying drawings.

Figure 1 is a flow diagram illustrating a method of generating an electronic document according to examples;

Figures 2a and 2b show schematically the generation of an electronic document according to examples;

Figure 3 shows schematically components of an example system for use with the methods described herein;

Figure 4 shows schematically internal components of a computing device according to examples;

Figure 5 is a flow diagram illustrating a verification method according to examples;

Figure 6 is a flow diagram illustrating features of a verification method according to further examples;

Figure 7 shows schematically components of a further example system for use with the methods described herein;

Figure 8 is a flow diagram illustrating features of a verification method according to yet further examples. Detailed Description

Details of systems and methods according to examples will become apparent from the following description, with reference to the Figures. In this description, for the purpose of explanation, numerous specific details of certain examples are set forth. Reference in the specification to“an example” or similar language means that a particular feature, structure, or characteristic described in connection with the example is included in at least that one example, but not necessarily in other examples. It should further be noted that certain examples are described schematically with certain features omitted and/or necessarily simplified for ease of explanation and understanding of the concepts underlying the examples.

Methods described herein may be used in the storage or verification of user data associated with a user. User data is for example personal data relating to an individual, such as employment data (e.g. pay information, appraisal records, employer information, or dates of employment); financial data (e.g. bank statements, records of transactions the individual has participated in or assets the individual has owned); educational data (e.g. educational or attainment certificates, grade transcripts, or tutor assessments); biometric data (e.g. representative of physical characteristics of the user, or data generated during biometric processes such as biometric identification processes); or other personal information that is associated with the user. Such user data may relate to physical attributes or physical interactions of the user, which have occurred or otherwise exist in the real world or which include a physical interaction between the user and another physical entity. For example, employment data may relate to work performed, in the real world, by the user for their employer.

First user data associated with the user is stored in a block of a distributed ledger in examples herein. A distributed ledger may be considered to be a growing list of records, encoded into blocks, that are distributed and synchronized across multiple computing nodes. Each of these computing nodes may be considered member nodes of what may be referred to as a distributed ledger network (DLN). A blockchain is an example of a distributed ledger, and a blockchain network is an example of a DLN.

A distributed ledger may include a cryptographically secure chain of data records. For example, each block of a blockchain typically includes a cryptographic hash of the previous block, and may additionally include further data such as a timestamp and a payload (which for example corresponds to the data to be stored in the block). With this structure, a data record cannot be altered retroactively without altering each subsequent block.

The distributed nature of the DLN further increases the immutability of the stored data, and improves the security of the stored data. For example, a malicious party may be able to alter a data record of their local copy of the distributed ledger, stored on their local member node of the DLN (although this would in itself involve rewriting the entire chain of data records due to the cryptographic link between each block of the chain). However, it is increasingly difficult for the malicious party to alter the data record of each of the copies of the distributed ledger as the number of different copies of the distributed ledger increases, especially if these copies of the distributed ledger are stored across different organisations, in different networks or within different security environments.

Hence, the first user data stored in the distributed ledger may be considered to be a secure data record, due to the difficulty, even near impossibility, of tampering with or otherwise altering data stored in a distributed ledger. The first user data may therefore be considered to reflect an actual or trusted representation of the user data, against which future copies or instances of the user data may be compared to verify the integrity of these further instances of the user data. For example, second user data may be verified with respect to the block by comparing the second user data with the first user data stored in the block. If the first and second user data match, the second user data may be considered to be verified. Verification of the second user data for example indicates that the second user data accurately reflects the underlying data (as stored in the distributed ledger as the first user data), which, as noted above, may relate to physical attributes or physical interactions of the user.

Examples herein include obtaining a block identifier identifying the block of the distributed ledger in which the first user data is stored. The block identifier is processed to generate a verification tag to be associated with second user data, for use in verifying the second user data with respect to the block. An electronic document comprising a computer-readable visual representation of the verification tag and a visual representation of the second user data may then be generated. The electronic document therefore provides a visual representation of the second user data which is readily verifiable, for example by processing the computer- readable visual representation of the verification tag. In this way, an entity desiring to determine whether the second user data accurately reflects the underlying user data (which in this case is stored in the distributed ledger as the first user data) can straightforwardly do so using the computer-readable visual representation of the verification tag. As the electronic document includes visual representations of both the data to be verified and the verification tag for use in verification of the data, the electronic document provides a convenient and easily transmissible verifiable record of the underlying data. For example, verification of the second user data may be performed using the electronic document itself.

The electronic document may be transmitted to the user. This therefore provides the user with a verifiable record of their user data, which is useable in various situations in which the user may wish to provide this data, e.g. to a third party. Moreover, as the electronic document includes the computer-readable visual representation of the verification tag, which allows the visual representation of the second user data to be verified, a third party desiring to determine whether the second user data reflects the true underlying information relating to the user can do so easily and efficiently using the electronic document itself. For example, the methods herein may allow an electronic document to be uniquely identified using a distributed ledger.

Figure 1 is a flow diagram illustrating a method of generating an electronic document according to examples. At item 100 of Figure 1, first user data associated with a user is received. As explained above, the first user data may be personal data reflecting physical attributes or physical interactions of the user, such as employment data, financial data, educational data, or biometric data. The first user data in this case is received by a computing node which is arranged to generate an electronic document comprising verifiable user data.

Although the first user data is associated with the user, the first user data need not be generated by or owned by the user but may instead be generated by a third party. For example, the first user data may be received from a trusted network node, the trusted network node having generated the first user data independently of the user. In such cases, the trusted network node may be considered to be the original source of the first user data. The trusted network node may be a further computing node, which is for example connected to other computing nodes via a network (including the computing node to which the first user data is sent). For example, various computing nodes within a given network may be able to receive and/or transmit data to each other over the network. In such cases, the computing nodes may be considered to be network nodes.

A network node may be considered trusted where it is associated with a trusted entity. Additionally or alternatively, a trusted network node may satisfy various security protocols or other requirements, for example to limit the risk of malicious third parties gaining access to the trusted network node. An entity may be considered trusted where the entity is considered to be a reliable or otherwise trustworthy source of the user data. This may depend on the type of user data generated. For example, an entity may be trusted to generate user data relating to interactions between a given user and the entity. Thus, an employer of a given user may be considered to be a trusted entity for the generation of employment data, for example. For example, a trusted network node may be trusted as a sole source of a particular type of user data. In such cases, user data received from other sources may be considered unreliable and may therefore be discarded.

In some cases, the first user data is received from the trusted network node without the user having access to the first user data. This can improve the integrity of the first user data, for example by limiting opportunities for the user to tamper with the first user data. For example, if the computing node receives the first user data directly from the trusted network node, independently of the user, it may be assumed that the first user data as received by the computing node accurately reflects the original data generated by the trusted network node, which, in turn, accurately reflects the underlying information relating to the user.

The first user data may be received from the trusted network node without being transmitted via other computing systems, such as other network nodes. This may further increase the security of the first user data, by further limiting opportunities for the first user data to be tampered with, for example at other network nodes.

The first user data may be received in any suitable form. For example, the first user data may be received as a file, via an input to an application programming interface (API) or from a database via any suitable database access protocol. The first user data may be sent to the computing system via any suitable network protocol, such as the file transfer protocol (FTP).

At item 102 of Figure 1, the first user data is encrypted. Any suitable encryption algorithm may be used to encrypt the first user data. Encrypting the first user data for example involves encoding the first user data so that the first user data is accessible to a restricted set of parties, typically those parties with a suitable decryption key to decrypt the encrypted first user data. By encrypting the first user data, the security of the first user data is improved. However, this is merely an example, and in some cases, encryption of the first user data may be omitted.

At item 104 of Figure 1, the first user data is transmitted to a member node of a distributed ledger network (DLN) for storage in a block of the distributed ledger. The member node therefore adds a block to the distributed ledger stored by the DLN, where the block includes the first user data. The block may additionally include other data, such as a hash of a previous block of the distributed ledger and metadata such as a timestamp. The first user data may be stored in the block without the user first having access to the first user data. This may improve the security of the first user data, by preventing the user from altering the first user data.

The DLN may be a private DLN, to which only a limited set of trusted users have access. This may further enhance the utility of the DLN for verification of user data. For example, addition of blocks to the distributed ledger stored in the DLN may be restricted to a limited set of trusted users, or trusted member nodes. In this way, it may be ensured that the data stored in the distributed ledger has originated from trusted sources (such as trusted member nodes) and is therefore reliable, and suitable for verifying other data against.

In some cases, the first user data may be processed prior to encryption or prior to sending the first user data to the member node of the DLN. For example, a data format of the first user data may be changed, or the first user data sent to the member node of the DLN may be a subset of a larger dataset or other data record received by the computing node.

In some cases, the first user data may include a plurality of data elements, the plurality of data elements comprising at least a first data element from a first data field of a data record and a second data element from a second data field of the data record. For example, the plurality of data elements may be arranged as a series or sequence of data fields, with each data field including a corresponding entry, which may be referred to as a data element. As an example, the first user data may be employment data and may include the following data fields: employee name, employee identification number, gross pay, net pay, deductions. In this example, the first data element may be the employee’s name and the second data element may be the employee’s identification number.

In some cases, the plurality of data elements may have been extracted from data received by the computing node (for example from the trusted network node). For example, the trusted network node may transmit a payslip as a portable document format (PDF) file, which may be processed to extract text representative of the plurality of data elements of the first user data.

Although not shown in Figure 1, it is to be appreciated that the first user data may be stored by the computing node, temporarily or otherwise, in addition to transmitting the first user data to the distributed ledger. For example, the first user data may be stored in a database or other suitable data store accessible to the computing node.

The block of the distributed ledger in which the first user data is stored is associated with a block identifier. The block identifier for example uniquely identifies the block within the distributed ledger stored in the distributed ledger network (DLN), and may be stored within the block, for example as metadata associated with the block. The block identifier may be in any suitable form, such as an integer or other numerical data type, or text, for example stored as a string or other data type.

The block identifier may depend on the member node which added the block including the first user data to the distributed ledger network. This can further increase the security of the first user data. For example, if the block identifier indicates that a given block has been added to the distributed ledger by a member node other than a member node permitted to add blocks to the distributed ledger, the block may be discarded or otherwise untrusted, for example due to originating from an untrusted source.

At item 106 of Figure 1, the block identifier identifying the block of the distributed ledger in which the first user data is stored is obtained by the computing node. The block identifier may be returned to the computing node, for example as part of a receipt indicating that the block comprising the first user data has been committed to the distributed ledger. For example, the block identifier may be sent to the computing node in response to the block being added to the distributed ledger, without the computing node first sending a request for the block identifier to the member node. In other examples, though, the computing node may first send a request to the member node to store the first user data in the distributed ledger and may subsequently send a request to the member node for the block identifier of the block in which the first user data is stored.

At item 108 of Figure 1, the block identifier is processed to generate a verification tag to be associated with second user data, for use in verifying the second user data with respect to the block. The verification tag for example includes instructions or other information indicative of a verification process which may be used to verify the second user data with respect to the block. For example, the verification tag may include verification data associated with a verification process for use in verifying the second user data with respect to the block. The verification data may be representative of computer program code to cause the verification process to be performed, upon processing of the verification tag using a suitable application. For example, the verification data may represent computer program code which is encoded on or otherwise stored in the distributed ledger, such as a so-called“smart contract”. The verification data may alternatively or additionally point to or otherwise indicate a website or other application including computer program code or other directions to initiate the performance of the verification process. For example, the verification data may be representative of a universal resource identifier (URI) identifying a resource comprising instructions, for example in the form of computer program code, for performing the verification process. The URI may be a Uniform Resource Locator (URL). In such cases, the resource may be a web page, and the URL may indicate a web address of the web page. By including the verification data in the verification tag, verification may be performed more efficiently and easily upon processing the verification tag (for example as described with reference to Figure 5), for example without requiring additional verification instructions. As the verification of the second user data in Figure 1 is with respect to the block, the verification tag may also include a representation of the block identifier, for example so that the first user data can be retrieved from the block associated with the block identifier as part of the verification process. For example, where the block identifier is in the form of a number or text, the verification tag may include numerical data or text data representative of the block identifier. In other cases, the verification tag may include an encoded representation of the block identifier from which the block identifier may be derived, e.g. after suitable decoding of the block identifier.

As an example, the verification tag may include a URI including the block identifier. A URI is for example a string or other sequence of characters identifying a given resource such as a web page. The block identifier (which may form part of the URI) may be used as an input to computer program code implemented by or via the resource. In such cases, navigating to the URI (for example using a suitable web browser) may initiate verification of the second user data with respect to the block identified by the block identifier included in the URI. This is discussed further below with reference to Figure 5.

In some cases, processing the block identifier to generate the verification tag may include processing the block identifier with the first user data or with at least a portion of the first user data to generate the verification tag. In this way, the first user data or portion thereof may be obtained from the verification tag, for example in addition to the block identifier and/or instructions to verify the second user data with respect to the block identified by the block identifier. The obtained first user data may be used in further verifying the second user data, as explained with reference to Figures 5 and 6.

In examples in which the first user data includes a plurality of data elements, processing the block identifier to generate the verification tag may include combining the block identifier with the plurality of data elements to generate an electronic fingerprint representative of the first user data, and processing the electronic fingerprint to generate the verification tag. The block identifier and the plurality of data elements may be combined in various ways. For example, combining the block identifier with the plurality of data elements may include concatenating the block identifier and each of the plurality of data elements. In such cases, the block identifier and data elements may be concatenated such that there is a separation element, such as a null character or another predetermined character designating a separation or space, between the block identifier and the first of the data elements and between each of the data elements. The block identifier and the plurality of data elements may be retrieved from the electronic fingerprint in such cases by separating the electronic fingerprint into constituent components using the separation elements.

The verification tag may be represented using a computer-readable visual representation. Hence, in some cases, processing the block identifier to generate the verification tag may include processing the block identifier to generate the verification tag in the form of a computer-readable visual representation of the verification tag. A representation may be considered visual where the content of the representation is encoded in an appearance of the representation rather than in another characteristic of the representation. The visual representation of the verification tag may therefore provide a visual depiction of the verification tag. For example, the computer-readable visual representation of the verification tag may include an image. An image may include pictures and/or text. For example, the computer-readable visual representation of the verification tag may include a series of letters and/or numbers. For example, an image may include a code such as a barcode or quick response (QR) code. A visual representation is for example computer-readable where it is in a format that can be processed or otherwise read by a computer. For example, an image may be computer- readable using image processing. For example, a barcode may represent the verification tag using a series of parallel lines with various line widths and spacings between the lines. A barcode may be read by a computer, for example using barcode reading software or hardware of the computer. A QR code may be considered to be a two- dimensional barcode, sometimes referred to as a matrix barcode. A QR code may represent the verification tag using an array of black squares of various different sizes and patterns arranged on a white background. A QR code may be captured using an image capture device, such as a camera, coupled to or forming part of a computer, and processed to extract the underlying data (such as the block identifier and/or the first user data).

It is to be appreciated that the generation of the verification tag may be performed by an appropriate application which is arranged to generate a particular visual representation from underlying data, such as a QR code generator or other visual representation generator. In such cases, the method may include transmitting a programming interface request to a programming interface for a visual representation generator to instruct the visual representation generator to generate the visual representation of the verification tag. In such cases, the programming interface request may include the block identifier or the block identifier and at least a portion of the first user data (such as a combination of the block identifier and at least a portion of the first user data).

As an example, the verification tag may be generated as a URI in the form of a string, which includes the block identifier and which points to a web page to initiate or otherwise cause verification of the second user data with respect to the block. The URI may then be processed, for example by a QR code generator, to generate the computer- readable visual representation of the verification tag, which in this case is a QR code. In other examples, though, the verification tag may be generated as a computer-readable visual representation of the verification tag without first generating the verification tag in a different format.

At item 110 of Figure 1, an electronic document comprising the computer- readable visual representation of the verification tag and a visual representation of the second user data (which may be verified against the block) is generated. The electronic document may be in any suitable format. For example, where the computer-readable visual representation of the verification tag includes an image, the electronic document may be or include an image in any suitable image file format. The visual representation of the second user data may also be an image, and may also include picture(s) and/or text. The visual representation of the second user data may be in a human-readable format or in a computer-readable format; it is to be appreciated that some formats may be human-readable and computer-readable.

At item 112 of Figure 1, the electronic document is transmitted to the user, whereupon it may be used by the user, for example as a verifiable representation of their user data.

An example of generation of an electronic document is shown schematically in Figures 2a and 2b. In examples such as this, a first electronic document 114a is generated. The first electronic document 114a is shown in Figure 2a and includes a first portion 116 including the visual representation of the second user data and a second portion 118 different from the first portion 116. In this example, the second portion 118 of the first electronic document 114a is blank or otherwise empty. The second portion 118 of the first electronic document 114a may be considered to correspond to a placeholder for the computer-readable visual representation of the verification tag. The first electronic document 114a may therefore be generated before the verification tag is generated. For example, the first electronic document 114a may be generated after receipt of the first user data by the computing but before generation of the verification tag. In such cases, the second user data and the first user data may be the same as each other, but the term first user data may be considered to refer to the user data which is stored in the block whereas the term second user data may be considered to refer to the user data which is included in the electronic document. In other cases, the second user data may have undergone further processing compared to the first user data.

The first electronic document 114a may be generated according to a predetermined electronic document template, which may depend on characteristics of the second user data, such as a number of data fields of the second user data or the data type of data in each data field of the second user data. For example, if the second user data represents a pay slip of a user, the first electronic document 114a may be generated using an electronic document template, such as an electronic document template associated with input data in the form of pay slips, with a suitable structure to represent a pay slip. This for example simplifies generation of the electronic document, by obviating the need to reformat or regenerate different document formats on an ad-hoc or user-by-user basis.

After generating the first electronic document 114a, the second portion 118 of the first electronic document 114a may be modified to include the computer-readable visual representation of the verification tag 120, thereby generating a second electronic document 114b (shown in Figure 2b) comprising the computer-readable visual representation of the verification tag 120 and the visual representation of the second user data 116. In some cases, the second electronic document 114b may supersede the first electronic document 114a. In such cases, the first electronic document 114a may be modified to generate the second electronic document 114b, without storing the first electronic document 114a. In other cases, though, both the first electronic document 114a and the second electronic document 114b may be stored. The verification tag (for example in the form of the computer-readable visual representation of the verification tag) may also be stored, although it may be stored in the same storage as or in different storage from the first and/or second electronic documents 114a, 114b. The second portion 118 of the first electronic document 114a may be selected so that the computer- readable visual representation of the verification tag 120 is provided in a suitable location and/or size as part of the second electronic document 114b. This can facilitate reading of the computer-readable visual representation of the verification tag 120 by a computer, for example during verification of the second electronic document 114b.

In examples, the electronic document is in a markup language electronic document format. A markup language for example refers to annotating a document so that the annotations (sometimes referred to as markup) are distinguishable from other content of the document (such as text). A markup language electronic document format for example refers to an electronic document format in which the electronic document includes markup, for example indicating how or where certain components of the electronic document are to be displayed or otherwise rendered. As an example, HyperText Markup Language (HTML) is a markup language which may be used to specify the structure of web pages.

In examples such as this, the first electronic document 114a may be an HTML electronic document and the first portion 116 of the first electronic document 114a may correspond to a first HTML element of the document. The first HTML element may include the second user data, and may include directions (for example in the form of markup) indicating how the second user data is to be displayed when the first electronic document 114a is rendered. The first electronic document 114a may include the second portion 118 as a second HTML element for including an image (for example using appropriate tags such as the <img> tag, as the skilled person will appreciate). However, a source for the image may be absent from the first electronic document 114a (which is for example generated before the verification tag is generated). After generation of the second electronic document 114b, though, the second HTML element may include or otherwise link to the computer-readable visual representation of the verification tag 120, which may be in an image format such as the Portable Network Graphics (PNG) data format). Figure 3 shows schematically components of an example system 122 for use with the methods described herein. The system 122 includes a trusted network node 124, which in this case is arranged to generate the first user data as discussed with reference to Figure 1. The trusted network node 124 transmits the first user data 126 to a computing node 128. The trusted network node 124 is associated with a trusted entity 130 and the computing node 128 is associated with a first entity 132. In this case, the trusted entity 130 and the first entity 132 are different entities, for example associated with different organizations or different physical locations. In other cases, though, the trusted network node 124 and the computing node 128 may be associated with the same entity.

The computing node 128 transmits the first user data 126 to a first member node 134 of a distributed ledger network (DLN) 136 for storage in a block of the DLN 136. In this case, the computing node 128 and the first member node 134 are both associated with the first entity 132, although this need not be the case. Furthermore, in some cases, the computing node 128 may itself be a member node of the DLN 136. In such cases, the first user data 126 may be stored in the DLN 136 by the computing node 128.

The DLN 136 in the example of Figure 3 also includes a second member node 138. Copies of data held within a distributed ledger associated with the DLN may be stored at, or by, each of the member nodes, including the first and second member nodes 134, 138. Member nodes may store copies of the distributed ledger or part of the distributed ledger. In examples, the DLN 136 is a private DLN. The DLN 136 may include control nodes for controlling access to the DLN and for providing various network functions.

In this example, the second member node 138 is associated with a second entity 140 which is different from the first entity 132. The distributed ledger is synchronized between member nodes of the DLN 136, such as between the first member node 134 and the second member node 138. This for example involves the transfer of synchronization data 142 between the first member node 134 and the second member node 138. As an example, upon addition of the block including the first user data 126 to the distributed ledger by the first member node 134, the first member node 134 may transmit the synchronization data 142 to the second member node 138. The synchronization data 142 for example includes the first user data 126, and may be used to synchronize a first version of the distributed ledger stored at the first member node 134 (which includes the block including the first user data 126) with a second version of the distributed ledger stored at the second member node 138.

A member node of a DLN such as the DLN 136 can take a variety of forms, including devices such as a server computer, a desktop computer, a laptop computer, or a smartphone computing device. A member node may therefore be any suitable computing device, such as any electronic device with appropriate processing capability for processing or interacting with a distributed ledger, such as a central processing unit (CPU), or dedicated software or hardware such as a suitably programmed field programmable gate array (FPGA) or application specific integrated circuit (ASIC).

Alternatively, a member node may be implemented by a distributed collection of devices interconnected by a network, for example a local area network. Where a member node is implemented by different entities, each having a separate corporate network, for example a local area network (LAN) protected by a firewall (as in the case of the first and second member nodes 134, 138 of Figure 3), at least a part of a member node which may be queried by one or more remote member nodes, may be located in a demilitarized zone (DMZ) outside a main firewall of the corporate network.

Each member node of a DLN such as the DLN 136 of Figure 3 may be operated by a different user or organization or a user or organization may control or operate a number of different member nodes.

The DLN 136 of Figure 3 is a decentralized, and distributed, system, in which the member nodes, including the first and second member nodes 134, 138, can communicate with each other via a data communications network. The network may include private network links and/or public network links, and may include a plurality of interconnected networks.

Each of the member nodes may have integrated or externally-coupled wired networking capabilities. Alternatively, or in addition, each of the member nodes may have integrated or externally-coupled wireless networking capabilities, using wireless telecommunications systems such as those using the Long Term Evolution (LTE) standards. The member nodes may in turn be connected to a series of one or more networks comprising servers, routers and other networking equipment that communicate using the Internet Protocol (IP) protocol. One or more of the member nodes may include virtual devices implemented on underlying physical computing hardware.

In Figure 3, the trusted network node 124 and/or the computing node 128 may have networking capabilities similar to or the same as the member nodes. The computing node 128 can communicate with the DLN 136 and the trusted network node 124 may be able to communicate with the DLN 136 or may be denied direct access or other communication with the DLN 136. In such cases, the trusted network node 124 may be able to communicate with the DLN 136 via the computing node 128. As for the network via which the member nodes are arranged to communicate, the network for communication between the trusted network node 124 and/or the computing node 128 and the DLN 136 may include private network links and/or public network links, and may include a plurality of interconnected networks.

Figure 4 provides an overview of examples of internal components for an example computing device 144 for use as a member node of a DLN, such as the first member node 134 of the DLN 136 of Figure 3. The computing device 144 of Figure 4 may additionally or alternatively be used as the computing node 128 and/or the trusted network node 124 of Figure 3.

The computing device 144 of Figure 4 includes a network interface 146 to communicate with a network 148, so that the computing device 144 may communicate with other computing devices via the network 148. The network interface 146 of the computing device 144 may include software and/or hardware components, such as a virtual network interface, an Ethernet port, a software driver and/or communications stack interacting with network hardware.

The computing device 144 of Figure 4 also includes storage 150, for example for storing data used in the methods herein such as the first user data, the distributed ledger, the second user data and/or the electronic document. The storage 150 may include at least one of volatile memory, such as a Random Access Memory (RAM) and non-volatile memory, such as magnetic, optical or tape media, or a solid state drive (SSD) such as Flash memory. In the example of Figure 4, the storage 150 is local to the computing device 144. However, in other examples, the computing device 144 may be coupled to storage which is remote from the computing device 144, such as cloud storage. At least one processor 152 is communicatively coupled to the storage 150 in the computing device 144 of Figure 4. The at least one processor 152 in the example of Figure 4 may be a microprocessor, a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any suitable combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. The at least one processor 152 may include one or more graphical processing units (GPUs).

The components of the computing device 144 in the example of Figure 4 are interconnected using a systems bus 154. This allows data to be transferred between the various components. For example, where the computing device 144 is used as the computing node 128 of Figure 3, the first user data may be transmitted to the first member node 134 of the DLN 136 by transferring the first user data from the storage 150, via the systems bus 154, to the network interface 146 for transmission to the network 148.

It is to be noted that the methods described herein may be performed by functional components which may include dedicated processing electronics and/or may be implemented by way of computer program code executed by a processor of at least one computing device (such as the at least one processor 152). In certain cases, one or more embedded computing devices may be used.

In some cases, the storage 150 may include computer program code configured to, when processed by the at least one processor 152, implement the methods described herein. This computer program code may be stored in an accessible non-transitory computer-readable medium and loaded into memory, for example the storage 150, to implement the methods described herein. For example, where the computing device 144 is used as the computing node 128 of Figure 3, the storage 150 may include computer program code configured to implement the method of Figure 1, when processed by the at least one processor 152. In other cases, the functional components arranged to perform any of the methods herein may include a suitably configured system-on-chip, application- specific integrated circuit and/or one or more suitably programmed field -programmable gate arrays. In certain cases, the components may be implemented by way of one or more functions implemented in parallel, e.g. on multiple processors and/or cores of a graphics processing unit.

Figure 5 is a flow diagram illustrating a verification method according to examples. The method of Figure 5 may for example be used to verify an electronic document such as that generated using the method of Figure 1, which includes a computer-readable visual representation of a verification tag and a visual representation of the second user data. For example, the method of Figure 5 may be used to verify, with respect to a block of a distributed ledger in which first user data associated with a user is stored, second user data.

Features of the method of Figure 5 may be performed by a computing device such as the computing device 144 of Figure 4. Such a computing device 144 may be associated with a third party who desires to verify the second user data associated with the user, and stored in the electronic document.

At item 156 of Figure 5, the electronic document is received, for example via a network, although this is merely an example. In some cases, the electronic document may be considered to be received by a computing device where it is accessible to the computing device. For example, where the computing device includes an image capture device, the electronic document may be considered received where the image capture device is able to capture an image of the electronic document. In other examples, though, receipt of the electronic document may include storage of the electronic document, including temporary storage of the electronic document, by the computing device.

At item 158 of Figure 5, the computer-readable visual representation of the verification tag is processed to extract, from the computer-readable visual representation of the verification tag, a block identifier of the block of the distributed ledger in which the first user data is stored. The computer-readable visual representation of the verification tag may be processed using any suitable functional component or application for reading the computer-readable visual representation of the verification tag. For example, where the computer-readable visual representation of the verification tag is a QR code, processing of the QR code may including obtaining an image of the QR code using an image capture device such as a camera, and processing the image using suitable image processing methods to extract the block identifier from the QR code. For example, an error correction process such as Reed-Solomon error correction may be applied to the image to reduce image artifacts. The block identifier may then be extracted from the patterns present in the error-corrected image, for example in vertical and horizontal components.

As explained above, the block identifier may form part of a URI. In such cases, the URI may be extracted from the computer-readable visual representation of the verification tag, and the block identifier may then be obtained from the URI. Instructions or other information indicative of a verification process which may be used to verify the second user data with respect to the block may be extracted from the computer-readable visual representation of the verification tag. For example, verification data associated with a verification process may be extracted from the computer-readable visual representation of the verification tag. For example, where the computer-readable visual representation of the verification tag includes a URI, the URI may include suitable computer program code or other directions to initiate the performance of the verification process. In such cases, the verification data may be representative of the URI. However, in other examples, the verification data may represent other resources or applications. In some cases, the verification data may include instructions, such as computer program code, to implement the verification process upon extracting the verification data from the computer-readable visual representation of the verification tag and upon processing of the computer program code appropriately, for example using an appropriate application. Computer program code as described herein may be in any suitable programming language and may be compiled or assembled code, or source code that is human-readable. It is to be appreciated that the block identifier and instructions such as this may be extracted together, for example as part of the same URI.

At item 160 of Figure 5, it is determined that the distributed ledger includes the block with the block identifier extracted from the computer-readable visual representation of the verification tag. If this is the case, it may be determined that the electronic document has not been tampered with, and that the second user data is therefore verified. A suitable message or indication may be received by the computing device indicating that the second user data has been successfully verified, indicating that the second user data of the electronic document accurately reflects the underlying user data (e.g. stored as the first user data in the block).

Otherwise, verification of the second user data may be considered to have failed and a message or other indication may be received by the computing device indicating that the second user data is unverified and may therefore differ from the underlying user data (e.g. stored as the first user data in the block).

To determine that the distributed ledger includes the block with the block identifier extracted from the computer-readable visual representation of the verification tag may include querying the distributed ledger to determine whether the distributed ledger includes a block with that particular block identifier. This may for example include transmitting a programming interface request to a programming interface for the DLN storing the distributed ledger, the programming interface request comprising the block identifier. The programming interface request may additionally include instructions to cause the programming interface for the DLN to attempt to identify whether the distributed ledger includes the block with the block identifier. The programming interface for the DLN may then scan the distributed ledger to locate the block with the block identifier. If the block with the block identifier is successfully located, the programming interface for the DLN may return an indication that the distributed ledger includes the block with the block identifier.

In an example in which the verification tag represents a URI, the resource associated with the URI may instruct or otherwise cause the sending of the programming interface request to the programming interface. The programming interface request may be sent in response to processing the computer-readable visual representation of the verification tag, for example without further input from the computing device.

The resource associated with the URI (such as a web page including suitable computer program code) may receive a response from the programming interface for the DLN either indicating that the second user data has been verified (e.g. if the block with the block identifier is successfully located in the distributed ledger) or indicating that verification of the second user data has failed (e.g. if the distributed ledger does not include a block with the block identifier). The resource associated with the URI may include suitable instructions, such as suitable computer program code, to generate a verification output based on the response received from the programming interface for the DLN. For example, where the resource associated with the URI is a web page, the web page may include suitable computer program code to receive the response from the programming interface for the DLN and generate a suitable output for rendering using a display device coupled to the computing device. For example, where the second user data is successfully verified, a web browser directed to the web page may render a message indicating that the second user data has been verified.

In some cases, verification may be considered to have been performed where it is determined that the distributed ledger includes a block with the block identifier obtained from the computer-readable visual representation of the verification tag. However, in other cases, such as that of Figure 5, the verification process may additionally include a comparison of the first user data (stored in the distributed ledger in the block with the block identifier obtained from the computer-readable visual representation of the verification tag) with the second user data.

Figure 5 includes, at block 162, retrieving the first user data from the block of the distributed ledger using the block identifier extracted from the computer-readable visual representation of the verification tag. Retrieval of the first user data may for example be performed similarly to determination of whether the distributed ledger includes a block with the block identifier. For example, the programming interface request to a programming interface for the DLN may include the block identifier and instructions to cause the programming interface for the DLN to retrieve the first user data from the block with the block identifier (rather than merely determining whether the distributed ledger includes the block with the block identifier). A response may be received from the programming interface for the DLN, which includes the first user data retrieved from the block with the block identifier.

At item 164, the first user data is decrypted, for example using a suitable decryption key. It is to be appreciated that item 164 may be omitted in examples in which the first user data is not encrypted. Decryption of the first user data may be performed by the programming interface for the DLN before the response is sent from the programming interface for the DLN. In other words, the first user data included in the response from the programming interface for the DLN may be decrypted first user data. In other examples, though, the first user data may be decrypted by the computing device rather than by the programming interface for the DLN.

At item 166, the first user data is compared with the second user data. If the first user data and the second user data match, the second user data may be considered verified with respect to the block (which includes the first user data). The first and second user data may be considered to match where corresponding values of the first and second user data are identical. The second user data may be obtained from the electronic document, for example.

As explained with reference to item 160, in such cases, the resource associated with the URI may include suitable instructions, such as suitable computer program code, to generate a verification output indicative of whether the second user data has been successfully verified with respect to the block. For example, where the resource associated with the URI is a web page, the web page may include suitable computer program code to generate a suitable output for rendering using a display device coupled to the computing device depending on the outcome of the comparison between the first and second user data.

Some cases may include generating a visual representation of the first user data obtained from the block of the distributed ledger at item 162. The visual representation of the first user data may be sent to the computing device for display (for example by sending the visual representation of the first user data to a display device interface of the computing device which is coupled to the display device), or to a further computing device for display. By comparing the visual representation of the first user data and the electronic document (which includes the visual representation of the second user data), it may be determined whether the first user data and the second user data match and, hence, whether the second user data is verified with respect to the block.

Figure 6 is a flow diagram illustrating features of a verification method according to further examples. Item 168 of Figure 6 includes receiving an electronic document such as that which may be generated using the method of Figure 1. The electronic document includes a computer-readable visual representation of a verification tag and a visual representation of second user data. Item 170 of Figure 6 includes processing the computer-readable visual representation of the verification tag similarly to the processing of item 158 of Figure 5. However, in the example of Figure 6, the first user data comprises a plurality of data elements, the plurality of data elements comprising at least a first data element from a first data field of a data record and a second data element from a second data field of the data record. In this case, the processing of the computer-readable visual representation of the verification tag includes extracting the block identifier from the computer-readable visual representation of the verification tag (as described with reference to item 158 of Figure 5). Instructions to perform or initiate the performance of a verification process may also be extracted from the computer-readable visual representation of the verification tag, for example as described with reference to item 158 of Figure 5. In addition, however, item 170 of Figure 6 includes processing the computer-readable visual representation of the verification tag to extract, from the computer-readable visual representation of the verification tag, at least one of the plurality of the data elements. The at least one of the plurality of the data elements may be compared against the first user data retrieved from the block of the distributed ledger (as described with reference to item 162 of Figure 5), to further verify that the computer- readable visual representation of the verification tag has not be tampered with. The at least one of the plurality of the data elements may additionally or alternatively be compared with the second user data of the electronic document. A visual representation of the at least one of the plurality of the data elements may be generated, for example for display. This may be more efficient than obtaining the data elements from the block of the distributed ledger in which the first user data is stored.

Figure 7 shows schematically components of a further example system for use with the methods described herein. The system of Figure 7 includes a computing device 172 and a programming interface 174 for a distributed ledger network (DLN) 176. The programming interface 174 acts as an interface between the computing device 172 and the DLN 176. For example, the computing device 172 may send instructions to the programming interface 174 to identify whether a distributed ledger stored by the DLN 176 includes a block with a given block identifier, or to retrieve the contents of a block with the block identifier from the distributed ledger. The programming interface 174 may then communicate with the DLN 176 to obtain an appropriate response, which it returns to the computing device 172. In Figure 7, the programming interface 174 is shown as a separate component from the computing device 172 and the DLN 176. However, in other examples, the computing device 172 or the DLN 176 (such as a member node of the DLN 176) may include the programming interface 174.

Figure 8 is a flow diagram illustrating features of a verification method according to yet further examples. The method of Figure 8 may be used to verify first user data, associated with a user, with respect to second user data.

Item 178 of Figure 8 includes obtaining a computer-readable visual representation of a verification tag associated with the second user data. The computer- readable visual representation of the verification tag may be similar to the computer- readable visual representation of the verification tag described with reference to other examples herein. In some cases, the computer-readable visual representation of the verification tag may be received independently of the second user data. In other cases, though, the computer-readable visual representation of the verification tag and the second user data may both be received. For example, obtaining the computer-readable visual representation of the verification tag may include obtaining the computer- readable visual representation of the verification tag from an electronic document including the computer-readable visual representation of the verification tag and a visual representation of the second user data, such as an electronic document described with reference to other examples herein.

Item 180 of Figure 8 includes processing the computer-readable visual representation of the verification tag to identify a block identifier of a block of the distributed ledger in which the first user data is stored. Item 180 of Figure 8 may be similar to item 158 of Figure 5, for example; a corresponding description is to be taken to apply. In this example, the block was added to the distributed ledger by a first member node of a distributed ledger network (DLN), such as the first member node 134 of Figure 3.

At item 182 of Figure 8, a request to obtain the first user data from a second member node of the DLN is transmitted. The request may be transmitted to the second member node of the DLN, to another member node of the DLN or to a control node of the DLN for controlling access to member nodes of the DLN. The second member node may be similar to or the same as the second member node 138 of Figure 3, and may be associated with a different entity than the first member node.

At item 184, the first user data is received from the second member node. The first user data received may then be compared against the second user data, for example to verify the first and second user data with respect to each other.

In methods in accordance with Figure 8, and with reference to Figure 3, the block including the first user data may be added to the distributed ledger by the first member node 134. The distributed ledger may then be synchronized between the first and second member nodes 134, 138, to update the copy of the distributed ledger stored at the second member node 138 to include the first user data. However, rather then retrieving the first user data from the copy of the distributed ledger stored at the first member node 134 as part of the verification process, the method of Figure 8 instead includes retrieving the first user data from the copy of the distributed ledger stored at the second member node 138.

This approach may be more efficient than retrieving the first user data from the first member node 134. For example, the first member node 134 may be associated with a first entity and the second member node 138 may be associated with a second entity different from the first entity. The computer-readable visual representation of a verification tag may be obtained and processed (to identify the block identifier) using a first computing node of a network associated with the second entity, and then retrieved from the second member node 138 of the DLN, which may be a second computing node of the network. In other words, the first user data may be obtained from a computing node on a network which is local to the computing node requesting the first user data, rather than from a computing node on an external or more remote network, such as the first member node 134. Furthermore, this may obviate the need for security protocols or processes that may be performed during the communication of data between the network associated with the second entity and a further network associated with the first entity. This may further improve the efficiency with which the first user data is retrieved.

The above examples are to be understood as illustrative examples. It is to be understood that any feature described in relation to any one example may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the examples, or any combination of any other of the examples. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the accompanying claims.