DETAILED ACTION
This is a non-final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 -45 in application 18/846261.
Claims 1, 2, 4-17, 20-37, and 42-45 are amended.
Claims 3, 18, 19, 38-41 are canceled.
Claims 1, 2, 4-17, 20-37, and 42-45 have been examined and are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4-17, 20-37, and 42-45 is/are rejected under 35 U.S.C. 103 as being unpatentable over Childe et al. (US20230360040A1) hereinafter Childe, in view of Gan (EP2795829B1), and in further view of Mee (WO2020212784A1).
Regarding Claim 1. Childe discloses (in BOLD):
A digital payment system, comprising: a payer communication device and a payee communication device, each having a short-range data communication interface, a broadband data communication interface and a trusted execution environment enabled for performing a predefined cryptographic operation;
Childe - a computer-implemented method of secure quantum safe (QS) payments using a quantum cloud payment platform and two or more endpoint devices (¶ 0016). a first end-point device 502 a of a first user 105 a (e.g. the first user is authorized to use or operate the first end-point device 502 a) and a second end-point device 502 b of a second user 105 b (e.g. the second user is authorized to use or operate the second end-point device 502 b) (Two distinct endpoint devices map to payer/payee device) (¶ 0280). The communications interface 502 b may include a transceiver, receiver and/or transmitter, and/or one or more input/output ports and the like for wireless and/or wired communication with a network and/or another computing device, end-point and the like (network/telecom connectivity = broadband interface) (¶ 0281). cryptographic key creation/generation/storage and processing; secure storage of cryptographic keys; performing cryptographic operations using the cryptographic keys and the like; trusted execution (¶ 0282). each device 502 a and 502 b may establish a communications path and connect with each other over a telecommunications network (device to device: short-range) (¶ 0326). secure processor/memory unit 503 d of the end-point device 502 a (e.g. a Secure Enclave, TrustZone, and the like) (Trusted Execution Environment)(¶ 0343).
a computerized payer account provider being a cloud-based computing resource capable of broadband data communication; and
Childe - the QS network comprising one or more QS server(s) and a distributed ledger technology (DLT) repository…users of the endpoint devices are registered with a QS payment account (¶ 0024).
a computerized payee account provider being a cloud-based computing resource capable of broadband data communication,
Childe – Thus, a first QS communication channel 504 is established using a QD key securely stored on the end-point device 502 (¶ 0313). QS payment system…transfers between participants of the QS payment system (¶ 0447).
wherein the trusted execution environment of the payer communication device comprises a first cryptographic key being a shared secret between the payer and payee communication devices, and a second cryptographic key,
Childe - sending the retrieved further QD key to the first and second devices 502 a and 502 b over a first and second QS communication channel 504 and 506 for use by the first and second devices 502 a and 502 b in forming a third QS communication channel (¶ 0340).
wherein the trusted execution environment of the payee communication device comprises said first cryptographic key being the shared secret between the payer and payee communication devices, and a third cryptographic key,
Childe - The second end-point device 502 b and the QS network 101 may establish a second QS communication channel 506 using a second QD key securely stored on the second end-point device 502 (¶ 0323).
wherein the payer communication device and the payee communication device are configured to negotiate payment details for an offline digital payment by exchanging a payment request and a payment response by short-range data communication,
Childe - An access operation may include, without limitation, for example queries (request/payment) in relation to the data item, updates in relation to the data item, retrieving information associated with the data item, answers to questions in relation to the data item and/or any other type of access operation associated with the data item (¶ 0135). each device 502 a and 502 b may establish a communications path and connect with each other over a telecommunications network (device to device: short-range) (¶ 0326).
wherein the negotiation involves the payer communication device: verifying the payment request by performing the predefined cryptographic operation based on payment- specific data included in the payment request as well as on the first cryptographic key and comparing with cryptographic data also included in the payment request and being the result of the payee communication device having performed the same predefined cryptographic operation based on said payment-specific data as well as on said first cryptographic key,
Childe - sending data representative of the received transaction or message and a QREF access token associated with a data item stored in the repository, the data item comprising a signing key for use in digitally signing the transaction or message; receiving a digitally signed transaction or digitally signed message comprising the transaction or message digitally signed using a digital signature algorithm based on the data item; sending the digitally signed transaction for further processing or storage (¶ 0703).
wherein the negotiation further involves the payee communication device verifying the payment response by performing the predefined cryptographic operation based on payment-specific data included in the payment response as well as on the first cryptographic key and comparing with cryptographic data also included in the payment response and being the result of the payer communication device having performed the same predefined cryptographic operation based on said payment-specific data as well as on said first cryptographic key, and
Childe - sending data representative of the received transaction or message and a QREF access token associated with a data item stored in the repository, the data item comprising a signing key for use in digitally signing the transaction or message; receiving a digitally signed transaction or digitally signed message comprising the transaction or message digitally signed using a digital signature algorithm based on the data item; sending the digitally signed transaction for further processing or storage (¶ 0703).
wherein at least one of the payer communication device and the payee communication device is configured to: upon successful verification of the payment request or the payment response, respectively, store the payment-specific data included in the payment response as negotiated payment details for the offline digital payment in the trusted execution environment, and
Childe - Each DLT node 166 a-166 f of the QS servers 103 a-103 c and/or QS servers of users 104 a-104 c may store and/or access an encrypted data item in a QS DLT record that is addressed using the QREF locator generated by a QS server 103 a-103 c during when the data item is stored in the QS DLT 167. The DLT record for storing a data item in the QS DLT 167 may include, without limitation, for example data representative of: QREF locator (e.g. QREF) generated for the data item; the data item (e.g. DATA_ITEM) or encrypted data item that is encrypted with an available QD key (e.g. QSKD_KEY) from the set of QD keys; access permissions such as create, read, write, modify and any other permission type (e.g. ACL_ROLE_ID); access control data (e.g. ACL_ID) such as, for example, user identifiers of the users (e.g. USER_ID or CUSTNUM) with permissions for accessing, in some manner, the data item; and/or any other data required for storing the data item in the QS DLT 167 (¶ 0233).
subsequently make a payment settlement request by broadband data communication with the computerized payer account provider or the computerized payee account provider, respectively, the payment settlement request including the stored negotiated payment details for the offline digital payment and being signed by the second cryptographic key or third cryptographic key, respectively.
Childe - QS payment transaction of a user comprising data representative of a payment value (¶ 0015). transmitting a quantum safe payment transaction to the quantum cloud platform, the QS payment transaction of a user comprising data representative of a payment value which is a fiat cash value or a digital currency value for transferring to another user of an endpoint device; receiving an indication of the number of quantum money tokens withdrawn from the QS payment account of the user of the endpoint device; and updating an electronic wallet of said user based on the indication (¶ 0018). the corresponding QREF access tokens associated with the set of signing keys may be sent to one or more systems (¶ 0414).
Childe does not teach, however Gan discloses the following (in BOLD):
wherein the negotiation involves the payer communication device: verifying the payment request by performing the predefined cryptographic operation based on payment- specific data included in the payment request as well as on the first cryptographic key and comparing with cryptographic data also included in the payment request and being the result of the payee communication device having performed the same predefined cryptographic operation based on said payment-specific data as well as on said first cryptographic key,
Gan - including instructions for memory handling, function calling, results comparison (¶ 0013). perform cryptographic operations, including storing, retrieving, and processing the cryptographic keys and data. These cryptographic operations may include publicly available cryptographic routines, including symmetric key cryptography such as AES, asymmetric key cryptographic such as RSA, hashing functions such as SHA-1, SHA-2, and HMAC, as well as pseudo-random number generation and key generation functions. This virtual machine may receive requests 106 from a plurality of client applications to perform these cryptographic operations by securely processing these cryptographic operations within the virtual machine and sending the results of these cryptographic operations as a response 107 back to the clients. This virtual machine may also be used to perform other non-cryptographic but security-critical processing functions (¶ 0012).
wherein the negotiation further involves the payee communication device verifying the payment response by performing the predefined cryptographic operation based on payment-specific data included in the payment response as well as on the first cryptographic key and comparing with cryptographic data also included in the payment response and being the result of the payer communication device having performed the same predefined cryptographic operation based on said payment-specific data as well as on said first cryptographic key, and
Gan - including instructions for memory handling, function calling, results comparison (¶ 0013). perform cryptographic operations, including storing, retrieving, and processing the cryptographic keys and data. These cryptographic operations may include publicly available cryptographic routines, including symmetric key cryptography such as AES, asymmetric key cryptographic such as RSA, hashing functions such as SHA-1, SHA-2, and HMAC, as well as pseudo-random number generation and key generation functions. This virtual machine may receive requests 106 from a plurality of client applications to perform these cryptographic operations by securely processing these cryptographic operations within the virtual machine and sending the results of these cryptographic operations as a response 107 back to the clients. This virtual machine may also be used to perform other non-cryptographic but security-critical processing functions (¶ 0012).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the two endpoint devices with a shared session key of Childe with the exact technological environment (request/response execution) of Gan because doing so reduces the man-in-the-middle risk and match common payment UX (tap-to-pay, transit).
The combination of Childe and Gan does not disclose, however Mee discloses (in BOLD):
wherein the payer communication device and the payee communication device are configured to negotiate payment details for an offline digital payment by exchanging a payment request and a payment response by short-range data communication,
Mee - notification may be sent to the payee entity regarding the request. This notification is sent even when the payee client is unavailable or offline (Page 6, lines 16 and 17).
wherein at least one of the payer communication device and the payee communication device is configured to: upon successful verification of the payment request or the payment response, respectively, store the payment-specific data included in the payment response as negotiated payment details for the offline digital payment in the trusted execution environment, and
Mee - notification may be sent to the payee entity regarding the request. This notification is sent even when the payee client is unavailable or offline (Page 6, lines 16 and 17).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the two endpoint devices with a shared session key of Childe and the exact technological environment (request/response execution) of Gan with the offline negotiation of Mee because doing so stores the authenticated negotiated payment details in the TEE and subsequently settled by broadband to payer/payee account providers with the settlement request being signed by the device keys which improves security, latency, and availability.
Regarding Claim 2. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 1, wherein the predefined cryptographic operation is one of: a cryptographic hash operation, and a symmetric data encryption operation.
Childe - One or more one-way functions; one or more hash functions; one or more one-way forward hash functions; one or more hash-based message authentication code functions; one or more key derivation functions; one or more of multiplication, subtraction, addition, division, factorization and/or any other mathematical operation; any one or more cryptographic functions, mathematical operations, functions, and/or combinations thereof that are operable to generate data representative of an QREF access token 207 that is unique, obfuscates the data representative of the QREF locator 203, and capable of being used by a QS server 103 a-103 l to identify the QREF locator 203 for providing an address for locating the associated data item stored in, without limitation, for example a QS repository 107 or QS DLT 167. Preferably, the second set of cryptographic operations and/or mathematical operations used to generate the QREF access token 207 from the QREF locator 203 is an irreversible process such that the QREF locator 203 cannot be derived from the data representative of the QREF access token 207. In a preferred example, the QREF access token is calculated using a one-way hash of the QREF locator (¶ 0199).
Regarding Claim 4. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 1, further comprising a computerized certificate authority configured for provisioning the first cryptographic key to the payer and payee communication devices via the computerized payer and payee account providers, respectively, as binary data of a trusted application asset, the first cryptographic key thereby being inaccessible to the computerized payer and payee account providers.
Childe - With the arrival and availability of quantum computers, there is a significant risk to a number of common cryptographic techniques such as, without limitation, for example the use of PKI X.509 certificates (e.g. Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA)) that are commonly used for authentication over public networks such as, without limitation, for example the Internet. The QS system 170, 175 or 180 provides a suitable platform that may be leveraged to overcome the upcoming challenges for authentication by combining, without limitation, a QS network 101 with QREF locator and QREF access token generation, SQKD technologies, and QS DLT to enable safe registration, issuance, storage and verification of certificates by Internet users, in a manner that can be regarded as quantum safe for a post-quantum digital world (¶ 0260).
Regarding Claim 5. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in as defined in claim 4, wherein the computerized certificate authority is further configured for providing the computerized payer and payee account providers with a result of performing the predefined cryptographic operation upon said first cryptographic key, and wherein at least one of the computerized payer account provider and computerized payee account provider is configured for: storing said result for future reference; and using said stored result to verify a request received from the payer communication device or payee communication device , respectively, said request comprising a corresponding result of the respective device having performed the predefined cryptographic operation upon said first cryptographic key as stored locally in the trusted execution environment of the respective device , the request being one of: a payment service onboarding request, a local digital wallet topup request, and said payment settlement request.
Childe - For example, there has been a lot of bad publicity in recent years in relation to malicious users/agents or hackers taking advantage of various DLT signature schemes by stealing a user's signature signing credentials and thus being able to masquerade as the user and steal and/or access that user's DLT assets using the signing credentials. For example, a malicious actor may steal a user's DLT/Blockchain assets (e.g. Bitcoin and the like) by gaining access to a user's private cryptographic keys (e.g. signing credentials) that are used for signing DLT/Blockchain transactions. This has led to user's keeping their signing credentials (e.g. private keys) offline, which is recommended best practice, and/or using secure wallet facilities and the like. However, such systems are either inconvenient to use (e.g. offline requires the user keeps a copy of the credentials on their person should they wish to sign a DLT transaction at any time) and/or still capable of being attacked by malicious actors/hackers and the like (e.g. the user has to trust the security measures a secure wallet facility had built in) (¶ 0369).
Regarding Claim 6. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in any preceding claim 1 wherein at least one of the computerized payer account provider and computerized payee account provider is configured for: receiving the payment settlement request; verifying that the payment settlement request has been duly signed by the payer communication device or payee communication device, respectively, by use of a public cryptographic key being associated with the second cryptographic key or third cryptographic key , respectively; and triggering settlement of the offline digital payment upon successful verification of the signature of the payment settlement request.
Childe - 1. The Customer/User follows the QS cloud platform authorised partner's instructions to begin the commissioning sequence of the QS or QS cloud platform service. Examples include a first-time powering of the device, Network OTP boot and key update via the Quantum Cloud listener, manually executing an QS cloud platform-provided setup.exe pre-installed installation application, inserting a USB key or SD card, Sim card or similar and initiating the install application software. 2. Once started, the (QS Initialisation App) decrypts the installation key held on the local device using the QS cloud platform secret key known by the installer application. 3. The decrypted (One Time Device Initialisation Key) is used to initiate a TLS connection on a specific HTTP port (e.g TCP Port:8000) to generate a handshake with the QS cloud platform Registration Node. 4. The QS cloud platform Registration Node listener on (TCP Port:8000) receives the handshake data request and makes an GraphQL API call to the DLT Server to match the handshake data received—(Registration Node, Registration Security Gateway, Backend Server, DLT Server). 5. The DLT searches the ‘Quantum Cloud/QS cloud platform device inventory’ for the pre-stored unique key details using the TLS handshake data to match that devices key. 6. Once the TLS handshake shared key is found, trigger a DLT Smart Contract which audits and initiates the following: 7. The required TLS Handshake Data response is returned to the (Registration Node) to enable the TLS handshake to be completed (¶ 0513).
Regarding Claim 7. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in The digital payment system as defined in wherein said at least one of the payer communication device and the payee communication device is configured to include in the payment settlement request result data representing the result of performing, in the trusted execution environment , said predefined cryptographic operation upon said first cryptographic key , and wherein at least one of the computerized payer account provider and computerized payee account provider is configured for: receiving the payment settlement request ; performing two steps of verification of the payment settlement request by:
verifying that the payment settlement request has been duly signed by the payer communication device or the payee communication device , respectively, by use of a public cryptographic key being associated with the second cryptographic key or third cryptographic key , respectively, and
Childe - 1. The Customer/User follows the QS cloud platform authorised partner's instructions to begin the commissioning sequence of the QS or QS cloud platform service. Examples include a first-time powering of the device, Network OTP boot and key update via the Quantum Cloud listener, manually executing an QS cloud platform-provided setup.exe pre-installed installation application, inserting a USB key or SD card, Sim card or similar and initiating the install application software. 2. Once started, the (QS Initialisation App) decrypts the installation key held on the local device using the QS cloud platform secret key known by the installer application. 3. The decrypted (One Time Device Initialisation Key) is used to initiate a TLS connection on a specific HTTP port (e.g TCP Port:8000) to generate a handshake with the QS cloud platform Registration Node. 4. The QS cloud platform Registration Node listener on (TCP Port:8000) receives the handshake data request and makes an GraphQL API call to the DLT Server to match the handshake data received—(Registration Node, Registration Security Gateway, Backend Server, DLT Server). 5. The DLT searches the ‘Quantum Cloud/QS cloud platform device inventory’ for the pre-stored unique key details using the TLS handshake data to match that devices key. 6. Once the TLS handshake shared key is found, trigger a DLT Smart Contract which audits and initiates the following: 7. The required TLS Handshake Data response is returned to the (Registration Node) to enable the TLS handshake to be completed (¶ 0094).
ii) verifying that said stored result of performing the predefined cryptographic operation upon said first cryptographic key as provided from the computerized certificate authority matches the result data included in the payment settlement request ; and triggering settlement of the offline digital payment upon successful outcome of both steps of verification of the payment settlement request.
Childe - 1. The Customer/User follows the QS cloud platform authorised partner's instructions to begin the commissioning sequence of the QS or QS cloud platform service. Examples include a first-time powering of the device, Network OTP boot and key update via the Quantum Cloud listener, manually executing an QS cloud platform-provided setup.exe pre-installed installation application, inserting a USB key or SD card, Sim card or similar and initiating the install application software. 2. Once started, the (QS Initialisation App) decrypts the installation key held on the local device using the QS cloud platform secret key known by the installer application. 3. The decrypted (One Time Device Initialisation Key) is used to initiate a TLS connection on a specific HTTP port (e.g TCP Port:8000) to generate a handshake with the QS cloud platform Registration Node. 4. The QS cloud platform Registration Node listener on (TCP Port:8000) receives the handshake data request and makes an GraphQL API call to the DLT Server to match the handshake data received—(Registration Node, Registration Security Gateway, Backend Server, DLT Server). 5. The DLT searches the ‘Quantum Cloud/QS cloud platform device inventory’ for the pre-stored unique key details using the TLS handshake data to match that devices key. 6. Once the TLS handshake shared key is found, trigger a DLT Smart Contract which audits and initiates the following: 7. The required TLS Handshake Data response is returned to the (Registration Node) to enable the TLS handshake to be completed (¶ 0094).
Regarding Claim 8. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 6, wherein the second cryptographic key or third cryptographic key complies with a quantum-resistant public key infrastructure, PKI, configuration for asymmetric data encryption being based on one of the following: lattice-based cryptography, multivariate cryptography, hash-based-cryptography, code-based cryptography, super singular elliptic curve isogeny, and Diffie Hallman-key exchange with forward secrecy.
Childe - With the arrival and availability of quantum computers, there is a significant risk to a number of common cryptographic techniques such as, without limitation, for example the use of PKI X.509 certificates (e.g. Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA)) that are commonly used for authentication over public networks such as, without limitation, for example the Internet. The QS system 170, 175 or 180 provides a suitable platform that may be leveraged to overcome the upcoming challenges for authentication by combining, without limitation, a QS network 101 with QREF locator and QREF access token generation, SQKD technologies, and QS DLT to enable safe registration, issuance, storage and verification of certificates by Internet users, in a manner that can be regarded as quantum safe for a post-quantum digital world (¶ 0260).
Regarding Claim 9. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 1 wherein the payment-specific data included in the payment request comprises a payment amount and an alias of a payee being an intended receiver of the offline digital payment, and wherein the payment-specific data included in the payment response comprises said payment amount , said payee alias and an alias of a payer being an intended sender of the offline digital payment.
Childe - This technique sees sensitive files, which could include information such as account holders' addresses and names, scraped and stored by malicious parties until they have the capability in the future to decipher the contents with quantum computers (¶ 0008). transmitting a quantum safe payment transaction to the quantum cloud platform, the QS payment transaction of a user comprising data representative of a payment value which is a fiat cash value or a digital currency value for transferring to another user of an endpoint device. receiving an indication of the number of quantum money tokens withdrawn from the QS payment account of the user of the endpoint device; and updating an electronic wallet of said user based on the indication (¶ 0018). The request may include the QREF number of the second user, an email address of the second user, or any type of data representative of an identifier of the second user 105 b that the QS network 101 may use to identify the QREF user account associated with the second user 105 b (¶ 0315).
Regarding Claim 10. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 9, wherein the trusted execution environment of the payer communication device comprises a payer digital wallet having a local balance representing a current monetary value available for offline payments, and wherein the payer communication device is configured, upon successful verification of the payment request , to reduce the local balance of the payer digital wallet by the payment amount.
Childe - an electronic wallet of said user (¶ 0013). Updating (reduce) an electronic wallet of said user based on the received number of quantum money tokens (¶ 0016). transmitting a quantum safe payment transaction to the quantum cloud platform, the QS payment transaction of a user comprising data representative of a payment value (¶ 0018). The QM App 703 includes an electronic wallet (e-wallet) or digital wallet 721 that stores, on the client-side, the total amount of fiat currency that the user has in the QM account. This total amount, or balance, will generally start at zero until money is deposited in the account by the user of the account, or some other user of the QS payment system 700. In the illustrated example of FIG. 9 a , an initial balance of zero is assumed for the e-wallet 721, for simplicity and clarity (¶ 0451).
Regarding Claim 11. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 10, wherein the trusted execution environment of the payee communication device comprises a payee digital wallet having a local balance representing a current monetary value available for offline payments, and wherein the payee communication device is configured, upon successful verification of the payment response , to increase the local balance of the payee digital wallet by the payment amount .
Childe - transfers across the QM tokens from the user (Alan) account to the other user (Bob) account with an indicated value in the fiat currency (USD) of the other user account based on this spot exchange rate, increasing the balance in the other user (Bob) e-wallet 721 by $13 (¶ 0489). Subsequently, in step 930, when the other user (Bob) logs onto QM client-side application 703 (e.g. QM App) that is installed on the other user endpoint device, the other user will see that the balance of their e-wallet has increased by the transferred amount at the current spot exchange rate (e.g. by $13) (¶ 0490).
Regarding Claim 12. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 9, wherein the payment-specific data included in the payment request further comprises a payment request identifier , and wherein the payment-specific data included in the payment response comprises said payment amount, said payee alias , said payment request identifier and an alias of a payer being an intended sender of the offline digital payment.
Childe - The QM App 703 includes an electronic wallet (e-wallet) or digital wallet 721 that stores, on the client-side, the total amount of fiat currency that the user has in the QM account. This total amount, or balance, will generally start at zero until money is deposited in the account by the user of the account, or some other user of the QS payment system 700. In the illustrated example of FIG. 9 a , an initial balance of zero is assumed for the e-wallet 721, for simplicity and clarity (¶ 0451).
Regarding Claim 13. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 11 wherein the trusted execution environment of the payee communication device comprises a payee digital wallet having a local balance representing a current monetary value available for offline payments, and wherein the payee communication device is configured, upon successful verification of the payment response, to increase the local balance of the payee digital wallet by the payment amount, and wherein the payee communication device is configured to check that the payment request identifier comprised in the payment-specific data included in the payment response matches the payment request identifier comprised in the payment-specific data included in the payment request as a further requisite for increasing the local balance of the payee digital wallet by the payment amount.
Childe - With the arrival and availability of quantum computers, there is a significant risk to a number of common cryptographic techniques such as, without limitation, for example the use of PKI X.509 certificates (e.g. Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA)) that are commonly used for authentication over public networks such as, without limitation, for example the Internet. The QS system 170, 175 or 180 provides a suitable platform that may be leveraged to overcome the upcoming challenges for authentication by combining, without limitation, a QS network 101 with QREF locator and QREF access token generation, SQKD technologies, and QS DLT to enable safe registration, issuance, storage and verification of certificates by Internet users, in a manner that can be regarded as quantum safe for a post-quantum digital world (¶ 0260).
Regarding Claim 14. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 1 wherein the payee communication device is configured to indicate, in the payment request , a version of the first cryptographic key comprised in its trusted execution environment , and wherein the payer communication device is configured to check that the version of the first cryptographic key indicated in the payment request is the same as or compatible with a version of the first cryptographic key comprised in its own trusted execution environment.
Childe - The unique quantum key identifier may be used or sent to one or more QS servers requiring a quantum-safe communication channel with each other or other devices over a communication network. The QS servers use the unique quantum key identifier to retrieve the corresponding QD key from the QS repository 107 and/or corresponding HSM 106 a-106 l for setting up a quantum-safe communication channel (¶ 0111). the identical sets of QD keys stored in the corresponding HSMs 106 a-106 l or QS repository 107 to set up quantum safe communication channels with each other and with the QS repository 107 using quantum encryption based on one or more available QD keys from the set of QD keys (¶ 0115). With the arrival and availability of quantum computers, there is a significant risk to a number of common cryptographic techniques such as, without limitation, for example the use of PKI X.509 certificates (e.g. Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA)) that are commonly used for authentication over public networks such as, without limitation, for example the Internet. The QS system 170, 175 or 180 provides a suitable platform that may be leveraged to overcome the upcoming challenges for authentication by combining, without limitation, a QS network 101 with QREF locator and QREF access token generation, SQKD technologies, and QS DLT to enable safe registration, issuance, storage and verification of certificates by Internet users, in a manner that can be regarded as quantum safe for a post-quantum digital world (¶ 0260).
Regarding Claim 15. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in claim 1 wherein the payer communication device is configured, upon successful verification of the payment request , to store the payment-specific data included in the payment response as negotiated payment details for the offline digital payment in the trusted execution environment , and subsequently make a payment settlement request by broadband data communication with the computerized payer account provider , the payment settlement request including the stored negotiated payment details for the offline digital payment and being signed by the second cryptographic key , and wherein the payee communication device is configured, upon successful verification of the payment response , to store the payment-specific data included in the payment response as negotiated payment details for the offline digital payment in the trusted execution environment , and subsequently make a payment settlement request by broadband data communication with the computerized payee account provider , the payment settlement request including the stored negotiated payment details for the offline digital payment and being signed by the third cryptographic key.
Childe - The communications interface 502 b may include a transceiver, receiver and/or transmitter, and/or one or more input/output ports and the like for wireless and/or wired communication with a network and/or another computing device, end-point and the like (network/telecom connectivity = broadband interface) (¶ 0281). cryptographic key creation/generation/storage and processing; secure storage of cryptographic keys; performing cryptographic operations using the cryptographic keys and the like; trusted execution (¶ 0282).
Regarding Claim 16. The combination of Childe, Gan, and Mee further discloses:
The digital payment system as defined in Claim 15. The digital payment system as defined in wherein the payment-specific data included in the payment response comprises a payment identifier ,wherein each of the payer communication device and the payee communication device is configured, upon successful verification of the payment request and the payment response , respectively, to store the negotiated payment details for the offline digital payment including said payment identifier in the trusted execution environment , and wherein each of the payer communication device and the payee communication device is configured to include said payment identifier in the respective payment settlement request , thereby preventing double settlement of the offline digital payment.
Childe - Each DLT node 166 a-166 f of the QS servers 103 a-103 c and/or QS servers of users 104 a-104 c may store and/or access an encrypted data item in a QS DLT record that is addressed using the QREF locator generated by a QS server 103 a-103 c during when the data item is stored in the QS DLT 167. The DLT record for storing a data item in the QS DLT 167 may include, without limitation, for example data representative of: QREF locator (e.g. QREF) generated for the data item; the data item (e.g. DATA_ITEM) or encrypted data item that is encrypted with an available QD key (e.g. QSKD_KEY) from the set of QD keys; access permissions such as create, read, write, modify and any other permission type (e.g. ACL_ROLE_ID); access control data (e.g. ACL_ID) such as, for example, user identifiers of the users (e.g. USER_ID or CUSTNUM) with permissions for accessing, in some manner, the data item; and/or any other data required for storing the data item in the QS DLT 167 (¶ 0233).
Regarding Claim 17. Childe discloses (in BOLD):
A communication device for use in a digital payment system, the communication device comprising: a short-range data communication interface;
Childe - a computer-implemented method of secure quantum safe (QS) payments using a quantum cloud payment platform and two or more endpoint devices (¶ 0016). a first end-point device 502 a of a first user 105 a (e.g. the first user is authorized to use or operate the first end-point device 502 a) and a second end-point device 502 b of a second user 105 b (e.g. the second user is authorized to use or operate the second end-point device 502 b) (Two distinct endpoint devices map to payer/payee device) (¶ 0280). The communications interface 502 b may include a transceiver, receiver and/or transmitter, and/or one or more input/output ports and the like for wireless and/or wired communication with a network and/or another computing device, end-point and the like (network/telecom connectivity = broadband interface) (¶ 0281). cryptographic key creation/generation/storage and processing; secure storage of cryptographic keys; performing cryptographic operations using the cryptographic keys and the like; trusted execution (¶ 0282). each device 502 a and 502 b may establish a communications path and connect with each other over a telecommunications network (device to device: short-range) (¶ 0326). secure processor/memory unit 503 d of the end-point device 502 a (e.g. a Secure Enclave, TrustZone, and the like) (Trusted Execution Environment)(¶ 0343).
a broadband data communication interface; and
Childe - The communications interface 502 b may include a transceiver, receiver and/or transmitter, and/or one or more input/output ports and the like for wireless and/or wired communication with a network and/or another computing device, end-point and the like (network/telecom connectivity = broadband interface) (¶ 0281).
a trusted execution environment enabled for performing a predefined cryptographic operation, wherein the trusted execution environment comprises a first cryptographic key being a shared secret, and an additional cryptographic key, the communication device being configured to act either for a payer or for a payee to negotiate payment details for an offline digital payment by exchanging a payment request and a payment response by short-range data communication with another communication device,
Childe - secure processor/memory unit 503 d of the end-point device 502 a (e.g. a Secure Enclave, TrustZone, and the like) (Trusted Execution Environment)(¶ 0343). Childe - An access operation may include, without limitation, for example queries (request/payment) in relation to the data item, updates in relation to the data item, retrieving information associated with the data item, answers to questions in relation to the data item and/or any other type of access operation associated with the data item (¶ 0135). each device 502 a and 502 b may establish a communications path and connect with each other over a telecommunications network (device to device: short-range) (¶ 0326).
wherein the negotiation involves, when the communication device acts for the payer, verifying the payment request by performing the predefined cryptographic operation based on payment-specific data included in the payment request as well as on the first cryptographic key and comparing with cryptographic data also included in the payment request and being the result of said another communication device having performed the same predefined cryptographic operation based on said payment-specific data as well as on said first cryptographic key,
Childe - sending data representative of the received transaction or message and a QREF access token associated with a data item stored in the repository, the data item comprising a signing key for use in digitally signing the transaction or message; receiving a digitally signed transaction or digitally signed message comprising the transaction or message digitally signed using a digital signature algorithm based on the data item; sending the digitally signed transaction for further processing or storage (¶ 0703).
wherein the negotiation involves, when the communication device acts for the payee, verifying the payment response by performing the predefined cryptographic operation based on payment-specific data included in the payment response as well as on the first cryptographic key and comparing with cryptographic data also included in the payment response and being the result of the payer communication device having performed the same predefined cryptographic operation based on said payment-specific data as well as on said first cryptographic key,
Childe - Each DLT node 166 a-166 f of the QS servers 103 a-103 c and/or QS servers of users 104 a-104 c may store and/or access an encrypted data item in a QS DLT record that is addressed using the QREF locator generated by a QS server 103 a-103 c during when the data item is stored in the QS DLT 167. The DLT record for storing a data item in the QS DLT 167 may include, without limitation, for example data representative of: QREF locator (e.g. QREF) generated for the data item; the data item (e.g. DATA_ITEM) or encrypted data item that is encrypted with an available QD key (e.g. QSKD_KEY) from the set of QD keys; access permissions such as create, read, write, modify and any other permission type (e.g. ACL_ROLE_ID); access control data (e.g. ACL_ID) such as, for example, user identifiers of the users (e.g. USER_ID or CUSTNUM) with permissions for accessing, in some manner, the data item; and/or any other data required for storing the data item in the QS DLT 167 (¶ 0233).
the communication device being configured, upon successful verification of the payment request or the payment response, respectively, to store the payment-specific data included in the payment response as negotiated payment details for the offline digital payment in the trusted execution environment, and
Childe - Each DLT node 166 a-166 f of the QS servers 103 a-103 c and/or QS servers of users 104 a-104 c may store and/or access an encrypted data item in a QS DLT record that is addressed using the QREF locator generated by a QS server 103 a-103 c during when the data item is stored in the QS DLT 167. The DLT record for storing a data item in the QS DLT 167 may include, without limitation, for example data representative of: QREF locator (e.g. QREF) generated for the data item; the data item (e.g. DATA_ITEM) or encrypted data item that is encrypted with an available QD key (e.g. QSKD_KEY) from the set of QD keys; access permissions such as create, read, write, modify and any other permission type (e.g. ACL_ROLE_ID); access control data (e.g. ACL_ID) such as, for example, user identifiers of the users (e.g. USER_ID or CUSTNUM) with permissions for accessing, in some manner, the data item; and/or any other data required for storing the data item in the QS DLT 167 (¶ 0233).
the communication device being configured to subsequently send a payment settlement request by broadband data communication, the payment settlement request including the stored negotiated payment details for the offline digital payment and being signed by the additional cryptographic key (wallet privkey;wallet2 priv key).
Childe - QS payment transaction of a user comprising data representative of a payment value (¶ 0015). transmitting a quantum safe payment transaction to the quantum cloud platform, the QS payment transaction of a user comprising data representative of a payment value which is a fiat cash value or a digital currency value for transferring to another user of an endpoint device; receiving an indication of the number of quantum money tokens withdrawn from the QS payment account of the user of the endpoint device; and updating an electronic wallet of said user based on the indication (¶ 0018). the corresponding QREF access tokens associated with the set of signing keys may be sent to one or more systems (¶ 0414).
wherein the negotiation involves, when the communication device acts for the payer, verifying the payment request by performing the predefined cryptographic operation based on payment-specific data included in the payment request as well as on the first cryptographic key and comparing with cryptographic data also included in the payment request and being the result of said another communication device