WO2020056455A1 - Système de transaction - Google Patents

Système de transaction Download PDF

Info

Publication number
WO2020056455A1
WO2020056455A1 PCT/AU2019/050916 AU2019050916W WO2020056455A1 WO 2020056455 A1 WO2020056455 A1 WO 2020056455A1 AU 2019050916 W AU2019050916 W AU 2019050916W WO 2020056455 A1 WO2020056455 A1 WO 2020056455A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
payment
transaction
transferable
details
Prior art date
Application number
PCT/AU2019/050916
Other languages
English (en)
Inventor
Shadi HADDAD
Richard Benjamin LANE
Original Assignee
Till Payments Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2018903504A external-priority patent/AU2018903504A0/en
Application filed by Till Payments Pty Ltd filed Critical Till Payments Pty Ltd
Publication of WO2020056455A1 publication Critical patent/WO2020056455A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present invention relates to a method and apparatus for facilitating transactions, and in one particular example, to a method and apparatus for facilitating transactions including multiple different entities.
  • a further issue with transactions of this form is managing payments, and in particular ensuring payment is appropriately made to all entities involved. This is further exacerbated in the case of transactions that involve multiple jurisdictions or payment providers. Again, this arises for similar technical reasons, and additional in view of the complexity in ensuring rules in different jurisdictions are satisfied.
  • an aspect of the present invention seeks to provide a system for facilitating transactions, the system including one or more processing devices that: obtain transaction details relating to the transaction, the transaction including a payment; generate a transferable token associated with the payment; store token data indicative of the transferable token and transaction details in a distributed data store; selectively provide access to transaction details using the token data in order to allow the transaction to be performed; and, use the transferable token in order to allow payments involving one or more of the entities to be made.
  • the transferable token governs payments involving the entities.
  • the transferable token represents a transferable payment obligation.
  • the one or more processing devices transfer ownership of at least part of the transferable token to transfer payment obligations between entities.
  • the transferable token is associated with a payment instrument to allow the payment to be performed using the payment instrument.
  • the transferable token is associated with a payment instrument by associating the transferable token with a payment token created using the payment instrument.
  • the distributed data store is a blockchain.
  • the one or more processing devices interface with computer systems of one or more entities to allow transfer of data between different software applications hosted by the one or more entities.
  • software applications hosted by the one or more entities are able to retrieve data using the token data stored in the distributed data store.
  • the one or more processing devices execute smart contracts to at least one of: provide access to transaction details; update transaction details; update the token data; and, transfer the transferable token.
  • the one or more processing devices receive transaction details from a merchant.
  • the one or more processing devices receive a payment token; and, associate the payment token with the transferable token.
  • the one or more processing devices at least one of: receive the payment token from the merchant; and, receive the payment token from a payment service provider in response to providing payment instrument details to the payment service provider.
  • the one or more processing devices provide transaction details to a merchant in response to at least one of: execution of a smart contract; a request by the merchant; and, a request by a different merchant.
  • the token data is indicative of a user identifier associated with a consumer involved in the transaction to allow one or more of the multiple entities to validate an identity of the consumer.
  • the user identifier is at least one of: an identity token; a KYC (Know Your Customer) token; identity details; KYC details; and, received as part of the transaction details.
  • the one or more processing devices receive the user identifier from the consumer; and use the user identifier and the token data to validate an identity of the consumer.
  • the user identifier is associated with a payment instrument in the distributed data store and wherein the one or more processing devices: receive the user identifier from the consumer; and use the user identifier to retrieve payment instrument details.
  • the transaction details are at least one of: stored in the distributed data store; and, accessed using a transaction identifier stored in the distributed data store.
  • the transferable token is at least one of: stored in the distributed data store; and, accessed using a token identifier stored in the distributed data store.
  • the token data include at least one of: a user identifier; an identity token; a transferable token owner; an entity identifier; transaction details; a transaction identifier; the transferable token; a token identifier; a token history indicative of interactions with the token; a payment token; and, a payment message.
  • the transaction details include at least one of: a payment amount; a payment distribution; payment instrument details; a payment token; and, a payment message.
  • the payment token includes at least one of: a high value payment token; a low value payment token; a payment pre-authorisation token; a payment clearance token; and, a payment redemption token.
  • the one or more processing devices host an application programming interface to allow computer systems hosting different software applications to access transaction details.
  • an aspect of the present invention seeks to provide a method for facilitating transactions, the method including, in one or more processing devices: obtaining transaction details relating to the transaction, the transaction including a payment; generating a transferable token associated with the payment; storing token data indicative of the transferable token and transaction details in a distributed data store; selectively providing access to transaction details using the token data in order to allow the transaction to be performed; and, using the transferable token in order to allow payments involving one or more of the entities to be made.
  • an aspect of the present invention seeks to provide a computer program product for facilitating transactions, the computer program product including computer executable code that when executed by one or more suitably programmed processing devices causes the processing devices to: obtain transaction details relating to the transaction, the transaction including a payment; generate a transferable token associated with the payment; store token data indicative of the transferable token and transaction details in a distributed data store; selectively provide access to transaction details using the token data in order to allow the transaction to be performed; and, use the transferable token in order to allow payments involving one or more of the entities to be made.
  • Figure 1 is a flowchart of an example of a process for facilitating transactions
  • Figure 2 is a schematic diagram of an example of a distributed hardware architecture
  • Figure 3 is a schematic diagram of an example of a processing system
  • Figure 4 is a schematic diagram of an example of a client device
  • Figure 5 is a schematic diagram illustrating an example functional implementation of a system for facilitating transactions
  • Figure 6 is a flowchart of an example of a process for performing transactions involving multiple merchants
  • Figures 7 A and 7B are a flowchart of an example of a process for performing a transaction utilising Know Your Customer (KYC) details
  • Figures 8A to 8C are a flowchart of a specific example of a process for performing a transaction.
  • Figure 9 is a flowchart of an example of a process for using a smart contract.
  • entity and “entities” are intended to cover any party or parties that are involved in the transaction and could refer to an individual such as a consumer, a company, a business, an organisation, a merchant, or the like, and it will be appreciated is not intended to be limiting.
  • token is intended to refer to a discrete data object that represents sensitive data, and is typically created by substituting sensitive data elements with non-sensitive information that allows the sensitive information to be recovered by an authorised entity, for example using a reference or identifier that maps back to a securely stored version of the sensitive data.
  • transferrable token is intended to refer to a token that is generated for the purpose of allowing a transaction to be performed using the techniques described herein.
  • the token is transferable in the sense that ownership of the token can be moved wholly or partly between entities as the transaction is performed. This could include physical movement of data packets between different processing systems or devices, or could include virtual movement by updating ownership information associated with the token.
  • KYC Know Your Customer
  • a person such as a customer, or a representative of a company or other entity, with the individual’s identity being used to identify the entity.
  • transaction details are obtained.
  • the transaction details can be of any appropriate form, and typically include at least some of the information required in order to allow a transaction to completed.
  • the transaction details could include information such as details of payments to be made, including a payment amount, details of a payee and/or payor, and optionally other information, such as details of a payment instrument used to affect the payment, such as a credit card, or similar.
  • the transaction details could include any other information required to allow the transaction to be performed and could include details of one or more entities involved in the transaction, such as the names of one or more merchants, details of products or services forming part of the transaction, or the like, and specific examples will be described in more detail below.
  • transaction details will vary depending upon the preferred implementation. In one example, this is achieved by having a merchant involved in the transaction forward the transaction details, but alternatively details of a transaction could be obtained from a client device associated with a consumer, retrieved from a database, or the like.
  • the processing device generates a transferable token associated with a payment to be made as part of the transaction.
  • the token is an algorithmically generated number representative of at least part of the transaction and more particularly the payment to be performed, which can be tracked back to the payment, and which typically anonymises sensitive data associated with the payment, such as details of a payment instrument such as a consumer's primary account number (PAN), or the like.
  • PAN primary account number
  • token data indicative of the transferrable token and transaction details associated with the transaction are stored in a distributed data store.
  • the token data could include the transferrable token and transaction details, or may alternatively include reference to the transferrable token and/or transaction details, which could in turn be stored in a different database.
  • Storing at least the token in the distributed data store is however particularly advantageous as this allows the transferrable token to be readily accessed by multiple entities.
  • a token is more secure as it substitutes sensitive data for non-sensitive data, which in turn refers to the sensitive data, meaning sensitive data, such a credit card details or the like are not exposed even if the token is viewable.
  • the distributed data store is a blockchain.
  • the distributed and encoded nature of the blockchain is particularly useful as this can be used to prevent transaction details that have been added to the blockchain from being subsequently altered. This, in turn, allows these to act as an absolute record of the transaction, providing immutable evidence of the transaction, and allowing this to be used in managing payments, as will be described in more detail below. Additionally, the distributed nature of the blockchain allows information, such as transaction details, to be easily recovered, even in the event for example of some of the nodes providing access to the blockchain.
  • blockchains can be public or private, or hybrids, and may include one node or multiple nodes, depending on the preferred implementation.
  • the preferred blockchain implementation may be a private blockchain and may hash the contents of a single transaction, a block or a series of blocks.
  • the particular implementation is based on the hyperledger blockchain. However, it will be appreciated that this is not intended to be limiting and any suitable implementation might be used.
  • access to the transaction details is selectively provided using the token data in order to allow the transaction to be performed.
  • multiple entities may be party to a transaction, in which case it may be necessary for transaction details to be provided to multiple different entities.
  • a consumer purchases a product from a reseller it may be necessary for details of the product purchased to be provided to a seller, allowing the seller to provide the product directly to the consumer, or to the reseller for onward provision to the consumer.
  • the booking may be created via a booking platform with details of the booking needing to be transferred to a hotel operator in order for the booking to be fulfilled.
  • access to the transaction details is achieved via the token data, either by retrieving the transaction details from the token data, or by obtaining information regarding a storage location of the transaction details from the token data, thereby allowing the transaction details to be retrieved from an alternative data store such as a database or similar.
  • the token data is used to perform payments involving the one or more entities. For example, if multiple entities are party to the transaction, it may be necessary for each of the entities to be paid. In this instance, as the token data is utilised in order to allow the transaction to be performed, information regarding the entities involved can be used in order to allocate payments to the entities. In one particular instance, this is achieved by transferring all or part of ownership of the token to the respective entities, allowing the entities to redeem the transferrable token in order to receive payment.
  • the above described arrangement utilises one or more transferrable tokens as a proxy for a payment associated with a transaction, with transfer of the token(s) between different entities allowing payment obligations to be transferred as the transaction is performed.
  • This is particularly useful for purchases involving multiple entities as this allows a consumer to initiate a purchase with one entity and then have the transferrable token transferred to another entity which is fulfilling the relevant transaction, allowing the other entity to receive payment without requiring further action from the consumer.
  • transferable tokens can be created associated with the transaction, with the transferable tokens being stored in a distributed data store, allowing these to be easily accessed by and passed between different entities, as needed.
  • the transferable tokens can be used to represent a payment obligation, so that the tokens can be used to govern payments to each of the merchants, or other entities involved.
  • the tokens can be associated with transactions details, allowing the merchants or other entities to be easily able access the transaction details. This is particularly beneficial as entities often use their own internal software applications, which are not necessarily able to easily communicate with software applications of other entities, as described above.
  • the above described process allows for payments and transaction details to be transferred between entities by way of a distributed data store such as a blockchain thereby facilitating transaction processes.
  • the transferable token typically governs payments involving the entities.
  • the transferable token represents a transferable payment obligation with ownership of the transferable token being used to transfer payment obligations between entities.
  • a first entity may transfer ownership of an entire transferable token to a second entity with this transfer resulting in the second entity being able to collect the entire payment.
  • ownership could be complete or partial, so that partial ownership of transferable tokens allows payments to be split between multiple entities. Additionally and/or alternatively, transferable tokens could be split, allowing such composite payments to be performed.
  • the transferable token is associated with a payment instrument to allow the payments to be performed using the payment instrument.
  • the payment instrument can be of any appropriate form and could include a credit card, debit card, bank account, or the like. Whilst the transferable token could be associated directly with details of the payment instrument, more typically, such an association is achieved by way of an intermediate transaction instrument token, which is used to protect sensitive payment information. In this instance, the transferable token is associated with a payment token created using the payment instrument.
  • the instrument token could be of any appropriate form and may include a high or low value payment token, a payment pre-authorisation, approval or clearance token, a payment instrument token, or similar.
  • the distributed data store is typically a blockchain.
  • a blockchain is particularly beneficial as this provides an immutable record of tokens and transactions using the tokens which can be accessed via a number of distributed nodes. This prevents the token data being fraudulently altered, whilst ensuring access to the data can be easily maintained. However, this is not essential, and any form of distributed data store could be used.
  • the processing devices interface with computer systems of the one or more entities to allow transfer of data between different software applications hosted by the one or more entities to be achieved at least in part using the token data stored in the distributed data store.
  • this allows software applications of each entity to communicate via the blockchain or other distributed data store, avoiding the need for software applications of different entities to communicate directly.
  • By providing the transaction details in the data store with a common format this ensures each entity’s system can more easily interface with the transaction details, for example via a suitable API, allowing these to be more easily used throughout the transaction chain.
  • smart contracts can be used to facilitate the transaction process.
  • a smart contract or self-executing contract is a contract embodied as computer executable code within the blockchain system.
  • the contracts typically define conditions under which a contract should be fulfilled, allowing the contract to be automatically executed by computers running the blockchain when the relevant contract conditions are met.
  • Smart contracts can be created and associated with the token data, for example storing the smart contract as part of the token data.
  • the smart contract can then be executed at an appropriate time, for example upon completion of other steps in the transaction process, allowing one or more actions to be performed.
  • Such actions can include providing access to transaction details, for example by forwarding transaction details, updating transaction details, updating token data, transferring all or part of the transferable token, trigger payments, or the like.
  • the user may have a set time period during which they can cancel the reservation.
  • details of the transaction and in particular booking details, can automatically be transferred from the distributed data store to the hotel reservation system, enabling the booking to be finalised.
  • the one or more processing devices can provide transaction details to a merchant in response to execution of the smart contract. Additionally, and/or alternatively, this can be performed based on a request by one of the entities, such as a merchant. This allows the details of transactions to be disseminated between merchants as needed in order to allow the transaction to be performed. Use of the smart contract allows this to be performed automatically but alternatively this can be triggered either by an originating merchant, or a different merchant within the transaction, for example based on requests from the merchant's software systems.
  • the transferable token is associated with a payment token, which is then used to process the subsequent payment.
  • the one or more processing devices receive the payment token and associate the payment token with the transferrable token.
  • the payment token could be received from a payment service provider, such as a payment gateway, financial institution, or the like, in response to providing payment details to the payment provider.
  • the payment token could be received from the merchant or another entity involved in the transaction.
  • payment service providers typically have well established processes for interaction with merchants, which may not be readily modifiable in order to accommodate the herein described transferrable token arrangement.
  • a merchant could arrange to receive a payment token from the payment service provider, in accordance with normal protocols, such as receiving a pre authorisation token upon providing payment instrument details of the consumer to the payment service provider.
  • the payment token could then be transferred from the merchant to the one or more processing devices running the blockchain, allowing these to add the payment token to the blockchain and thereby associate the payment token with the transferrable token.
  • the transferable token can also be used to assist with identifying consumers, or other entities.
  • the token data can be indicative of a user identifier associated with the consumer or another entity involved in the transaction, thereby allowing one or more of the multiple entities to validate the identity of a consumer, or other entity.
  • the nature of the user identifier can vary depending upon preferred implementation. For example, when the user identifier is associated with a consumer, the identifier could include an identity token, a KYC token, identity details, KYC details, or the like. Thus, the consumer could undergo an identification process with a KYC service provider, with this being used to generate a KYC token, which can then be associated with the transferable token, allowing this to be used for subsequent identification of the consumer.
  • the user identifier could be received as part of the transaction details from the merchant, or other entity, or could be received directly from the consumer depending upon the preferred implementation.
  • the processing device can receive the user identifier from the consumer and use the user identifier and the token data to validate an identity of the consumer. For example, a user can provide KYC details such as a username, or identifier associated with an identification document, with the processing device then using this and the token data to validate the identity of the consumer.
  • KYC details such as a username, or identifier associated with an identification document
  • the user identifier can be associated with a payment instrument in the distributed data store.
  • a payment instrument such as a credit card could be associated with a consumer’s KYC account, with details of this being recorded in the distributed data store, for example on the blockchain.
  • the processing device can receive the user identifier from the consumer and then use this identifier to retrieve details of the payment instrument.
  • a user can associate credit card details with a KYC account and then simply provide a username or other suitable identifier associated with the KYC account, in order to allow payment instrument details to be retrieved. This enables a transaction to be performed without the user having to present any credit card or other similar details.
  • the user can simply under identification using KYC information, with this in turn being used to retrieve payment instrument details from a blockchain.
  • payment instrument details could be stored
  • a payment instrument token could be stored, avoiding sensitive information being stored on the blockchain or other distributed data store.
  • the transaction details are stored in the distributed data store, but this is not essential and alternatively a transaction identifier, such as a reference number, can be stored in the distributed data store, with this being used to retrieve the transaction details from another store, such as a centralised and/or remote database, or similar.
  • the transferable token can be stored in the data store or accessed using the token identifier stored in the distributed data store.
  • the token data typically includes one or more of a user identifier, an identity token, a transferable token owner such as an identity of the current owner, an entity identifier, transaction details, a transaction identifier, transferable token, a token identifier, a token history indicative of transactions associated with the token, a payment token or a payment message.
  • the transaction details can include any one or more of a payment amount, a payment distribution, such as details of entities that are to receive payment, payment instrument details, a payment token or a payment message.
  • the payment token could include a high value payment token, a low value payment token, a payment preauthorisation token, a payment clearance token or a payment redemption token.
  • the process is performed by one or more processing systems and client devices operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2.
  • a number of base stations 210 are coupled via communications networks 240, such as the Internet, and/or one or more local area networks (LANs), to a number of client devices 230.
  • communications networks 240 such as the Internet, and/or one or more local area networks (LANs)
  • client devices 230 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.11 networks, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as Bluetooth, or the like.
  • processing systems 210 can be used to provide access to the blockchain and/or generate blocks, which can be included in the blockchain and/or can be used by entities party to the transaction, such as merchants or the like.
  • the processing systems 210 also typically hosts interface modules, such as APIs or similar, which allow access to the content of the blockchain. Whilst the processing system 210 is a shown as a single entity, it will be appreciated that the processing system 210 can be distributed over a number of geographically separate locations, for example by using processing systems 210 and/or databases that are provided as part of a cloud-based environment. However, the above described arrangement is not essential and other suitable configurations could be used.
  • FIG. 3 An example of a suitable processing system 210 is shown in Figure 3.
  • the processing system 210 includes at least one microprocessor 300, a memory 301, an optional input/output device 302, such as a keyboard and/or display, and an external interface 303, interconnected via a bus 304 as shown.
  • the external interface 303 can be utilised for connecting the processing system 210 to peripheral devices, such as the communications network 240, databases, other storage devices, or the like.
  • peripheral devices such as the communications network 240, databases, other storage devices, or the like.
  • a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) maybe provided.
  • the microprocessor 300 executes instructions in the form of applications software stored in the memory 301 to allow the required processes to be performed.
  • the applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.
  • the processing system 210 may be formed from any suitable processing system, such as a suitably programmed client device, PC, web server, network server, or the like, although this could also include smartphones, tablets, IoT (Internet of Things) devices, wearable devices, or the like.
  • the processing system 210 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential.
  • the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
  • the client device is typically used by a consumer to access services provided by the merchants or other entities.
  • An example of a suitable client device 230 is shown in Figure 4.
  • the client device 230 includes at least one microprocessor 400, a memory 401, an input/output device 402, such as a keyboard and/or display, and an external interface 403, interconnected via a bus 404 as shown.
  • the external interface 403 can be utilised for connecting the client device 230 to peripheral devices, such as the communications networks 240, databases, other storage devices, or the like.
  • peripheral devices such as the communications networks 240, databases, other storage devices, or the like.
  • a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.
  • the microprocessor 400 executes instructions in the form of applications software stored in the memory 401 to allow communication with the processing system2l0, for example to allow graph data to be received.
  • the client devices 230 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, or hand-held PC, and in one preferred example is either a tablet, or smart phone, or the like.
  • the client device 230 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non volatile (e.g., hard disk) storage, although this is not essential.
  • the client devices 230 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
  • one or more processing systems 210 generate and govern access to token data, and perform operations associated with entities such as merchants, including hosting web pages, or the like, whilst consumers interact with the system via the client devices 230.
  • input data and commands are received from the client devices 230 using a webpage, with resulting visualisations being rendered locally by a browser application, or other similar application executed by the client device 230.
  • the processing system 210 is therefore typically a server (and will hereinafter be referred to as a server) which communicates with the client device 230 or other servers, via a communications network 240, or the like, depending on the particular network infrastructure available.
  • the server 210 typically executes applications software for hosting webpages, as well as performing other required tasks including storing, searching and processing of data, with actions performed by the processing system 210 being performed by the processor 300 in accordance with instructions stored as applications software in the memory 301 and/or input commands received from a user via the I/O device 302, or commands received from the client device 230. It will also be assumed that the user interacts with the server 210 via a GUI (Graphical User Interface), or the like presented on the client device 230, and in one particular example via a browser application that displays webpages hosted by the server 210, or an App (software application) that displays data supplied by the server 210. Actions performed by the client device 230 are performed by the processor 400 in accordance with instructions stored as applications software in the memory 401 and/or input commands received from a user via the I/O device 402.
  • GUI Graphic User Interface
  • first and second merchants are provided with respective merchant servers 510.1, 510.2, which can be one or more servers configured to host web pages or other software applications, used in providing goods or services. In one specific example, these could include a booking engine hosted by a first merchant server 510.1, and a hotel reservation system hosted by the second merchant server 510.2.
  • a KYC service provider is provided having a KYC server 510.3, which is used in verifying the identify of entities, such as a user of client device 530.
  • a payment service provider has a payment server 510.4, which hosts software used to process payments.
  • the payment service provider could include a payment gateway, credit card provider, financial institute, or the like.
  • the overall system is operated using system servers 510, which typically includes multiple distributed blockchain nodes and associated supporting infrastructure, including software APIs that allow each of the merchant, KYC and payment servers 510.1, 510.2, 510.3, 510.4 to interact directly with the blockchain, and to provide other services as required.
  • a transaction is initiated with the first merchant, which typically involves having a consumer access merchant services hosted by the first merchant server 510.1, via a website, or similar.
  • this could include creating a hotel booking via a booking engine.
  • the first merchant server 510.1 generates transaction details, such as booking information, a payment amount, or the like, which is then provided to the system servers 510, at step 610, allowing the system servers 510 to generate the transferable token and store the transaction details, either as part of the blockchain, or in a remote data store.
  • Transaction details are then propagated to the second merchant at step 620, for example by having the system servers 510 push transaction details to the second merchant server 510.2, or by having the merchant server 510.2 retrieve details from the blockchain.
  • the transaction details could be retrieved directly from the blockchain, or could use information stored in the blockchain in order to retrieve the transaction details from remote data store. In either case, this allows the second merchant server 510.2 to process the transaction details, for example by importing booking details into an internal hotel reservation system.
  • the transaction is performed, for example by having the consumer stay in the hotel so that the reservation is completed.
  • Information regarding performance of the transaction is provided by the second merchant server 510.2 to the system servers 510, which in turn causes ownership of the transferrable token to be updated, either by updating token data stored in the blockchain at step 640, or by physically transferring the digital transferable token to the second merchant server 510.2. It will also be appreciated that this transfer could occur at an alternative time, such as before the transaction is performed by the second merchant, depending on the preferred implementation.
  • payment can be affected using the transferrable token at step 650, for example by having the transferrable token transferred to the payment server 510.4, either directly, or via an intermediate entity such as one of the merchants.
  • the payment service provider utilises the transferable token to identify the entities that should receive payment allowing the payment to be allocated accordingly. This could include for example allocating all of the payment to the second merchant, or could include distributing the payment between the first and second merchants, depending on any agreements in place between the merchants.
  • a user provides KYC details via their client device 530, with these being used to validate the user's identity and obtain a KYC token at step 705.
  • this could be achieved using an app installed on the client device 530, and having the user enter a user name and password or similar, with the client device 530 then validating the user identity, either locally within the app, or by communicating with the KYC server 510.3, depending on the preferred implementation.
  • the user enters credit card details, again typically via an app hosted by the client device, with the credit card details optionally being validated at step 715.
  • the KYC token and credit card are associated at step 720, with the association being stored in the blockchain at step 725.
  • the association may between the KYC token and credit card details, but more typically is between the KYC token and credit card token, which is related to the credit card details, but which stores the credit card details in a secure obfuscated form.
  • this process involves passing the credit card details to the payment server 510.4, with a credit card token representing the credit card being returned, and provided as needed.
  • a transaction commences at step 730, the user can simply provide KYC details to a merchant at step 735. For example, this can involve providing information originally used to identify the user, such as username, driver’s licence, or similar, but more typically involves generating a QR (Quick Response) code or similar using the app installed on the client device 530, with this then being presented to the first merchant server 510.1, for example by scanning the QR code with a scanner associated with the first merchant server 510.1.
  • the QR code could be generated by the app, or could be retrieved from a third party depending on the preferred implementation.
  • these can be used to retrieve the credit card details, such as the credit card token, from the blockchain at step 740, typically as part of the process of submitting the transaction details in order to create the transferable token, as described above. Once the credit card details have been retrieved these are used to obtain a payment token for the respective transaction at step 745.
  • This process can be performed by the having the first merchant server 510.1, or system servers 510, pass the credit card token to the payment server 510.4, together with transaction details, allowing the payment server 510.4 to authorise the payment and generate a payment token, such as a pre-authorisation token.
  • the payment token can be associated with the transferrable token at step 750, for example by storing this as part of the token data associated with the transferable token. This then allows a transaction to be performed at step 755 with the payment being processed using the transferrable token and payment token at step 760.
  • step 800 the user initiates a transaction with a first merchant via a merchant website hosted by the first merchant server 510.1.
  • the merchant server 510.1 generates transaction details at step 802, which may be based on information provided by the user, such as booking details for a hotel.
  • step 804 the user provides KYC details, for example using an app to generate a QR code as described above, which are then provided together with the transaction details, by the first merchant server 510.1 at step 806.
  • a transferrable token is generated at step 808 with token data including the transaction details and transferable token being stored on the blockchain at step 810.
  • this process might involve multiple steps, with information being transferred between the merchant server 510.1 and the servers implementing the blockchain, before data is actually added to the blockchain. This might be as part of a smart contract or programmed into the endpoint (that is communicating with the blockchain) as part of its requirements. This will also be different per end point as different entities may operate different systems. Accordingly, in one example, intermediate systems might be utilised in order to translate messages from one format to another, allowing the blockchain system, to understanding the relevant data and update the blockchain accordingly.
  • the consumer's identity is validated and used to retrieve the credit card token previously stored on the blockchain as described above, with this being used to seek approval for the payment at step 814, by pushing the credit card token and payment details to the payment server 510.4, either using the system servers 510, or the first merchant server 510.1, depending on the payment server 510.4 configuration.
  • a payment token authorising the payment is returned at step 816, with the payment token being associated with the transferrable token by updating the token data in the blockchain at step 818.
  • step 822 a user arrives at their hotel and provides KYC details to check in, for example generating a QR code using an app installed on their client device 530, as previously described.
  • the second merchant server 510.2 uploads KYC details to the system servers 510 at step 824, with the KYC details being validated at step 826, and used to access the token data and retrieve transaction details at step 828. This allows the merchant to confirm the users reservation, and perform the transaction at step 830, for example, by providing the consumer with access to the hotel room in accordance with the booking.
  • the merchant can upload confirmation of completion of the transaction at step 832, for example when the user checks out, causing the token data to be updated at step 834, for example, by transferring at least part ownership of the transferrable token to the second merchant.
  • the transferable token now identifies the second merchant as the entire or part owner, depending on whether the first merchant receives a payment for talking the booking.
  • Tokens including the payment token and transferrable token can then be provided to the payment server 510.4, at step 836, either by the system servers 510, or the second merchant server 510.2, allowing payments to be performed, and in particular allowing payments to be made to either the first and/or second merchants at step 838, as required based on the ownership of the transferable token.
  • one or more aspects of the process can be automated through the use of smart contracts, and an example of the operation of a smart contract will now be described with reference to Figure 9.
  • transaction details are uploaded at step 900, with the transferrable token being created at step 910 for example using processes described above.
  • the system servers 510 generate a smart contract at step 920, based on instructions in the transaction details and/or predefined systemrules. In this regard, rules might be established for particular transactions, establishing how smart contracts should be used in order to automate the transaction.
  • token data can be updated with details of the smart contract, either by storing the smart contract as part of the token data on the blockchain, or by storing the smart contract separately but with reference to the smart contract being included in the token data.
  • the smart contract specifies events that should be used to trigger execution of the contract, and the actions that should be taken on execution. In this regard the nature of the events and the associated actions will vary depending upon the preferred implementation and the nature of the particular transaction being performed.
  • the smart contract is typically generated in order to implement part of the transaction and this may therefore be triggered by information provided by the merchant servers 510.1, 510.2, external events, or any other event that can be detected by or communicated to the system servers 510.
  • information provided by the merchant servers 510.1, 510.2, external events, or any other event that can be detected by or communicated to the system servers 510 can be detected by or communicated to the system servers 510.
  • a wide range of different actions could be performed, such providing access to transaction details, causing a payment to be performed, or the like.
  • step 940 events are monitored at step 940, with the system servers 510 assessing if the contract requirements are met at step 950, and if not returning to step 940 to continue monitoring. Otherwise at step 960 the contract is performed for example by performing an action such as providing transaction details to a merchant, transferring ownership of a transferable token or the like.
  • the above described arrangement provides a singular instrument, in the form of a transferable token, that allows for interaction with a range of different merchants.
  • the transferable token could be generated associated with a holiday, with the same token then being used to access a range of services provided by different service providers, such as transit, parking, accommodation, travel, or the like.
  • the transferable token can be used both as an information exchange, allowing booking details or other transaction details to be propagated to the relevant entities, even if these operate using different incompatible platforms.
  • ownership of the token can be updated as transactions are performed, to allow payments to be allocated to different entities as needed.
  • the above described system provides a standard trusted payment network paired with a trust-less network hosting a transferable payment instrument, to control access to information and transfer of payment obligations.
  • the system further uses an embedded KYC profile, which can be used to identify consumers to different service providers, thereby facilitating the transaction process, and reducing the verification burden on both consumers and providers.
  • the system can be configured to leave existing payments infrastructure in situ, effectively adding on a blockchain to facilitate the portability of a payment instrument by pairing or proxying to an already provided FIAT token, which is indicative of currency that a government has declared to be legal tender, but it is not backed by a physical commodity.
  • FIAT token is indicative of currency that a government has declared to be legal tender, but it is not backed by a physical commodity.
  • the system can provide a blockchain merchant payment network, allowing transactions to be more easily affected between different jurisdictions.
  • the system can host Transferable Payments Protocols (TPP), which can define rules and governance, allowing compliance with rules to be embedded within the system.
  • TPP Transferable Payments Protocols
  • the system can act to provide a Payments Interchange Messaging Hub (PIMH), providing translation between various payment message types, and making it easier for different payment systems to interact.
  • PIMH Payments Interchange Messaging Hub
  • the system can also provide a Payments Interchange Connector Exchange (PICE), aggregating points of payment providers, such as Visa, Mastercard, Amex, Alipay, or the like.
  • PICE Payments Interchange Connector Exchange
  • the system can also provide a Transferable Payments Smart Contracts (TransPay), defining how to create relationships with different providers within the eco-system.
  • a transferable token referred to as a Transferable Payments Obligation (TPO) Token
  • TPO Transferable Payments Obligation
  • TPO Transferable Payments Obligation
  • the system can provide a terminal management system providing a technical layer to support payment terminals or Apps.
  • the system can integrate Pin-on-Glass as a Service, allowing a touch screen enabled system to be used to allow for entry of a secure PIN (Personal Identification Number), as part of a transaction system.
  • the blockchain system can provide an SDK (Software Development Kit), allowing third parties to create interfaces, such as APIs, that can communicate with the processing systems running the blockchain. This enables third parties to configure different services so that these can easily interact with data stored in the system.
  • the system can provide a blockchain payment network.
  • the infrastructure can work in conjunction with existing payment infrastructure, such as existing payment providers, and with existing services, such as existing merchant systems.
  • the blockchain system provides a common framework which each of these services and payment providers can interact with, thereby allowing the blockchain to effectively act as a bridge, so that payments and other information can be transferred between entities, by having each entity interface with the blockchain network. This allows payments to be transferred between relevant entities, and can facilitate business processes, by allowing transport of other relevant information, whilst avoiding the complexity of having individual systems communicate directly.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système permettant de faciliter des transactions, le système comprenant un ou plusieurs dispositifs de traitement qui obtiennent des détails de transaction concernant la transaction, la transaction comprenant un paiement, qui génèrent un jeton transférable associé au paiement, qui mémorisent des données de jeton indicatives du jeton transférable et des détails de transaction dans une mémoire de données distribuée, qui fournissent sélectivement un accès aux détails de transaction à l'aide des données de jeton afin de permettre la réalisation de la transaction, et qui font appel au jeton transférable afin de permettre des paiements à effectuer impliquant une ou plusieurs des entités.
PCT/AU2019/050916 2018-09-18 2019-08-28 Système de transaction WO2020056455A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2018903504 2018-09-18
AU2018903504A AU2018903504A0 (en) 2018-09-18 Transaction system

Publications (1)

Publication Number Publication Date
WO2020056455A1 true WO2020056455A1 (fr) 2020-03-26

Family

ID=69886790

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2019/050916 WO2020056455A1 (fr) 2018-09-18 2019-08-28 Système de transaction

Country Status (1)

Country Link
WO (1) WO2020056455A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023154203A1 (fr) * 2022-02-08 2023-08-17 Mastercard International Incorporated Procédé et système de transfert de propriété de nft (jeton non fongible) lors d'une transaction de remboursement dans un réseau de paiement

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160224977A1 (en) * 2015-01-30 2016-08-04 Yaasha Sabba Token check offline
WO2017145004A1 (fr) * 2016-02-23 2017-08-31 nChain Holdings Limited Système universel de segmentation en jetons pour des monnaies cryptographiques à enchaînement de blocs
US20170357966A1 (en) * 2016-06-09 2017-12-14 Mastercard International Incorporated Method and system for use of a proprietary private blockchain
WO2019125666A1 (fr) * 2017-12-20 2019-06-27 Mastercard International Incorporated Procédé et système permettant des paiements basés sur la confiance par l'intermédiaire d'une chaîne de blocs

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160224977A1 (en) * 2015-01-30 2016-08-04 Yaasha Sabba Token check offline
WO2017145004A1 (fr) * 2016-02-23 2017-08-31 nChain Holdings Limited Système universel de segmentation en jetons pour des monnaies cryptographiques à enchaînement de blocs
US20170357966A1 (en) * 2016-06-09 2017-12-14 Mastercard International Incorporated Method and system for use of a proprietary private blockchain
WO2019125666A1 (fr) * 2017-12-20 2019-06-27 Mastercard International Incorporated Procédé et système permettant des paiements basés sur la confiance par l'intermédiaire d'une chaîne de blocs

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023154203A1 (fr) * 2022-02-08 2023-08-17 Mastercard International Incorporated Procédé et système de transfert de propriété de nft (jeton non fongible) lors d'une transaction de remboursement dans un réseau de paiement

Similar Documents

Publication Publication Date Title
CN110612546B (zh) 用于数字资产账户管理的方法和装置
US20180322489A1 (en) System and method for restricted transaction processing
US20170293898A1 (en) Static ctyptographic currency value
US20230035321A1 (en) Systems and methods for hyperledger-based payment transactions, alerts, and dispute settlement, using smart contracts
US11861619B1 (en) Systems and methods for payment transactions, alerts, dispute settlement, and settlement payments, using multiple blockchains
US20180121908A1 (en) Cross device digital wallet payment system and process
US11616816B2 (en) Distributed ledger based document image extracting and processing within an enterprise system
CN115809871A (zh) 基于非同质化代币的商务属性
US11270313B2 (en) Real-time resource account verification processing system
US20230206198A1 (en) User interface for a biller directory and payments engine
Shaker et al. Online rating system development using blockchain-based distributed ledger technology
US20140089186A1 (en) Mobile payment service for small financial institutions
US20200302407A1 (en) Real-time resource split distribution network
WO2020140015A1 (fr) Écosystèmes de chaîne de blocs privés destinés à permettre des opérations informatiques sécurisées
CA3122951A1 (fr) Systeme et methode de mise en jeton de justificatifs electroniques
US20190102778A1 (en) Secure online transaction system and method therefor
US12008538B2 (en) Methods, apparatuses, and systems for user account-affiliated payment and billing, consolidated digital biller-payment wallets
US20170221067A1 (en) Secure electronic transaction
WO2020056455A1 (fr) Système de transaction
WO2023201359A2 (fr) Procédé, contrôleur et support lisible par ordinateur pour détecter l'expiration d'un identifiant cryptographique unique sur un réseau de transfert distribué
JP2020166601A (ja) 仲介サーバ、プログラム、及び情報処理方法
US11983683B2 (en) Processing personalized electronic healthcare payment transactions with a financing partner
US20220198442A1 (en) Secure communications for mobile wallet applications
JP7241581B2 (ja) システム及びプログラム
US20230297995A1 (en) Allocating payment transaction portions to more than one funding source via a single card

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19862163

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19862163

Country of ref document: EP

Kind code of ref document: A1