DETAILED ACTION
This is a 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 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 .
Response to Arguments
Regarding the 103 Rejection
Applicant’s arguments filed 3/27/2026 has been considered but are not persuasive. The rejection does not require bodily incorporating Mee’s entire payment service system in to Childe, nor does it require Childe to abandon its quantum-safe framework. Rather, Chile is relied upon for the secure payment architecture, endpoint devices, keys, wallets, and broadband/cloud settlement; Gan is relied upon for trusted execution, cryptographic verification/comparison, and secure storage; and Mee is replied upon for the known concept of offline payment handling and later completion.
Applicant argues that Childe would use QD keys “all the way” and therefore would not use a shared secret for offline negotiation and a separate private key for online settlement. This is not persuasive. Childe already uses different keys for different communication relationships. It would have been a predictable design choice to use lightweight shared-secret authentication for local offline negotiation and separate signing keys for later settlement, because those phases serve different security purposes.
Applicant also argues there is no motivation to create the claimed “hybrid cryptographic architecture.” However, the motivation arises from the complementary teachings of references: Childe provides the payment and settlement framework, Gan provides secure cryptographic execute and storage, and Mee provides offline handling. Combining the teachings would predictable allow verified payment details to be negotiated locally when broadband connectivity is unavailable, securely stored, and later settled online.
Applicant further argues that Mee is mediated by a payment service and does not teach direct peer-to-peer offline negotiation. This is not persuasive because Mee is not relied upon for the entire claimed peer-to-peer architecture for shared-secret verification. Mee is relied upon only for the offline payment concept. A reference need not to disclose the identical architecture to be properly combined.
Applicant’s argument that Mee uses PKI rather than a pre-shared symmetric secret is also unpersuasive. The shared-secret verification is supplied by the Childe and Gan combination not Mee. Mee’s use of PKI in its own embodiment does not teach away from using a shared secret in the modified system.
The hindsight argument is likewise unpersuasive. The references are all directed to secure electronic payment and cryptographic transaction processing and address related problems. The combination applies known techniques according to their established functions to achieve predictable results.
Therefore the 103 rejection of the claims is maintained.
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 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).
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 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
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 20. The combination of Childe, Gan, and Mee further discloses:
A computing resource configured to perform the functionality of the computerized payer account provider in the digital payment system as defined by claim 1.
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 21. The combination of Childe, Gan, and Mee further discloses:
A computing resource configured to perform the functionality of the computerized payee account provider in the digital payment system as defined by claim 1.
Regarding Claim 22. Childe discloses (in BOLD):
a payer communication device and a payee communication device negotiating payment details for an offline digital payment by exchanging a payment request and a payment response by short-range data communication, wherein the negotiation involves performing a predefined cryptographic operation for the payment request as well as the payment response, the cryptographic operation being based on payment-specific data as well as on a first cryptographic key which is a shared secret being stored in respective trusted execution environments of the payer communication device and payee communication device;
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).
at least one of the payer communication device and the payee communication device , upon successful negotiation, storing the 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).
said at least one of the payer communication device and the payee communication device subsequently making a payment settlement request by broadband data communication with a computerized payer account provider or computerized payee account provider, respectively, the payment settlement request including the stored negotiated payment details for the offline digital payment and being signed by a second cryptographic key or third cryptographic key, respectively, which is stored in the trusted execution environment of the payer communication device or payee communication device, respectively.
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).
Childe does not teach, however Gan discloses the following (in BOLD):
a payer communication device and a payee communication device negotiating payment details for an offline digital payment by exchanging a payment request and a payment response by short-range data communication, wherein the negotiation involves performing a predefined cryptographic operation for the payment request as well as the payment response, the cryptographic operation being based on payment-specific data as well as on a first cryptographic key which is a shared secret being stored in respective trusted execution environments of the payer communication device and payee communication device;
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):
a payer communication device and a payee communication device negotiating payment details for an offline digital payment by exchanging a payment request and a payment response by short-range data communication, wherein the negotiation involves performing a predefined cryptographic operation for the payment request as well as the payment response, the cryptographic operation being based on payment-specific data as well as on a first cryptographic key which is a shared secret being stored in respective trusted execution environments of the payer communication device and payee communication device;
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).
at least one of the payer communication device and the payee communication device , upon successful negotiation, storing the 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 23. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, the predefined cryptographic operation being a cryptographic hash operation or 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 24. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, the second cryptographic key or third cryptographic key being a private key in 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, supersingular elliptic curve isogeny, and Diffie Hallman-key exchange with forward secrecy.
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 25. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, further comprising, by a computerized certificate authority , 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 - 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 26. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 25, further comprising by the computerized certificate authority: providing the computerized payer and payee account providers with a result of performing the predefined cryptographic operation upon said first cryptographic key , and by at least one of the computerized payer account provider and computerized payee account provider :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 - 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 27. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, further comprising, by at least one of the computerized payer account provider and computerized payee account provider: 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 - 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 28. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in any of claim 22, further comprising by said at least one of the payer communication device and the payee communication device :performing, in the trusted execution environment , said predefined cryptographic operation upon said first cryptographic key , and including result data, representing a result of said performing, in the payment settlement request , and by at least one of the computerized payer account provider and computerized payee account provider :receiving the payment settlement request ;performing two steps of verification of the payment settlement request by: i) 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 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 - 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). 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 29. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 27 or 28, 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, supersingular elliptic curve isogeny, and Diffie Hallman-key exchange with forward secrecy.
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 30. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, 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 - 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 31. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 30, the trusted execution environment of the payer communication device comprising a payer digital wallet having a local balance representing a current monetary value available for offline payments, wherein the method comprises, by the payer communication device upon successful verification of the payment request , reducing the local balance of the payer digital wallet (DW) by the payment amount .
Childe - 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 32. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 31, the trusted execution environment of the payee communication device comprising a payee digital wallet having a local balance representing a current monetary value available for offline payments, wherein the method comprises, by the payee communication device upon successful verification of the payment response , increasing 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). 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 33. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 30, 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 - 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 34. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 32 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, the computerized method further comprising, by the payee communication device , checking 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 - Each temporary QREF access token is compared with the received QREF access token and the QREF locator corresponding to the temporary QREF access token that matches the received QREF access token is the identified QREF locator (¶ 0130). checking the user has permissions to access the data item based on an access control list associated with the data item; and enabling the user access operations to the data item in response to determining the user has permissions to access the data item (¶ 0628).
Regarding Claim 35. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, further comprising: by the payee communication device , indicating in the payment request a version of the first cryptographic key comprised in its trusted execution environment , and by the payer communication device , checking 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 36. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 22, further comprising: by the payer communication device :upon successful verification of the payment request , storing 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 - the end-point device includes, without limitation, for example a secure processor/memory… secure storage of cryptographic keys; performing cryptographic operations using the cryptographic keys and the like; trusted execution (¶ 0282).
subsequently making a payment settlement request by broadband data communication with the computerized payer account provider , wherein the payment settlement request includes the stored negotiated payment details for the offline digital payment and is signed by the second cryptographic key, and by the payee communication device :upon successful verification of the payment response,
Childe - transmitting a quantum safe deposit payment transaction to the quantum cloud platform, the QS deposit payment transaction comprising data representative of a deposit fiat cash value; receiving data representative of said number of quantum money tokens corresponding to the deposit fiat cash value; updating an electronic wallet of said user based on the received number of quantum money tokens; in response to a withdrawal instruction from the user of the endpoint device, transmitting a quantum safe withdrawal payment transaction to the quantum cloud platform (¶ 0026). within public telecommunication infrastructure, so-called non-quantum safe network 102, such as, without limitation, for example the public Internet, telecommunications networks, public service telecommunication network(s) and the like (¶ 0191).
storing 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 - storing and accessing data items in relation to a first plurality of users 104 a-104 m and a second plurality of users 105 a-105 n. In this example, a plurality of the QS server(s) 103 a-103 c includes a plurality of DLT nodes 166 a-166 c and/or user server of user 104 a includes DLT node 166 d, where the DLT nodes 166 a-166 d operate to form the QS DLT network 167 (referred to as QS DLT) for storing and/or accessing data items and the like. The QS DLT 167 may be based on at least one or more DLTs from, without limitation, for example the group of: a distributed ledger; a shared ledger; a blockchain; publish/subscribe and/or response/request management system or platform; and/or any other secure distributed database management system and the like; and/or as the application demands. In this example, the QS DLT 167 may include a distributed ledger and/or a shared ledger for storing, by way of example only but is not limited to, the data items of the plurality of users 104 a-104 m and/or 105 a-105 n and the like (¶ 0146).
subsequently making a payment settlement request by broadband data communication with the computerized payee account provider , wherein the payment settlement request includes the stored negotiated payment details for the offline digital payment and is signed by the third cryptographic key (wtallet2jpriv 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). 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 37. The combination of Childe, Gan, and Mee further discloses:
The computerized method as defined in claim 36, the payment-specific data included in the payment response comprising a payment identifier,
Childe - Each unique QD key is stored in the QS repository 107 may be assigned a corresponding unique quantum key identifier (e.g. QKID). When a set of QD keys are submitted or filed, they may be compared with previously submitted sets of QD keys so duplicate QD keys are discarded and only unique QD keys are stored against a unique quantum key identifier in the QS repository 107 (¶ 0111).
wherein the method further comprises, by each of the payer communication device and the payee communication device: upon successful verification of the payment request and the payment response, respectively, storing the negotiated payment details for the offline digital payment including said payment identifier in the trusted execution environment, and including said payment identifier in the respective payment settlement request, thereby preventing double settlement of the offline digital payment.
Childe - serve and/or process one or more user requests associated with registration, storing and/or accessing data items within the QS network; serve and/or process one or more user requests for quantum-safe communication between user device(s) of users of the QS network and/or QS servers and the like; receiver and/or process data representative of one or more QD keys (or QD keys) distributed in a quantum-safe manner form a QKD source using a QKD protocol and/or quantum channels and the like (¶ 0112). 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 42. The combination of Childe, Gan, and Mee further discloses:
A tangible, non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the payer communication device in the method according to claim 22 when the computer program code is executed by a processing device.
Childe - In essence, an HSM 106 a-106 l comprises or represents a computing device or apparatus configured for at least securely storing one or more cryptographic or digital keys for use in, for example, authentication and/or cryptographic operations/processing and the like.
Regarding Claim 43. The combination of Childe, Gan, and Mee further discloses:
A tangible, non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the payee communication device in the method according to 22 when the computer program code is executed by a processing device.
Childe - a seventh example, the present disclosure provides a computer-readable medium comprising code or computer instructions stored thereon, which when executed by a processor unit, causes the processor unit to perform the computer-implemented method according to any of the first, second, third, fourth and/or fifth examples, one or more features thereof, one or more features herein, combinations thereof, modifications thereto and/or as described herein. In a eighth example, the present disclosure provides an end-point device comprising a processor unit, a memory unit and a communication interface, the processor unit connected to the memory unit and the communication unit, wherein the apparatus is configured to implement the computer-implemented method according to any of the fourth and/or fifth examples, one or more features thereof, one or more features herein, combinations thereof, modifications thereto and/or as described herein (¶ 0648).
Regarding Claim 44. The combination of Childe, Gan, and Mee further discloses:
A tangible, non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the computerized payer account provider in the method according to claim 22 when the computer program code is executed by a processing device.
Childe - a seventh example, the present disclosure provides a computer-readable medium comprising code or computer instructions stored thereon, which when executed by a processor unit, causes the processor unit to perform the computer-implemented method according to any of the first, second, third, fourth and/or fifth examples, one or more features thereof, one or more features herein, combinations thereof, modifications thereto and/or as described herein. In a eighth example, the present disclosure provides an end-point device comprising a processor unit, a memory unit and a communication interface, the processor unit connected to the memory unit and the communication unit, wherein the apparatus is configured to implement the computer-implemented method according to any of the fourth and/or fifth examples, one or more features thereof, one or more features herein, combinations thereof, modifications thereto and/or as described herein (¶ 0648).
Regarding Claim 45. The combination of Childe, Gan, and Mee further discloses:
A tangible, non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the computerized payee account provider in the method according to claim 22 when the computer program code is executed by a processing device.
Childe - a seventh example, the present disclosure provides a computer-readable medium comprising code or computer instructions stored thereon, which when executed by a processor unit, causes the processor unit to perform the computer-implemented method according to any of the first, second, third, fourth and/or fifth examples, one or more features thereof, one or more features herein, combinations thereof, modifications thereto and/or as described herein. In a eighth example, the present disclosure provides an end-point device comprising a processor unit, a memory unit and a communication interface, the processor unit connected to the memory unit and the communication unit, wherein the apparatus is configured to implement the computer-implemented method according to any of the fourth and/or fifth examples, one or more features thereof, one or more features herein, combinations thereof, modifications thereto and/or as described herein (¶ 0648).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Raj (US10417619B2) - (An alias management and value transfer claim processing system is disclosed. A sending entity initiates value transfer identifying a recipient entity using an alias that is unregistered with the system. The value transfer is authorized, but not settled until the recipient entity registers with the system and claims the value transfer. The registered alias can be used for subsequent value transfers.). Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C whose telephone number is (571)270-7280. The examiner can normally be reached on Monday-Friday from 8am to 5pm.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick Mcatee, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights