System for generating verifiable physical transaction documents

Abstract

Inventions relate to a computer-implemented system and methods for generating, using and verifying physical transaction documents, wherein each physical transaction document comprises transaction information and security information. The system comprises: a key generator, configured to generate a plurality of keys; a document generator, configured to generate a plurality of physical transaction documents; and a digital counterpart ledger, configured to store a respective digital counterpart for each of the plurality of physical transaction documents. The digital counterpart ledger may be an immutable ledger. The document generator generates each document by: obtaining a first key from the key generator 401; obtaining transaction information 402; obtaining a unique document identifier based on the key 403; generating a digital counterpart of the physical transaction document 404, the digital counterpart comprising the unique document identifier and the transaction data; adding the digital counterpart to the digital counterpart ledger 406; and producing the physical transaction document based on the digital counterpart 405.

Description

TECHNICAL FIELD

[0001] The present application relates systems for managing transaction documents. BACKGROUND

[0002] There has been an increasing trend in using digital assets rather than physical assets for many transactions. Digital assets are often more convenient to transfer between parties, and trust can be established through means such as blockchains. Here "trust" refers to requirements such as preventing forgery / duplication of assets, or tracking a chain of ownership.

[0003] However, in many types of transaction, a physical asset is still needed.

[0004] For example, in supply chain financing, bills of exchange, promissory notes, bills of lading and other related assets were in the past frequently used as transaction documents.

[0005] Physical transaction documents are also sometimes needed in scenarios that are not necessarily related to supply-chain financing. For example, bills of lading may need to be physically presented upon receipt of delivered goods. Furthermore, physical transaction documents, including bills of exchange, promissory notes etc., may be used as a way to store value securely independently from any function that they may have when completing a transaction.

[0006] Rules for generating and using such assets are legally defined in many countries, and in many cases (or even most cases) the relevant laws are written based on the assumption that the transaction document is a physical object which can be presented to the relevant authorities, for example in order to receive an official stamp. In other words, a "digital equivalent" of a physical transaction document may be recognised in some legal jurisdictions but, in other jurisdictions, the physical transaction document itself may be required.

[0007] Accordingly, it is desirable to provide a system which can manage generation and / or usage of physical transaction documents while providing convenience and / or security features that are comparable to digital assets. Preferably, such a system is also compliant with relevant laws on Electronic Transferable Records (e.g. MLETR) and / or KYC / AML regulations. SUMMARY

[0008] According to a first aspect, the application provides a computer-implemented system for generating verifiable physical transaction documents, wherein each physical transaction document comprises transaction information and security information, the system comprising: a key generator configured to generate a plurality of keys; a document generator configured to generate a plurality of physical transaction documents; and a digital counterpart ledger configured to store a respective digital counterpart for each of the plurality of physical transaction documents, wherein the digital counterpart ledger is an immutable ledger, wherein the document generator is configured to generate each physical transaction document by: obtaining a first key from the key generator; obtaining transaction information; obtaining a unique document identifier based on the key; generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier and the transaction data; adding the digital counterpart to the digital counterpart ledger; and producing the physical transaction document based on the digital counterpart.

[0009] By creating a digital counterpart and adding the digital counterpart to a ledger, security of the produced physical transaction document is increased. Furthermore, since the physical transaction document is produced based on the digital counterpart, a time and / or place of production of the physical transaction document can be decoupled from the time and / or place where the document was (digitally) generated. This means that the transaction document can be conveniently portable (as a digital asset), at least until a time at which the transaction document needs to be physically present.

[0010] In embodiments of the first aspect, the key generator may be configured to send keys to the document generator using a quantum communication channel and / or using a quantumsafe encryption. For example, the system may comprise a quantum-safe "QS" network including the key generator and the document generator, the key generator comprising one or more QS server(s), each QS server comprising a hardware security module "HSM" for storing an identical set of quantum distributed "QD" keys, said identical set of QD keys having been distributed to each of said QS server(s) in a quantum-safe manner, and said QS server(s) configured to communicate securely with each other and the document generator using one or more available QD keys from the identical set of QD keys, and to provide a respective different QD key to the document generator as the first key for generating each physical transaction document.

[0011] Similarly, in embodiments of the first aspect, the document generator may be configured to send the digital counterpart to the digital counterpart ledger using a quantum communication channel and / or using a quantum-safe encryption.

[0012] Using a quantum communication channel and / or quantum-safe encryption has the advantage of preventing any external party from accessing the generated keys. This increases the security of the system against forgery of fake or duplicated transaction documents.

[0013] In embodiments of the first aspect, the key generator may be configured to send keys to the digital counterpart ledger, and the digital counterpart ledger may be configured to, for each physical transaction document: receive the digital counterpart from the document generator; obtain a second key from the key generator; encrypt the digital counterpart using the second key; and store the encrypted digital counterpart.

[0014] Using a second key for encryption has the advantage of controlling access to digital counterparts and thereby increasing the reliability of the digital counterparts for verifying the physical transaction document

[0015] Similar to the above, in embodiments of the first aspect, the key generator may be configured to send keys to the digital counterpart ledger using a quantum communication channel and / or using a quantum-safe encryption. For example, the system may comprise a quantum-safe "QS" network including the key generator and the digital counterpart ledger, the key generator comprising one or more QS server(s), each QS server comprising a hardware security module "HSM" for storing an identical set of quantum distributed "QD" keys, said identical set of QD keys having been distributed to each of said QS server(s) in a quantumsafe manner, and said QS server(s) configured to communicate securely with each other and the digital counterpart ledger using one or more available QD keys from the identical set of QD keys, and to provide a respective different QD key to the digital counterpart ledger as the second key for generating each physical transaction document.

[0016] In embodiments of the first aspect, the first key and / or the second key may be a symmetric encryption key. For example, the key may be a 256-bit key suitable for AES-256 encryption. This has the advantage that the same key generator can be used for obtaining unique document identifiers and for encrypting transaction document data.

[0017] In embodiments of the first aspect, obtaining the unique document identifier may comprise calculating a first hash based on the first key. Furthermore, obtaining the unique document identifier further may comprise calculating a second hash based on the transaction data and the first hash. Using a hash function improves security, by making it more difficult for a third party to predict a valid document identifier for a given transaction document, reducing the risk of forgery. Additionally, in a case where the key generator is not entirely trusted, the hash performed by the document generator ensures that the key generator does not have direct access to the unique document identifier.

[0018] In embodiments of the first aspect, the digital counterpart ledger may be a distributed ledger comprising a plurality of ledger instances. A plurality of ledger instances protects against data loss. Additionally, in embodiments where different ledger instances are controlled by different parties, a process of consensus between the ledger instances can be used to reduce the risk of errors and / or forgeries.

[0019] In some embodiments of the first aspect, the system may further comprise a digital counterpart retriever configured to obtain the digital counterpart for a physical transaction document from the digital counterpart ledger based on the unique document identifier of the physical transaction document. Furthermore, the digital counterpart retriever may be configured to display the transaction data of the digital counterpart for comparison to the physical transaction document. Yet further, producing the physical transaction document based on the digital counterpart may comprise printing the physical transaction document, wherein the printed physical transaction document comprises a machine-readable code, wherein the machine-readable code includes information for obtaining the digital counterpart of the physical transaction document; and the digital counterpart retriever comprises a scanner configured to read the machine-readable code. For example, the information for obtaining the digital counterpart of the physical transaction document comprises the unique document identifier. Each of these implementations of a digital counterpart retriever provides a suitable interface for user to verify a physical transaction document by comparison to its digital counterpart.

[0020] In some embodiments of the first aspect, for a first physical transaction document of the plurality of physical transaction documents, the document generator is configured to generate the physical transaction document by: obtaining a first key from the key generator; obtaining a first set of transaction data; obtaining a second set of transaction data; obtaining a unique document identifier based on the first key; generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier, the first set of transaction data and the second set of transaction data; producing the physical transaction document based on the digital counterpart, wherein the physical transaction document comprises the first set of transaction data and the unique document identifier, and the second set of transaction data is omitted from the physical transaction document; and adding the digital counterpart to the digital counterpart ledger. Furthermore, the system may comprise a digital counterpart retriever configured to obtain the digital counterpart for a physical transaction document from the digital counterpart ledger based on the unique document identifier, wherein the digital counterpart retriever is configured to provide the first set of transaction data and the second set of transaction data of the digital counterpart to a user. Furthermore, the digital counterpart retriever may be configured to: determine a read access level of the user, wherein the read access level is a basic read access level or an enhanced read access level; and if the read access level is the basic read access level, provide the first set of transaction data of the digital counterpart to the user and omit providing the second set of transaction data of the digital counterpart to the user; and if the read access level is the enhanced read access level, provide the first set of transaction data and the second set of transaction data of the digital counterpart to the user. The first set of transaction data or the second set of transaction data may comprise user privilege data, wherein the user privilege data identifies one or more users having the enhanced read access level.

[0021] In such embodiments, additional transaction data is associated with the transaction document, beyond the data that is actually shown on the physical transaction document. This provides a mechanism for maintaining more detailed transaction records and securely linking those records to the physical transaction document, without requiring that the detailed records are available to everyone who can see the physical transaction document. Additionally, access to the detailed transaction records can be limited to specific users or user groups.

[0022] In some embodiments of the first aspect, the digital counterpart further comprises a state of the physical transaction document, the state indicating whether the physical transaction document has been produced. This enables control of how many copies of the physical transaction document can exist. In many applications, the number of copies is limited to one.

[0023] In some embodiments of the first aspect, the system comprises check-in means for verifying destruction of a physical transaction document. This enables control of how many copies of the physical transaction document can exist at any given time, without requiring that the physical transaction document is held and carefully preserved by the user over time.

[0024] According to a second aspect, the application provides a computer-implemented method for generating a verifiable physical transaction document, wherein the physical transaction document comprises transaction information and security information, the method comprising: obtaining a first key from a key generator; obtaining transaction information; obtaining a unique document identifier based on the key; generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier and the transaction data; adding the digital counterpart to a digital counterpart ledger; and producing the physical transaction document based on the digital counterpart.

[0025] By creating a digital counterpart and adding the digital counterpart to a ledger, security of the produced physical transaction document is increased. Furthermore, since the physical transaction document is produced based on the digital counterpart, a time and / or place of production of the physical transaction document can be decoupled from the time and / or place where the document was (digitally) generated. This means that the transaction document can be conveniently portable (as a digital asset), at least until a time at which the transaction document needs to be physically present.

[0026] In embodiments of the second aspect, the key may be obtained using a quantum communication channel and / or using a quantum-safe encryption. For example, the system may comprise a quantum-safe "QS" network, the key generator comprising one or more QS server(s), each QS server comprising a hardware security module "HSM" for storing an identical set of quantum distributed "QD" keys, said identical set of QD keys having been distributed to each of said QS server(s) in a quantum-safe manner, and said QS server(s) configured to communicate securely using one or more available QD keys from the identical set of QD keys, and to provide the key.

[0027] Similarly, in embodiments of the second aspect, the digital counterpart may be added to the digital counterpart ledger using a quantum communication channel and / or using a quantum-safe encryption.

[0028] Using a quantum communication channel and / or quantum-safe encryption has the advantage of preventing any external party from accessing the generated keys. This increases the security of the system against forgery of fake or duplicated transaction documents.

[0029] In embodiments of the second aspect, the method may additionally comprise the key generator sending a second key to the digital counterpart ledger, and the digital counterpart ledger: encrypting the digital counterpart using the second key; and storing the encrypted digital counterpart.

[0030] Using a second key for encryption has the advantage of controlling access to digital counterparts and thereby increasing the reliability of the digital counterparts for verifying the physical transaction document.

[0031] Similar to the above, in embodiments of the second aspect, the key generator may send the second key to the digital counterpart ledger using a quantum communication channel and / or using a quantum-safe encryption. For example, the key generator and the digital counterpart ledger may each be part of a same quantum-safe "QS" network, the key generator comprising one or more QS server(s), each QS server comprising a hardware security module "HSM" for storing an identical set of quantum distributed "QD" keys, said identical set of QD keys having been distributed to each of said QS server(s) in a quantum-safe manner, and said QS server(s) configured to communicate securely with each other and the digital counterpart ledger using one or more available QD keys from the identical set of QD keys, and to provide a QD key to the digital counterpart ledger as the second key.

[0032] In embodiments of the second aspect, the first key and / or the second key may be a symmetric encryption key. For example, the key may be a 256-bit key suitable for AES-256 encryption. This has the advantage that the same key generator can be used for obtaining unique document identifiers and for encrypting transaction document data.

[0033] In embodiments of the second aspect, obtaining the unique document identifier may comprise calculating a first hash based on the first key. Furthermore, obtaining the unique document identifier further may comprise calculating a second hash based on the transaction data and the first hash. Using a hash function improves security, by making it more difficult for a third party to predict a valid document identifier for a given transaction document, reducing the risk of forgery. Additionally, in a case where the key generator is not entirely trusted, the hash calculation ensures that the key generator does not have direct access to the unique document identifier.

[0034] In embodiments of the second aspect, the digital counterpart ledger may be a distributed ledger comprising a plurality of ledger instances. A plurality of ledger instances protects against data loss. Additionally, in embodiments where different ledger instances are controlled by different parties, a process of consensus between the ledger instances can be used to reduce the risk of errors and / or forgeries.

[0035] In some embodiments of the second aspect, the method may further comprise: a digital counterpart retriever obtaining the digital counterpart for a physical transaction document from the digital counterpart ledger based on the unique document identifier of the physical transaction document. Furthermore, the method may comprise: the digital counterpart retriever displaying the transaction data of the digital counterpart for comparison to the physical transaction document.

[0036] In some embodiments of the second aspect, producing the physical transaction document based on the digital counterpart comprises printing the physical transaction document, wherein the printed physical transaction document comprises a machine-readable code, wherein the machine-readable code includes information for obtaining the digital counterpart of the physical transaction document; and the digital counterpart retriever comprises a scanner configured to read the machine-readable code. For example, the information for obtaining the digital counterpart of the physical transaction document may comprise the unique document identifier. Each of these implementations of a digital counterpart retriever provides a suitable interface for user to verify a physical transaction document by comparison to its digital counterpart.

[0037] In some embodiments of the second aspect, for a first physical transaction document of the plurality of physical transaction documents, generating the physical transaction document coprises: obtaining a first key from the key generator; obtaining a first set of transaction data; obtaining a second set of transaction data; obtaining a unique document identifier based on the first key; generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier, the first set of transaction data and the second set of transaction data; producing the physical transaction document based on the digital counterpart, wherein the physical transaction document comprises the first set of transaction data and the unique document identifier, and the second set of transaction data is omitted from the physical transaction document; and adding the digital counterpart to the digital counterpart ledger. Furthermore, the method may comprise a digital counterpart retriever obtaining the digital counterpart for a physical transaction document from the digital counterpart ledger based on the unique document identifier, wherein the digital counterpart retriever is configured to provide the first set of transaction data and the second set of transaction data of the digital counterpart to a user. Furthermore, the method may comprise the digital counterpart retriever: determining a read access level of the user, wherein the read access level is a basic read access level or an enhanced read access level; and if the read access level is the basic read access level, providing the first set of transaction data of the digital counterpart to the user and omitting providing the second set of transaction data of the digital counterpart to the user; and if the read access level is the enhanced read access level, providing the first set of transaction data and the second set of transaction data of the digital counterpart to the user. The first set of transaction data or the second set of transaction data may comprise user privilege data, wherein the user privilege data identifies one or more users having the enhanced read access level.

[0038] In such embodiments, additional transaction data is associated with the transaction document, beyond the data that is actually shown on the physical transaction document. This provides a mechanism for maintaining more detailed transaction records and securely linking those records to the physical transaction document, without requiring that the detailed records are available to everyone who can see the physical transaction document. Additionally, access to the detailed transaction records can be limited to specific users or user groups.

[0039] In some embodiments of the second aspect, the digital counterpart may further comprise a state of the physical transaction document, the state indicating whether the physical transaction document has been produced. This enables control of how many copies of the physical transaction document can exist. In many applications, the number of copies is limited to one.

[0040] In some embodiments of the second aspect, the method may comprise a check-in means verifying destruction of a physical transaction document. This enables control of how many copies of the physical transaction document can exist at any given time, without requiring that the physical transaction document is held and carefully preserved by the user over time.

[0041] According to a third aspect, the application provides a computer-implemented method for verifying a physical transaction document, wherein the physical transaction document comprises transaction information and security information, the method comprising: obtaining a unique document identifier, wherein the unique document identifier is included in the security information of the physical transaction document; sending a digital counterpart request to a digital counterpart ledger, the request comprising the unique document identifier and requesting access to a digital counterpart that is stored at the digital counterpart ledger in association with the unique document identifier, the digital counterpart comprising transaction information; receiving a digital counterpart request response, wherein the digital counterpart request response comprises at least a part of the transaction information of the digital counterpart.

[0042] In some embodiments, the method of the third aspect further comprises: obtaining the transaction information from the physical transaction document; and determining whether the transaction information from the physical transaction document matches the at least part of the transaction information of the digital counterpart.

[0043] According to a fourth aspect, the application provides a computer-implemented method for securely using and storing a physical transaction document, wherein the physical transaction document comprises transaction information and security information, the method comprising: at a digital counterpart retriever, sending a digital counterpart request to a digital counterpart ledger, the request comprising the unique document identifier and requesting to produce a physical transaction document corresponding to a digital counterpart that is stored at the digital counterpart ledger; at the digital counterpart ledger, verifying that a user of the digital counterpart retriever is permitted to produce the physical transaction document and transmitting data of the digital counterpart to a physical production device; at the physical production device, producing the physical transaction document for the user; at a secure check-in system, after the user has finished using the transaction document, receiving the physical transaction document, verifying the transaction document using the digital counterpart ledger, and destroying the physical transaction document.

[0044] In some embodiments, the method of the fourth aspect further comprises: at the physical production device, transmitting a production confirmation message to the digital counterpart ledgerafter producing the physical transaction document; at the digital counterpart ledger, in response to the production confirmation message, recording a checked-out state in association with the digital counterpart; at the secure check-in system, transmitting a destruction confirmation message to the digital counterpart ledger after destroying the physical transaction document; at the digital counterpart ledger, in response to the destruction confirmation message, removing the checked-out state in association with the digital counterpart, wherein verifying that a user of the digital counterpart retriever is permitted to produce the physical transaction document comprises determining that there is no checked-out state associated with the digital counterpart.

[0045] According to a fifth aspect, the application provides a storage medium storing computer program instructions which, when executed by a processor, cause the processor to perform a method according to any of the second, third and fourth aspects.

[0046] According to a sixth aspect, the application provides a computer program comprising instructions which, when executed by a processor, cause the processor to perform a method according to any of the second, third and fourth aspects.

[0047] According to a seventh aspect, the application provides a data signal comprising instructions which, when executed by a processor, cause the processor to perform a method according to any of the second, third and fourth aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 schematically illustrates a supply chain financing method;

[0049] Figure 2 schematically illustrates a verifiable transaction document;

[0050] Figure 3 schematically illustrates a system according to the invention;

[0051] Figure 4 schematically illustrates a method according to the invention;

[0052] Figure 5 schematically illustrates a method of generating a verifiable transaction document;

[0053] Figures 6A and 6B schematically illustrates quantum-safe systems for generating verifiable transaction documents;

[0054] Figure 7 schematically illustrates a method of verifying or producing a physical transaction document based on a digital counterpart;

[0055] Figure 8 schematically illustrates a method of updating a physical transaction document having a digital counterpart;

[0056] Figure 9 schematically illustrates an example architecture of a computer-implemented system for generating verifiable physical transaction documents. DETAILED DESCRIPTION

[0057] Figure 1 schematically illustrates a supply chain financing method in which embodiments of the invention may be used.

[0058] Referring to Figure 1, supply chain financing (SCF) may be used to facilitate a commerce transaction between a buyer 110 and a supplier 120. Rather than the buyer 110 paying the supplier 120 directly, the buyer 110 may instead initiate an SCF transaction by issuing a transaction document such as a bill of exchange or a promissory note. An investor 140 purchases the transaction document, providing financing to complete the commerce transaction. In return, the buyer 110 is committed to paying the investor 140 at a later date in order to complete the SCF transaction. In many cases, the supply chain financing is coordinated by an SCF coordinator 130, although the SCF coordinator could simply be one of the parties (the buyer 110, the supplier 120 or the investor 140).

[0059] Referring to the example method of Figure 1, at step 101, the supplier 120 provides an agreed service to the buyer 110 and sends an invoice. At step 102a or 102b, the buyer 110 or supplier 120 contacts the SCF coordinator 130 to arrange for payment of the invoice.

[0060] At step 103, the SCF coordinator 130 generates a transaction document having a sale value suitable for paying the invoice, identifies a suitable investor 140 and sells the transaction document to the investor 140. The SCF coordinator 130 may, for example, operate a market in which transaction documents are advertised for sale. The sale value is the price at which the transaction document is sold to the investor 140, and may be different from the repayment value.

[0061] At step 104, the SCF coordinator pays the buyer 110 based on the sale value of the sold transaction document. For example (and as shown in Figure 1) the SCF coordinator may directly pay the supplier 120 on behalf of the buyer 110, based on the invoice for the original transaction between the buyer 110 and the supplier 120.

[0062] At step 105, at the repayment date, the buyer 110 pays the repayment value to the investor 140. Finally (and optionally) at step 106a or 106b, the buyer 110 or the investor 140 informs the SCF coordinator 130 that the SCF transaction is complete.

[0063] In other embodiments, rather than an SCF transaction, the transaction document may relate to another type of transaction, such as a simple payment, a value transfer, an escrow agreement. As another example, the transaction document may relate to escrow agreement support upon bankruptcy.

[0064] Transaction documents used for purposes such as supply chain financing need to be trusted. For example, the investor 140 needs to be confident that they will receive the repayment value, and the buyer 110 needs to be confident that transaction documents cannot be produced in their name without their consent. In the following, technical solutions are described which can support that trust.

[0065] Figure 2 schematically illustrates a verifiable transaction document. Figure 3 schematically illustrates a computer-implemented system for generating verifiable physical transaction documents. Figure 4 schematically illustrates steps of a corresponding method for generating verifiable physical transaction documents.

[0066] Referring to Figure 2, verifiable transaction documents comprise transaction information 210 and security information 220.

[0067] The transaction information 210 depends upon the type of the transaction and may, for example, define the terms of a transaction (in this case the SCF transaction). For example, the transaction information for an SCF transaction typically includes at least: information about a repayment value to be paid to the owner of the transaction document; and the party responsible for paying the repayment value. In the example of Figure 2, the transaction information additionally includes further example transaction information fields: a repayment date; a transaction document type ("bill of exchange"), a transaction document issuer ("ourselves") and recipient of the repayment value ("international investor entity"). The transaction information in Figure 2 is intended as a hypothetical example, and is not indicative of a real transaction or real companies.

[0068] The security information 220 may comprise, for example, a unique identifier for the transaction document. The unique identifier may be used to inhibit re-use or duplication of the transaction document. The unique identifier may be generated through a secure process such as a computer-implemented algorithm known only to the SCF coordinator 130, in order to inhibit forgery of transaction documents. In the physical transaction document, the unique identifier may be provided in a human-readable form (such as alphanumeric text) and / or a machine-readable form (such as a bar code or QR code).

[0069] Referring to Figure 3, the system comprises a key generator 310, a document generator 320 and a digital counterpart ledger 330. The key generator 310, document generator 320 and digital counterpart ledger 330 communicate with each other via communication links which may be direct links or may be links via one or more networks. Each of the key generator 310, document generator 320 and digital counterpart ledger 330 may comprise multiple instances, and each time a document is generated, this may be performed by a random combination of one of the key generator instances, one of the document generator instances and at least one of the digital counterpart ledger instances.

[0070] The key generator 310 is configured to generate keys. The keys may be, for example, digital values. For example, the keys may be 256-bit values suitable for AES-256 encryption. The keys are preferably generated in a random or pseudo-random process. For example, the keys may be generated by sampling a noise signal. For example, the key generator may be configured to generate random entropy which can be formed into keys of a suitable length. The key generator may, for example, comprise a hardware random number generator, such as a true random number generator or a quantum random number generator (QRNG) or a NIST-approved source of secure randomness. The key generator 310 may, in some embodiments, comprise multiple random number generators. The multiple random number generators may be located at different nodes in a network. The key generator 310 may be configured to randomly choose between multiple random number generators in order to generate a random number or in order to generate a key.

[0071] The document generator 320 is configured to generate transaction documents. Each transaction document is generated as a physical transaction document and as a digital counterpart, where the digital counterpart includes at least the information contained in the physical transaction document.

[0072] In some embodiments, the key generator 310 may be controlled by a first transaction document generation party and the document generator 320 may be controlled by a second transaction document generation party, where the transaction document generation parties are independent from the transaction parties (e.g. a buyer and an investor) and are independent from each other.

[0073] Specifically, the physical transaction document and digital counterpart each include: transaction information comprising at least a first set of transaction data; and security information comprising a unique document identifier.

[0074] The digital counterpart may further include a second set of transaction data beyond what is included in the physical transaction document.

[0075] For example, referring to the example of Figure 1, the first set of transaction data may comprise information about the SCF transaction between the buyer 110 and the investor 140, while the second set of transaction data may comprise information about the commerce transaction between the buyer 110 and the supplier 120 that is facilitated by the SCF transaction.

[0076] Referring again to Figure 3, the functions of the document generator 320 may be broken down conceptually into three parts: ID obtaining 321, digital generation 322 and physical production 323. ID obtaining

[0077] In ID obtaining 321, the document generator 320 obtains a key from the key generator 310, and obtains a unique document identifier suitable for a transaction document based on the key. In a simple case, the unique document identifier may be the same as the key. However, the unique document identifier is preferably calculated using a hash operation based on the key. For example, the unique document identifier may be a digital signature.

[0078] In one case, the hash operation may comprise applying a first predetermined hash function to the key to obtain the unique document identifier.

[0079] In another case, the hash operation may be additionally based on all of, or part of, the first set of transaction data and / or all of, or part of, the second set of transaction data. The hash operation may, for example, comprise a first stage and a second stage. In the first stage, a first predetermined hash function is applied to the key, in order to obtain a first hash value. In the second stage, a second predetermined hash function is applied to a combination of the first hash value with all of, or part of, the first set of transaction data and / or all of, or part of, the second set of transaction data, in order to obtain the unique document identifier.

[0080] At least one of the key generator 310 and the document generator 320 are configured to ensure (to an acceptable degree of certainty) that the document identifier is unique.

[0081] In one embodiment, the key generator 310 may be configured to verify that each generated key is unique (e.g. verify that the key has never been generated before by the key generator 310). This may be implemented by storing all previously generated keys, and checking that each generated key is different from all stored keys. Alternatively, the key generator 310 may be configured to generate keys using a method in which generating the same key twice is extremely unlikely. For example, if the number of possible key values that could be generated by the key generator 310 is orders of magnitude larger than the total number of keys which are expected to be generated in the lifetime of the system, then it may be reasonable to expect that all of the generated keys will be unique, without needing verification of their uniqueness.

[0082] Additionally or alternatively, the ID obtaining functionality 321 of the document generator 320 may include features configured to verify that each obtained document identifier is unique. This may be implemented by storing all previously generated document identifiers, and checking that each obtained document identifier is different from all stored document identifiers. Digital generation

[0083] In digital generation 322, the document generator 320 generates the digital counterpart. The digital counterpart is a data object comprising the transaction information and the security information.

[0084] The transaction information included with the digital counterpart may also comprise an image of the physical transaction document. The image of the physical transaction document may contain information that is not otherwise represented in the digital counterpart. For example, in cases where the physical transaction document has received an official stamp, the official stamp may be shown in the image.

[0085] The document generator 320 may store the digital counterpart as a computer file including the transaction information and the security information. For example, the digital counterpart may be stored as a PDF document (especially when the transaction information includes an image of the physical transaction document), and / or may be stored in a structured or semi-structured data format (such as an individual JSON file, or an entry in a larger JSON file comprising digital counterparts corresponding to multiple physical transaction documents). Physical production

[0086] In physical production 323, the document generator 320 produces a physical transaction document based on the digital counterpart.

[0087] In a simple example, the document generator 320 may comprise a generic printer which can receive the digital counterpart as a PDF file and print the physical transaction document. The physical transaction document may be printed on paper or another suitable media.

[0088] However, more preferably, the document generator 320 comprises means specifically configured for producing the physical transaction document. For example, the document generator 320 may add anti-copying elements such as a hologram or a ELIRion constellation when producing the physical transaction document. Additionally, the document generator 320 may add a further signature when producing the physical transaction document. For example, the physical transaction document may include a hash of production information about how the physical transaction document was produced, such as a time or place of production or a device identifier identifying the hardware which produced the physical transaction document. The security information 220 included on the physical transaction document may include a hash of the unique document identifier and the production information. Alternatively, the security information 220 may simply comprise the unique document identifier.

[0089] In one embodiment, the digital counterpart comprises a state of the physical transaction document such as: 1) either "not yet produced" or "produced", or 2) either "checked out" or "checked in". Additionally, the digital counterpart may comprise production information about how the physical transaction document was produced, such as a time or place of production or a device identifier identifying the hardware which produced the physical transaction document.

[0090] In the example 1), in which the state of the physical transaction document is either "not yet produced" or "produced", the document generator 320 and / or the digital counterpart ledger 330 may be configured to only permit production the physical transaction document once. After the physical transaction document is produced once, the state of the physical transaction document is updated in the digital counterpart to "produced". This ensures that duplicate physical copies of the transaction document cannot exist.

[0091] Alternatively, in example 2), in which the state of the physical transaction document is either "checked out" or "checked in", the document generator 320 and / or the digital counterpart ledger 330 may comprise means for "checking out" and "checking in" the physical transaction document. When the physical transaction document has been produced, the state of the physical transaction document is updated to "checked out". Subsequently, when the document generator 320 and / or the digital counterpart ledger 330 receives an indication that the physical transaction document no longer exists, the state of the physical transaction document is updated to "checked in".

[0092] The system may further comprise a secure check-in system (which may be a single device or may comprise multiple devices) configured to receive, read, optionally verify, and destroy a physical transaction document as part of a "checking in" process. This may for example be implemented using a combination of scanner and shredder hardware. This has the advantage that the transaction document can subsequently be reproduced at a different time or place, while still preventing multiple copies from simultaneously existing. For example, a business which issues physical transaction documents may have multiple locations, each of which supports secure "check out" and "check in" of the physical transaction document.

[0093] In the event that the physical transaction document is lost, the physical transaction document may be invalidated. Invalidation may comprise destroying the physical transaction document, and marking the digital counterpart of the transaction document as invalid in the digital counterpart ledger 330. Alternatively, a third-party record of the digital counterpart may be used as independent evidence for the need to generate a new physical transaction document to replace the lost transaction document. Optional modularity

[0094] The above-mentioned functions of the document generator 320 (ID generation 321, digital generation 322 and physical production 323) may be implemented as two or more separate hardware or software modules, or a single device or single software program may be configured to perform all three functions. The functions of the document generator 320 may be distributed across multiple devices at multiple locations.

[0095] As one example, in some embodiments, physical production 323 of transaction documents is performed separately from ID generation 321 and digital generation 322. This may enable physical production to occur at a user's local document production device (e.g. printer) while ID generation 321 and digital generation 322 are performed in a secure system.

[0096] When a user's local document production device is to be used, the user may authorize the document generator 320 to directly control their local document production device. This may be used to ensure security by denying the user control of a digital copy of the data included in the physical transaction document. Document generation method

[0097] Figure 4 schematically illustrates an alternative embodiment in which a method is performed for generating verifiable physical transaction documents.

[0098] The steps of this method may be performed in any computer implementation. For example, the steps of the method may be stored as computer-readable instructions which can be executed by one or more processors. The computer-readable instructions may collectively form a self-contained computer program or a component (e.g. library, DLL) suitable for execution as part of a computer program. The computer-readable instructions may be stored in a memory, such as an internal volatile or non-volatile memory of a computer, or in an external memory device such as a flash drive or CD. The computer-readable instructions may be transmitted as a data signal, for example in order to download or upload the instructions from / to a network location. Alternatively, the steps of this method may be implemented in hardware, for example as one or more ASIC elements.

[0099] Referring to Figure 4, at step 401, the computer implementation obtains a key from a key generator. At step 402, the computer implementation obtains transaction data. At step 403, the computer implementation obtains a unique document identifier based on the key (and optionally further based on the transaction data). At step 404, the computer implementation generates a digital counterpart of the physical transaction document. At step 405, the computer implementation produces the physical transaction document. At step 406 (which may be performed before, after, or in parallel with step 405), the computer implementation adds the digital counterpart to a digital counterpart ledger.

[0100] The method of Figure 4 may be implemented similarly to the three functions (ID generation 321, digital generation 322 and physical production 323) described above. Digital ledger

[0101] The digital counterpart ledger 330 is configured to receive and store a digital counterpart of each physical transaction document generated by the document generator 320 or generated according to the method of Figure 4. The digital counterpart ledger 330 is also configured to provide read access to the digital counterparts stored in the ledger, for use in verifying the corresponding physical transaction document.

[0102] Data may be stored in the digital counterpart ledger 330 in any manner. For example, data may be stored in a database or in a file store.

[0103] The digital counterpart ledger 330 may be a fully immutable ledger, in which digital counterparts are never deleted and cannot be modified or overwritten after they have been initially added to the ledger. In some embodiments, the digital counterpart ledger 330 may additionally store some mutable data (such as a state of the physical transaction document, as discussed above), or the digital counterpart ledger 330 may permit the addition of subsequent immutable data to a digital counterpart (such as state transition events recording changes in the state of the physical transaction document).

[0104] The digital counterpart ledger 330 may implement access controls to limit who can retrieve copies of the digital counterparts. For example, access to a digital counterpart may be limited to parties with an interest in the corresponding physical transaction document (e.g. a buyer 110, a supplier 120, an investor 140 and / or an SCF coordinator 130). The digital counterpart ledger 330 may support different levels of access to different parts of the digital counterpart. For example, the digital counterpart ledger 330 could allow all relevant financial institutions and official entities access to the above-described first set of transaction data (e.g. data regarding an SCF transaction), and only allow the parties with an interest (e.g. a buyer 110, a supplier 120, an investor 140 and / or an SCF coordinator 130) to access the abovedescribed second set of transaction data (e.g. data regarding an underlying commerce transaction). This may, for example, enable financial institutions and / or officials to verify authenticity of a physical transaction document when it is presented, without giving wide access to information about an underlying commercial transaction.

[0105] The digital counterpart ledger 330 may be implemented as any type of secure ledger for storing data.

[0106] In some embodiments, the digital counterpart ledger 330 may be controlled by a third transaction document generation party that is independent from first and second transaction document generation parties that control the key generator 310 and the document generator 320 may be controlled by a second transaction document generation party, and is independent from the transaction parties (e.g. a buyer and an investor).

[0107] Advantageously, the digital counterpart ledger 330 may be stored as multiple copies (i.e. multiple ledger instances). This reduces the risk of losing records in case of an error or malfunction. A consensus algorithm may be used to maintain consistency between copies of the ledger. Two, three or more instances of the ledger may be controlled by independent parties, in order to increase the trustworthiness of the digital counterpart ledger 330.

[0108] For example, the digital counterpart ledger 330 may be implemented as a distributed ledger that uses a consensus algorithm (such as blockchain) to reach consensus between a plurality of ledger instances. In embodiments where the digital counterpart ledger 330 comprises non-public data, the ledger data may be distributed in an encrypted form and consensus may be implemented based on the encrypted ledger data, with decryption only occurring when a permitted party accesses the data.

[0109] One or more ledger instances, or one or more digital counterparts from a ledger instance, may be stored in a physical storage medium. The physical storage medium may be permanently, or intermittently, disconnected from other ledger instances in the digital counterpart ledger 330. For example, a local copy of a ledger may be maintained at a customs office or other physical location that needs to be able to verify physical transaction documents using the digital counterpart ledger 330.

[0110] The digital counterpart ledger 330 may be configured to obtain keys from the key generator 310. For example, when the digital counterpart ledger 330 adds a digital counterpart to the ledger, the digital counterpart ledger 330 may obtain a further key from the key generator 310, encrypt the digital counterpart using the further key, and store the encrypted digital counterpart in the ledger. Optional flags

[0111] In some embodiments, the transaction document may support a state in which the transaction document has been generated, but has not yet been approved for by one or more of the party(s) to the transaction. For example, the transaction document may require approval by an investor 140. A digital counterpart of the transaction document may nevertheless be stored in the digital counterpart ledger 330. For example, the digital counterpart may comprise an ISSUED flag, indicating either that the transaction document has been formally issued or that the transaction document is not yet approved by all necessary parties. The "not formally issued" state may instead be referred to as a "draft" state. If a transaction document is not formally issued, the digital counterpart ledger 330 and / or the transaction parties may mark the transaction document with a cancelled or rejected state. This may occur automatically if a threshold time passes after generation of the transaction document without it being formally issued.

[0112] In some embodiments, the transaction document may support a state in which the transaction document is disputed. For example, in the case of a bill of exchange, an owed amount may remain unpaid after a repayment date, and a buyer 110 may instead have chosen to formally protest the bill of exchange. In such embodiments, the digital counterpart may comprise a PROTEST flag (or, more generally, a DISPUTED flag), indicating whether the transaction document is disputed. Example application

[0113] Figure 5 schematically illustrates using the system of Figure 3 to facilitate the SCF scenario shown in Figure 1. The interactions between the document generator 320, the key generator 310 and the digital counterpart ledger 330 in Figure 5 are equally applicable to any transaction that is tracked using a system according to Figure 3.

[0114] As mentioned above, at Figure 1 step 103, the SCF coordinator 130 generates a transaction document having a sale value suitable for paying the invoice, identifies a suitable investor 140 and sells the transaction document to the investor 140.

[0115] Step 103 may be implemented using the steps shown in Figure 5.

[0116] At step 501, the SCF coordinator 130 communicates with an investor 140 to obtain their agreement to participate in the SCF transaction and to create a corresponding physical transaction document and digital counterpart. For example, the SCF coordinator 130 may advertise the potential SCF transaction as an investment opportunity, and wait for a response from an investor.

[0117] At step 502, the SCF coordinator 130 provides transaction information about the agreed transaction to the document generator 320. For example, this transaction information may comprise the above-mentioned first set of transaction data comprising information about the SCF transaction between the buyer 110 and the investor 140 and / or the above-mentioned second set of transaction data comprising information about the commerce transaction between the buyer 110 and the supplier 120 that is facilitated by the SCF transaction. In response to receiving (i.e. obtaining) the transaction information, the document generator 320 performs the rest of a method of generating a verifiable physical transaction document.

[0118] At step 503, the document generator 320 obtains a key from the key generator 310. The key obtaining step that is performed by the document generator 320 (or performed in step 401 of Figure 4) may be performed in response to receiving transaction information or otherwise commencing a document generation process, or the key obtaining step may be performed pre-emptively. For example, the document generator 320 may maintain a store of one or more unused keys ready for generating transaction documents, and may refill this store by obtaining keys from the key generator 310.

[0119] At step 504, the document generator obtains a unique document identifier based on a previously-unused key and generates the digital counterpart of the physical transaction document.

[0120] However, in this example, the document generator 320 does not yet add the digital counterpart to the ledger 330. Instead, the transaction document is first submitted for approval by the investor 140 (As mentioned above, in alternative embodiments, the transaction document may be added to the ledger 330 prior to approval, with the digital counterpart optionally including a "draft" or "not yet issued" flag.)

[0121] Specifically, at step 505, the document generator 320 sends the SCF coordinator 130 a provisional copy of the digital counterpart of the physical transaction document. Then, at step 506, the SCF coordinator 130 communicates with the investor 140 to obtain their approval based on the provisional copy. This additional approval is intended to reduce the risk of unapproved transaction documents appearing in the digital counterpart ledger 330. After obtaining the investor's approval, at step 507 the SCF coordinator 130 instructs the document generator 320 to add the digital counterpart to the digital counterpart ledger 330 (step 508) and to enable production of the physical transaction document (which may be implemented as immediate production, or as later production at a time desired by the investor 140).

[0122] On the other hand, if the investor 140 refuses to approve the transaction document, then the document generator 320 can be instructed to discard the provisional digital counterpart. Nevertheless, the document generator 320 may ensure that the unique document identifier associated with the unapproved transaction document is not used for any subsequent transaction document. Quantum secure implementations

[0123] Figures 6Aand 6B schematically illustrate communication links in embodiments of the system of Figure 3.

[0124] Figures 6A and 6B additionally showa user terminal 610 which may communicate with the document generator 320. For example, the user terminal may send the document generator 320 an instruction to generate a transaction document. Additionally or alternatively, the document generator 320 may control production of a physical transaction document at the user's location, by controlling the user terminal 610 (usually after obtaining the user's permission).

[0125] The user terminal 610 may also communicate with the digital counterpart ledger 330. For example, the digital counterpart ledger 330 may provide a website interface for authorized parties to view digital counterparts of physical transaction documents.

[0126] Any communication link can be monitored by a third party, especially if the link goes via a public network. In the case of quantum communication channels (i.e. communication channels which are configured to preserve quantum states of objects (e.g. photons or electrons) travelling in the channel, where the quantum states indicate the transmitted data), such monitoring cannot be performed without it being detectable. In the case of classical communication channels, such monitoring can go undetected, but cryptanalysis is usually required in order to learn anything from the transmitted information.

[0127] Cryptanalysis (encryption breaking) can be a resource intensive process, but nevertheless can be achieved with enough time and with enough samples of data encrypted with the same encryption key, regardless of the encryption algorithm that is used. As such, all encryption keys need to be changed periodically, and the useful lifespan of a given encryption key depends upon how resistant the encryption algorithm is to third-party cryptanalysis.

[0128] Asymmetric encryption algorithms can be particularly vulnerable because, while each public-private key pair enables convenient "many-to-one" communication, this requires informing the "many" (which is often the general public) about which encryption / decryption algorithm is to be used and also informing the "many" of the public key parameters to be used in the encryption (these parameters generally having a defined mathematical relationship to the non-public private key parameters used for decryption) - this dramatically narrows the guesswork required for successful cryptanalysis and unauthorised decryption. For example, some asymmetric encryption algorithms such as RSA are known to be vulnerable to efficient cryptanalysis using quantum computing.

[0129] As such, it is desirable to provide an implementation in which the communication links of the system are less vulnerable to cryptanalysis using quantum computing. Herein, such implementations are denoted as "quantum secure implementations".

[0130] In Figures 6A and 6B, a part of each system embodiment is implemented with quantum secure communication links, as illustrated using the dashed boxes 620. In Figure 6A, the key generator 310 and the document generator 320 are configured to communicate with each other via a quantum secure communication link. In Figure 6B, the key generator 310, the document generator 320 and the digital counterpart ledger 330 are all configured to communicate with each other via quantum secure communication links.

[0131] As mentioned above, these quantum-secure communication links may be implemented using quantum communication channels. As an extra layer of security, the data transmitted over the quantum communication channel may optionally be encrypted data. However, quantum communication channels are generally significantly more expensive than classical communication channels, because of the requirement to preserve quantum states (which frequently requires cryogenic temperatures).

[0132] Another solution is to transmit data that has been encrypted using a quantum-secure method. Such methods may comprise the use of symmetric encryption.

[0133] Symmetric encryption algorithms have many security benefits. Third parties generally cannot even tell which encryption algorithm was used by looking at the encrypted data, let alone start with knowledge of any of the encryption / decryption parameters. The best available symmetric encryption algorithms such as AES are not known to be vulnerable to efficient cryptanalysis using existing classical or quantum computing techniques. However, symmetric encryption requires providing a shared private key to both parties, without allowing a third party to obtain the private key. As such, key distribution for symmetric encryption is more challenging compared to asymmetric encryptions (in which only a public key is distributed).

[0134] Referring again to Figures 6A and 6B, a quantum-safe encrypted link between the key generator 310 and the document generator 320 may be established using symmetric encryption and using keys generated by the key generator 310.

[0135] For example, a connection between the key generator 310 and the document generator 320 may include a quantum communication channel suitable for quantum key distribution QKD (e.g. using the BB84 protocol).

[0136] Once the key generator 310 and the document generator 320 have established a shared symmetric key using the quantum communication channel, the key generator 310 and the document generator 320 may communicate using a classical communication channel and symmetric encryption / decryption.

[0137] Preferably, however, the symmetric key is distributed in a quantum-safe manner to the key generator 310 and the document generator 320 without ever requiring a quantum communication channel. Techniques for symmetric key distribution without requiring a quantum communication channel are described in, for example, GB2106977.8, GB2101310.7, GB1916311.2 and GB2308078.1. In the technique of GB2308078.1, a hub node is provided which sends randomly generated data to each end node of an intended quantum secure link (e.g. the key generator 310 and the document generator 320). The two end nodes of the intended link perform an algorithm based on the received randomly generated data to establish a symmetric key known to the end nodes, but not known to the hub node.

[0138] Any of the above methods for establishing a symmetric key may be used in order to establish quantum-safe symmetric encrypted links between the key generator 310 and the document generator 320; between the document generator 320 and the digital counterpart ledger 330; and / or between the key generator 310 and the digital counterpart ledger 330, or between any other pair of entities in the system, to establish a quantum secure portion 620 of the system.

[0139] Additionally, any of the above methods may be used for updating symmetric keys used for quantum-safe symmetric encrypted links between the key generator 310 and the document generator 320; between the document generator 320 and the digital counterpart ledger 330; and / or between the key generator 310 and the digital counterpart ledger 330, or between any other pair of entities in the system. For example, in one embodiment, new symmetric keys are generated each time a document is generated, to replace the existing keys for the quantumsafe symmetric encrypted links. This helps to prevent attacks in the system, such as spoofing or man-in-the-middle attacks. Using the digital counterpart and producing the physical transaction document

[0140] Figure 7 schematically illustrates a method of verifying or producing a physical transaction document based on a digital counterpart.

[0141] Referring to Figure 7, at step 701 a user requests access to a digital counterpart from the digital counterpart ledger 330 via a digital counterpart retriever 710 (which may be a user terminal 610). The digital counterpart retriever may, for example, be any type of local device such as a laptop or smartphone. The digital counterpart retriever 710 may be specifically configured to access the digital counterpart ledger 330, for example using a computer program installed on the digital counterpart retriever 710. Alternatively, the digital counterpart retriever 710 may initiate contact with the digital counterpart ledger 330 using a generic interface such as a browser which can render a website provided by the digital counterpart ledger 330. In the request, the digital counterpart may be identified using its unique identifier. For example, the request may comprise an image scan of a physical transaction document 200 including the security information 220, or may comprise the unique identifier obtained by a scanning element of the digital counterpart retriever 710 (e.g. a local QR code reader).

[0142] Step 701 may comprise the user providing personal information such as login details, to confirm their identity and authenticate their access to the digital counterpart ledger. The user may be, for example, a party to the physical transaction document having the requested digital counterpart, ora potential buyer of the physical transaction document. Alternatively, the user may be a member of a financial institution or a public official authorized to access the digital counterpart ledger 330. In some embodiments, the digital counterpart ledger may accept requests from anyone, without performing access control.

[0143] The request of step 701 may be a request to view the digital counterpart. If the request is a request to view the digital counterpart then, after verifying that the user has the necessary level of access, at step 702, the digital counterpart ledger 330 transmits a response to the digital counterpart retriever 710 comprising some or all of the data of the digital counterpart. For example, the counterpart ledger 330 may provide an interface in which the user can browse the data to which they have access, or the counterpart ledger 330 may provide a PDF document comprising all data of the requested digital counterpart which is accessible by the user. As mentioned above, different users may have different access levels. For example, some users may have full access to the digital counterpart. For example, users having full access may be allowed to view the first set of transaction data described above (e.g. information about the supply chain financing transaction) and the second set of transaction data described above (e.g. information about an underlying commercial transaction facilitated by the SCF transaction). Other users may only have partial access to the digital counterpart. For example, users with partial access may be only allowed to view the first set of transaction data.

[0144] The digital counterpart retriever 710 may be further configured to automatically perform a verification method. For example, the digital counterpart retriever 710 may obtain transaction data from an image scan of the physical transaction document and compare the obtained transaction data to some or all of the data of the digital counterpart.

[0145] Alternatively, the request of step 701 may be a request to produce the physical transaction document. If the request is a request to produce the physical transaction document then, after verifying that the user has the necessary level of access and verifying that production of the physical transaction document is permitted, at step 703 the digital counterpart ledger 330 transmits data of the digital counterpart to a physical production device 720. The physical production device 720 may be implemented in the same way as any of the means described above for the physical production function 323 of the document generator 320. For example, the physical production device 720 may be a user's local document production device, located nearby to the digital counterpart retriever 710. Modification of the transaction document

[0146] As mentioned above, the physical transaction document may be modified. For example, the physical transaction document may receive an official stamp. In some embodiments, the digital counterpart may be similarly modified. For example, an image of the physical transaction document may be replaced with an updated image.

[0147] However, in some embodiments, the digital counterpart is stored in an immutable, unchangeable form upon completion of digital generation. In such embodiments, when a first physical transaction document is modified, it may be necessary to generate an entirely new second transaction document having a second physical transaction document and a second digital counterpart in order to reflect the modification to the physical transaction document. The second transaction document may replace the first transaction document.

[0148] Figure 8 schematically illustrates an example method of modifying or updating a physical transaction document having a digital counterpart. This example refers to the SCF scenario previously introduced in Figures 1 and 5, but the interactions between the document generator 320, the key generator 310 and the digital counterpart ledger 330 in Figure 8 are equally applicable to any transaction that is tracked using a system according to Figure 3.

[0149] At step 801, an investor 140 who owns a first physical transaction document contacts the digital counterpart ledger 330 to produce the first physical transaction document from its digital counterpart.

[0150] At step 802, the investor 140 allows the first physical transaction document to be modified, for example by applying an official stamp or annotating the physical transaction document with details of a transfer of ownership.

[0151] At step 803, the investor 140 contacts the SCF coordinator 130 to coordinate issuance of a second physical transaction document to replace the first physical transaction document, based on the modification. For example, the investor 140 may provide a scanned image of the modified first physical transaction document to be used when generating the second physical transaction document. The SCF coordinator then contacts the document generator 320 at step 804 to request generation of the second physical transaction document. In alternative embodiments, the SCF coordinator 130 may be unnecessary for an update procedure, and the investor 140 (or another owner of the physical transaction document) may contact the document generator 320 directly.

[0152] Steps 805 to 809 are largely similar to steps 503 to 507 as shown in Figure 5 and described above for generating an entirely new physical transaction document. However, in the case of generating a second physical transaction document based on a modified first physical transaction document, data of the modified first physical transaction document is used in step 806 when generating the digital counterpart of the second physical transaction document.

[0153] In the digital counterpart of the second physical transaction document, at least some data of the first physical transaction document may be included and labelled as "old" or "modified" data. Additionally or alternatively, an image of the modified and / or original first physical transaction document may be included as part of the digital counterpart of the second physical transaction document. This image may, for example, be retained as an additional page of a PDF format of the digital counterpart.

[0154] For example, a scanned image of the first physical transaction document may be included when generating the digital counterpart of the second transaction document, and the second physical transaction document may be generated based on this image. In other words, where the first physical transaction document has received an official stamp, the second physical transaction document may include a printed reproduction of the official stamp.

[0155] Notably, in steps 805 and 806, the second physical transaction document is generated with its own unique document identifier, which is different from the unique document identifier of the first physical transaction document.

[0156] After obtaining the investor's approval at step 808 (corresponding to step 506 of Figure 5), at step 809 the SCF coordinator 130 instructs the document generator 320 to finalize the modification / update. At step 810, the document generator 320 finalizes the modification / update, by: a) adding the digital counterpart of the second physical transaction document to the digital counterpart ledger 330, and b) marking the digital counterpart of the first transaction document as invalid in the digital counterpart ledger 330.

[0157] Figure 9 schematically illustrates an example architecture of a computer-implemented system for generating verifiable physical transaction documents.

[0158] In this example, the key generator 310 is implemented using two or more Arqit Quantum Cloud nodes (a). The Quantum Cloud nodes may have an SDK interface for receiving key requests and delivering keys to the document generator 320.

[0159] In this example, the document generator 320 is implemented using a plurality of document generation micro services, which run on one or more document generator nodes (b). Implementations which provide parallel services can, for example, be used to perform multiple document generation processes in parallel.

[0160] In this example, the digital counterpart ledger 330 comprises a plurality of ledger instances. These may, for example, be implemented on blockchain database nodes (d), such as Ethereum blockchain nodes. The document generator 320 may interact with the digital counterpart ledger 330 using a blockchain client.

[0161] In this example, an SCF coordinator 130 is shown as an element (f) of the system. The SCF coordinator 130 may be configured to exchange information with the document generator 320 in JSON format. JSON objects may be configured to define a request to mint a new transaction document, to confirm the result of minting a transaction document, and so on. In some embodiments, the SCF coordinator 130 may be configured to communicate with the document generator 320 and / or with the digital counterpart ledger 330 using a quantum communication channel and / or quantum-safe encryption. In other words, the SCF coordinator 130 may be provided with an interface to a quantum-secure portion 620 of the system.

[0162] In this example, the system further includes a web server (c) for viewing and / or interacting with transaction documents stored in the digital counterpart ledger 330.

[0163] Any of the computer entities (e.g. key generator 310, document generator 320, digital counterpart ledger 330, user terminal 610, digital counterpart retriever 710, physical production device 720) mentioned in the above-described methods may be implemented as two or more separate hardware or software modules, or a single device or single software program.

[0164] Any of the computer entities may comprise one or more processors configured to execute processing instructions and one or more memories storing processing instructions defining the respective steps performed by the computer entity in the above method. The processing instructions may be copiable, and may be additionally or alternatively stored on a non-transitory storage medium or transmitted in a data signal.

[0165] Additionally or alternatively, any of the computer entities may comprise hardware specifically configured to perform the respective steps performed by the computer entity in the above method. For example, the computer entity may comprise one or more application specific integrated chips (ASICs).

[0166] Although the above disclosure refers to specific types of transaction document, the described techniques are generally applicable to any transaction document, even if such transaction documents are not commonly handled in a physical form. For example, a transaction document may include: Digital Negotiable Instruments, examples which include bills of exchange; cheques; promissory notes; consignment notes; bills of lading; warehouse receipts; insurance certificates; and airwaybills. For example, the transaction document may be covered under the Model Law on Electronic Transferable Records (MLETR) law. A transaction document may also include E-Money, FIAT currencies, Digital Money, Crypto, CBDC, Bl DC digital assets.

Claims

1. A computer-implemented system for generating verifiable physical transaction documents, wherein each physical transaction document comprises transaction information and security information, the system comprising:a key generator configured to generate a plurality of keys;a document generator configured to generate a plurality of physical transaction documents; anda digital counterpart ledger configured to store a respective digital counterpart for each of the plurality of physical transaction documents, wherein the digital counterpart ledger is an immutable ledger,wherein the document generator is configured to generate each physical transaction document by:obtaining a first key from the key generator;obtaining transaction information;obtaining a unique document identifier based on the key;generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier and the transaction data;adding the digital counterpart to the digital counterpart ledger; and producing the physical transaction document based on the digital counterpart.

2. A system according to claim 1, wherein the key generator is configured to send keys to the document generator using a quantum communication channel and / or using a quantumsafe encryption.

3. A system according to claim 2, comprising a quantum-safe "QS" network including the key generator and the document generator, the key generator comprising one or more QS server(s), each QS server comprising a hardware security module "HSM" for storing an identical set of quantum distributed "QD" keys, said identical set of QD keys having been distributed to each of said QS server(s) in a quantum-safe manner, and said QS server(s) configured to communicate securely with each other and the document generator using one or more available QD keys from the identical set of QD keys, and to provide a respective different QD key to the document generator as the first key for generating each physical transaction document.

4. A system according to any of claims 1 to 3, wherein the document generator is configured to send the digital counterpart to the digital counterpart ledger using a quantum communication channel and / or using a quantum-safe encryption.

5. A system according to any of claims 1 to 4, wherein the key generator is configured to send keys to the digital counterpart ledger, and the digital counterpart ledger is configured to, for each physical transaction document:receive the digital counterpart from the document generator;obtain a second key from the key generator;encrypt the digital counterpart using the second key; and store the encrypted digital counterpart.

6. A system according to claim 5, wherein the key generator is configured to send keys to the digital counterpart ledger using a quantum communication channel and / or using a quantum-safe encryption.

7. A system according to claim 6, comprising a quantum-safe "QS" network including the key generator and the digital counterpart ledger, the key generator comprising one or more QS server(s), each QS server comprising a hardware security module "HSM" for storing an identical set of quantum distributed "QD" keys, said identical set of QD keys having been distributed to each of said QS server(s) in a quantum-safe manner, and said QS server(s) configured to communicate securely with each other and the digital counterpart ledger using one or more available QD keys from the identical set of QD keys, and to provide a respective different QD key to the digital counterpart ledger as the second key for generating each physical transaction document.

8. A system according to any preceding claim, wherein the first key and / or the second key is a symmetric encryption key.

9. A system according to any preceding claim, wherein obtaining the unique document identifier comprises calculating a first hash based on the first key.

10. A system according to claim 8, wherein obtaining the unique document identifier further comprises calculating a second hash based on the transaction data and the first hash.

11. A system according to any preceding claim, wherein the digital counterpart ledger is a distributed ledger comprising a plurality of ledger instances.

12. A system according to any preceding claim, further comprising a digital counterpart retriever configured to obtain the digital counterpart for a physical transaction document from the digital counterpart ledger based on the unique document identifier of the physical transaction document.

13. A system according to claim 12, wherein the digital counterpart retriever is further configured to display the transaction data of the digital counterpart for comparison to the physical transaction document.

14. A system according to claim 12 or claim 13, wherein:producing the physical transaction document based on the digital counterpart comprises printing the physical transaction document, wherein the printed physical transaction document comprises a machine-readable code, wherein the machine-readable code includes information for obtaining the digital counterpart of the physical transaction document; andthe digital counterpart retriever comprises a scanner configured to read the machine-readable code.

15. A system according to claim 14, wherein the information for obtaining the digital counterpart of the physical transaction document comprises the unique document identifier.

16. A system according to any preceding claim wherein, for a first physical transaction document of the plurality of physical transaction documents, the document generator is configured to generate the physical transaction document by:obtaining a first key from the key generator;obtaining a first set of transaction data;obtaining a second set of transaction data;obtaining a unique document identifier based on the first key;generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier, the first set of transaction data and the second set of transaction data;producing the physical transaction document based on the digital counterpart, wherein the physical transaction document comprises the first set of transaction data and the unique document identifier, and the second set of transaction data is omitted from the physical transaction document; andadding the digital counterpart to the digital counterpart ledger.

17. A system according to claim 16, further comprising a digital counterpart retriever configured to obtain the digital counterpart for a physical transaction document from the digital counterpart ledger based on the unique document identifier, wherein the digital counterpart retriever is configured to provide the first set of transaction data and the second set of transaction data of the digital counterpart to a user.

18. A system according to claim 17, wherein the digital counterpart retriever is configured to:determine a read access level of the user, wherein the read access level is a basic read access level or an enhanced read access level; andif the read access level is the basic read access level, provide the first set of transaction data of the digital counterpart to the user and omit providing the second set of transaction data of the digital counterpart to the user; andif the read access level is the enhanced read access level, provide the first set of transaction data and the second set of transaction data of the digital counterpart to the user.

19. A system according to claim 18, wherein the first set of transaction data or the second set of transaction data comprises user privilege data, wherein the user privilege data identifies one or more users having the enhanced read access level.

20. A system according to any preceding claim, wherein the digital counterpart further comprises a state of the physical transaction document, the state indicating whether the physical transaction document has been produced.

21. A system according to any preceding claim, further comprising check-in means for verifying destruction of a physical transaction document.

22. A computer-implemented method for generating a verifiable physical transaction document, wherein the physical transaction document comprises transaction information and security information, the method comprising:obtaining a first key from a key generator;obtaining transaction information;obtaining a unique document identifier based on the key;generating a digital counterpart of the physical transaction document, the digital counterpart comprising the unique document identifier and the transaction data;adding the digital counterpart to a digital counterpart ledger; andproducing the physical transaction document based on the digital counterpart.

23. A computer-implemented method for verifying a physical transaction document, wherein the physical transaction document comprises transaction information and security information, the method comprising:obtaining a unique document identifier, wherein the unique document identifier is included in the security information of the physical transaction document;sending a digital counterpart request to a digital counterpart ledger, the request comprising the unique document identifier and requesting access to a digital counterpart that is stored at the digital counterpart ledger in association with the unique document identifier, the digital counterpart comprising transaction information;receiving a digital counterpart request response, wherein the digital counterpart request response comprises at least a part of the transaction information of the digital counterpart.

24. A method according to claim 23, further comprising:obtaining the transaction information from the physical transaction document; anddetermining whether the transaction information from the physical transaction document matches the at least part of the transaction information of the digital counterpart.

25. A computer-implemented method for securely using and storing a physical transaction document, wherein the physical transaction document comprises transaction information and security information, the method comprising:at a digital counterpart retriever, sending a digital counterpart request to a digital counterpart ledger, the request comprising the unique document identifier and requesting to produce a physical transaction document corresponding to a digital counterpart that is stored at the digital counterpart ledger;at the digital counterpart ledger, verifying that a user of the digital counterpart retriever is permitted to produce the physical transaction document and transmitting data of the digital counterpart to a physical production device;at the physical production device, producing the physical transaction document for the user;at a secure check-in system, after the user has finished using the transaction document, receiving the physical transaction document, verifying the transaction document using the digital counterpart ledger, and destroying the physical transaction document.

26. A method according to claim 25, further comprising:at the physical production device, transmitting a production confirmation message to the digital counterpart ledger after producing the physical transaction document;at the digital counterpart ledger, in response to the production confirmation message, recording a checked-out state in association with the digital counterpart;5 at the secure check-in system, transmitting a destruction confirmation message to thedigital counterpart ledger after destroying the physical transaction document;at the digital counterpart ledger, in response to the destruction confirmation message, removing the checked-out state in association with the digital counterpart,wherein verifying that a user of the digital counterpart retriever is permitted to produce 10 the physical transaction document comprises determining that there is no checked-out state associated with the digital counterpart.

27. A storage medium storing computer program instructions which, when executed by a processor, cause the processor to perform a method according to any of claims 22 to 25.15

Images