EP3563277A1 - Système de paiement électronique anonyme - Google Patents

Système de paiement électronique anonyme

Info

Publication number
EP3563277A1
EP3563277A1 EP16926019.7A EP16926019A EP3563277A1 EP 3563277 A1 EP3563277 A1 EP 3563277A1 EP 16926019 A EP16926019 A EP 16926019A EP 3563277 A1 EP3563277 A1 EP 3563277A1
Authority
EP
European Patent Office
Prior art keywords
payer
certificate
payee
transaction
client device
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP16926019.7A
Other languages
German (de)
English (en)
Inventor
Ingo Barth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verimatrix GmbH
Original Assignee
Verimatrix GmbH
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
Application filed by Verimatrix GmbH filed Critical Verimatrix GmbH
Publication of EP3563277A1 publication Critical patent/EP3563277A1/fr
Withdrawn legal-status Critical Current

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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/383—Anonymous user system

Definitions

  • the present invention relates generally to payment of funds electronically and more specifically to obscuring the identities of each party to a payment transaction.
  • a method for hiding the identities of a payer and a payee from each other in an electronic payment transaction includes providing payment information to a payer client device making a payment transaction for a payer to a payee, where the payment information includes a payment amount, sending, by the payer client device, a request for a payer certificate to a payer transaction processor, sending, by the payer transaction processor, a payer certificate to the payer client device, where the payer certificate includes information uniquely identifying the payer only to the payer transaction processor and no other entity, sending, by a payee client device receiving the payment transaction for the payee, a request for a payee certificate to a payee transaction processor, sending, by the payee transaction processor, a payee certificate to the payee client device, where the payer certificate includes information uniquely identifying the payer only to the payer transaction processor and no other entity, sending, by the payee client device, the payee certificate
  • the method also includes sending a transaction request for the payment information from the payer client device to the payee client device, and receiving, by the payer client device from the payee client device, a message including the payment information.
  • the request for a payer certificate includes payment parameters and the payment parameters includes a maximum authorized amount.
  • generating a transaction certificate from at least some of a set of transaction information includes taking a hash over the at least some of a set of transaction information and verifying the transaction certificate includes taking a hash and comparing the result.
  • generating a transaction certificate from at least some of a set of transaction information includes encrypting the at least some of a set of transaction information using the payer's private key in a public-private key pair and verifying the transaction certificate includes decrypting the encrypted transaction information using the payer's public key in the public-private key pair.
  • the method also includes sending a request for purchase of a piece of content using the payer client device, where the request for purchase includes a device identifier associated with the payer client device and a content identifier associated with the piece of content, receiving, by the payer client device, the payment information and the payee certificate in response to the request for purchase, and creating an entitlement to play back the piece of content after the funds have been transferred to the payee transaction processor.
  • the payee certificate is visually represented by and displayed as a QR-code.
  • the method also includes generating the payer certificate using the payer client device, where generating the payer certificate includes taking a hash as SHA(R1
  • Fig. 1 is a system overview illustrating client devices and transaction processors that can interact process an anonymous payment in accordance with an embodiment of the invention.
  • FIG. 2A conceptually illustrates components of a payer client device in accordance with embodiments of the invention.
  • FIG. 2B conceptually illustrates components of a payer transaction processor in accordance with embodiments of the invention.
  • FIG. 3A conceptually illustrates components of a payee client device in accordance with embodiments of the invention.
  • FIG. 3B conceptually illustrates components of a payee transaction processor in accordance with embodiments of the invention.
  • Fig. 4 is a flow chart illustrating a process for transacting an anonymous payment using payer and payee certificates in accordance with embodiments of the invention.
  • Fig. 5 is a message diagram illustrating a process for transacting an anonymous payment using payer and payee certificates in accordance with embodiments of the invention.
  • Anonymous electronic systems in accordance with embodiments of the invention provide anonymity in that the payer and payee need not exchange information that can directly identify each other, i.e., their identities are obscured to each other, and instead utilize a payer transaction processor and a payee transaction processor as intermediaries that mask the identities of each party (payer and payee).
  • a payer using a payer client device, identifies itself with a payer transaction processor (which can be a server or other machine controlled by a bank or other financial institution) and obtains a payer certificate.
  • the payer certificate is a piece of data with which the payer transaction processor, but no other entity, can identify the payer.
  • a payee using a payee client device, identifies itself with a payee transaction processor (which can be a server or other machine controlled by a bank or other financial institution) and obtains a payee certificate.
  • the payee certificate is a piece of data with which the payee transaction processor, but no other entity, can identify the payee.
  • a "certificate" identifies the entity the certificate is granted to but only with the entity granting the certificate.
  • only the partnering transaction processor can create and later verify a certificate that it grants to its partner that is a party to the transaction (e.g., payer or payee).
  • the payer certificate and payee certificate are one-time use only.
  • the payer and payee exchange their certificates, which are embedded into the payment transaction.
  • the payer and/or payee can take part in a transaction without revealing account information, e.g., account number, credit card number, etc.
  • the transaction details such as what has been bought, is only known to the payer and the payee. While each transaction processor only knows the identity of its own partner client, but not about party on the other side of the transaction. If required by law or otherwise compelled to, the two transaction processors can "recombine" the data to reveal which partners have been involved.
  • an anonymous system utilizing payer and payee certificates includes a payer client device and a payee client device, as well as a payer transaction processor and a payee transaction processor that act as intermediaries.
  • An anonymous payment system in accordance with embodiments of the invention is illustrated in FIG. 1.
  • the illustrated system 100 includes a payer transaction processor 102 configured to communicate with a payer client device 104 or 106, a payee transaction processor 108, and/or a payee client device 114 or 116 over a network 110, such as the Internet.
  • the system 100 includes a payee transaction processor 112 configured to communicate with a payee client device 114 or 116, a payer transaction processor 102, and/or a payer client device 104 or 106 over the network 110.
  • payer client devices include mobile phone 104 and personal computer 106.
  • Payee client devices include mobile phone 114 and personal computer 116.
  • payer or payee client devices can include any of various types of consumer electronics devices such as, but not limited to, tablets, laptop computers, and other devices that are capable of connecting to a network.
  • FIG. 2A A payer client device in accordance with an embodiment of the invention is illustrated in FIG. 2A.
  • the payer client device 202 includes a processor 204 and non-volatile memory 210 that includes an anonymous payment application 212 and optionally transaction seed data 214 that can be used to generate a payer certificate.
  • the non-volatile memory 210 is utilized to store instructions via the payment application 212 that configure the processor 204 to perform processes such as those discussed further below.
  • an anonymous payment application can be loaded from any kind of memory or storage device including volatile memory in accordance with many embodiments of the invention.
  • the anonymous payment application 212 can configure the payer client device 202 to communicate with a payee client device and/or a payer transaction processor as will be discussed further below.
  • FIG. 2B A payer transaction processor in accordance with an embodiment of the invention is illustrated in FIG. 2B.
  • the payer transaction processor 220 includes a processor 222 and non-volatile memory 224 that includes an anonymous payment application 226 and optionally transaction seed data 228 that can be used to generate a payer certificate.
  • the non-volatile memory 224 is utilized to store instructions via the payment application 226 that configure the processor 222 to perform processes such as those discussed further below.
  • an anonymous payment application can be loaded from any kind of memory or storage device including volatile memory in accordance with many embodiments of the invention.
  • the anonymous payment application 226 can configure the payer transaction processor 220 to communicate with a payer client device and/or a payee transaction processor as will be discussed further below.
  • FIG. 3A A payee client device in accordance with an embodiment of the invention is illustrated in FIG. 3A.
  • the payee client device 310 includes a processor 312 and non-volatile memory 314 that includes an anonymous payment application 316.
  • the non-volatile memory 314 is utilized to store instructions via the payment application 316 that configure the processor 312 to perform processes such as those discussed further below.
  • an anonymous payment application can be loaded from any kind of memory or storage device including volatile memory in accordance with many embodiments of the invention.
  • the anonymous payment application 316 can configure the payee client device 310 to communicate with a payer client device and/or a payee transaction processor as will be discussed further below.
  • FIG. 3B A payee transaction processor in accordance with an embodiment of the invention is illustrated in FIG. 3B.
  • the payee transaction processor 320 includes a processor 322 and non-volatile memory 324 that includes an anonymous payment application 326.
  • the non-volatile memory 324 is utilized to store instructions via the payment application 326 that configure the processor 322 to perform processes such as those discussed further below.
  • an anonymous payment application can be loaded from any kind of memory or storage device including volatile memory in accordance with many embodiments of the invention.
  • the anonymous payment application 326 can configure the payee transaction processor 320 to communicate with a payee client device and/or a payer transaction processor as will be discussed further below. Payer and payee certificates are discussed next.
  • a payer certificate and payee certificate is a piece of data plus information that can be used to validate the correctness of the data, where the ability to perform the validation is restricted to certain entities (e.g., a transaction processor). As the transaction certificates are only to be verified by the transaction processors that create them, this can be done with either symmetric or asymmetric mechanisms. In several embodiments, when a transaction certificate has been checked by a transaction processor in making a payment transaction it will be invalidated for the future.
  • Transaction information available to each party can contain at least a transaction number, an identifier of the transaction processor that created the data, the transaction information, and/or a certificate for the data. It can also include additional information such as the amount of money to be transaction, currency, and/or an expiration date for the transaction information.
  • the payer and/or payee client devices can be mobile devices where the data and certificates are transmitted between a payer and payee using, e.g., QR-codes (Quick Response Codes).
  • QR-codes Quick Response Codes
  • the payer and payee can be the buyer and seller, respectively, in a transaction. The payment could also be applied to normal buying situations, e.g., in a supermarkets.
  • the store would request a payee transaction certificate and state a requested value and provide these to the buyer, for example, with a QR-code or other visual or electronic message.
  • a payment application on the mobile phone of the buyer/payer would read the code or message, request a payer certificate from a payer transaction processor, receive a payer certificate created by the payer transaction processor, and then provide the data as a new QR-code to the QR-reader associated with a payee client device in the store. The store can then complete the transaction and receive its payment.
  • the transaction certificates should not contain any information about the client. It can be just a number (e.g., random or pseudo-random), best together with the limited cash amount and the time when this certificate expires.
  • This data could be hashed, e.g. by adding some random data at the beginning and this random data could be stored in the database of the bank for this transaction. This data is not published. To verify the certificate the hash is calculated again, using the stored random data and if it matches the certificate has not been manipulated, if it does not match, the data has been modified.
  • Several embodiments utilize this mechanism of only hashing and does not require encryption or asymmetric algorithms.
  • Signing with symmetric data can be performed as follows.
  • D represents the data to be signed.
  • Rl and R2 represents some random information that is stored by the signer.
  • SHA(...) is a hash function over the data, a
  • a certificate can be generated as SHA(R1
  • Rl and R2 are not revealed to other parties and the hash function cannot be reversed, the certificate can only be created and therefore also verified by the owners of Rl and R2.
  • the creation and verification are done by the same entity, even the algorithm can be different.
  • Rl and R2 can be transaction seed data that is provided to a payer client device by a payer transaction processor, and not revealed to any other entity.
  • D includes an identification of the payer and the amount of money to be transferred, as well as a payer certificate or reference to the payer certificate.
  • Payee certificates can be verified as authentically belonging to the payee (and not an imposter) to a payer by signing the payee certificate with a signature that can only be attributed to the payee, such as the payee's private key or authentication through a trusted authority.
  • the payer provides the payee transaction number to his payer transaction processor to include it into the transaction certificate and hence the transaction certificate is only valid for this one operation. Processes for sending an anonymous electronic payment in accordance with embodiments of the invention are discussed below.
  • a payer client device sends (410) a transaction request to a payee client device.
  • the transaction request informs the payee that the payer would like to make a payment to the payee and requests a payee certificate that identifies the payee with the payee transaction processor.
  • the payee client device responds (412) to the request by sending payment information, which can include information such as, but not limited to, a payment amount, currency, and/or date of execution.
  • the payee client device can also send payee transaction data that includes information from the payee side that is relevant to the transaction, such as identification of the goods or services being paid for by the transaction.
  • the payee transaction data can accompany a payee certificate.
  • the payee transaction data may not be used in generating a transaction certificate while the payee certificate is.
  • payer transaction data that includes information from the payer side that is relevant to the transaction, such as a shipping address or physical or virtual destination for the purchased goods, can accompany a payer certificate but not be used in generating a transaction certificate.
  • the payer client device requests and receives (414) a payer certificate from the payer transaction processor.
  • the request for a payer certificate includes some payment parameters, such as a maximum amount of money to authorize.
  • the payer transaction processor puts a hold on that amount of money in the payer's account until the transaction is no longer valid due to timing out (e.g., the payer certificate, transaction certificate, and/or payee certificate expire) or the transaction has completed. If the payer's account does not have enough money to cover the requested amount, no payer certificate is created.
  • the payee client device requests and receives (416) a payee certificate from the payee transaction processor.
  • a request for a payer certificate or payee certificate involves verifying the payer or payee's identity with the respective payer or payee transaction processor.
  • the payer identifies himself with the payer transaction processor by communicating a one-time-use identifier and transaction number encrypted by a transaction processor key unique to the payer transaction processor, where only the payer transaction processor knows the transaction processor key.
  • a payer transaction processor can create a payer certificate to provide to a payer client device by any of a variety of techniques, and similarly for a payee transaction processor creating a payee certificate for a payee client device.
  • a client device requests a certificate by providing payee or payer information to create a certificate and receives the certificate from the respective transaction processor.
  • the transaction processor generates the certificate in response to the request.
  • the payer transaction processor can provide the payer client device with payer information to create a payer certificate that can be verified by the payer transaction processor and can only be used in the context of the given transaction.
  • the payer client device provides the payer's public key, of a public and private key pair used in public-private key cryptography, to the payer transaction processor and creates the certificate using the payer's own private key.
  • any of the above techniques could be combined.
  • a payee transaction processor can conduct any of the same processes for a payee certificate for a payee client device.
  • the payee client device sends (418) the payee certificate to the payer client device.
  • a payee certificate is not used, but in this case a misuse of the data could happen before it is used for the real transaction.
  • the interaction between the payee client device and the payee transaction can be more trusted without using a payee certificate if there is a secure communications channel between the two.
  • the payer client device obtains (420) a transaction certificate.
  • An entity in many embodiments the payer client device creates a unique transaction certificate only used for that transaction, which is invalidated or expired once used.
  • the transaction certificate includes a maximum authorized amount.
  • a transaction certificate is generated, such as by taking a hash value over some or all of the transaction information (e.g., payment information, payer certificate, and/or payee certificate) and/or some data that is only known to the payer client device (transaction seed data) and the payer transaction processor and is not transferred or known to the payee or any other entity.
  • the payer transaction processor can create such random data and store it as part of the transaction and fetch it when the transaction is finished. This can be performed using symmetric or asymmetric cryptography.
  • the transaction certificate is generated using some or all of the transaction information and the payer's private key in a public-private key pair.
  • the payer client device sends (422) the payment information (which can include a payment amount, currency, and/or date of execution), payer certificate, payee certificate, and transaction certificate to the payee client device.
  • the payer client device creates a certificate over this complete data using the payer certificate information received from the payer transaction processor or by using the payer's private key.
  • the payee client device checks whether the payment information corresponds with the payment information that it previously sent to the payer client device and whether the received payee certificate is correct. If these are verified, the payee client device sends (424) all this information unchanged to the payee transaction processor (e.g., the seller's bank).
  • the payee transaction processor extracts the payee certificate from the received data and checks that it is valid for the requesting payee. If it is, the payee transaction processor forwards (426) the data unchanged to the payer transaction processor. In several embodiments, the payee transaction processor need not forward the portions including transaction information of the payee, such as identification of goods or services that are paid for by the transaction.
  • the payer transaction processor verifies (428) the transaction certificate as well as the payer certificate.
  • the transaction certificate can be verified by using the payer's public key, if the payer's private key was used to generate the transaction certificate, and/or the transaction seed data if that was used to generate the transaction certificate. If both transaction certificate and payer certificate are verified as authentic, the payer transaction processor withdraws the money from the payer's account in the amount contained in the payment information and transfers it to the payee transaction processor.
  • the money transfer includes some information indicative of the transaction, such as the payer and/or payee transaction numbers for the transaction and/or a reference to the payee certificate.
  • the payee transaction processor informs the payee that the payment has been made and puts the money in the payee's account.
  • the payer transaction processor can also inform the payer that the transaction has completed.
  • a transaction may fail. For example, data may be corrupted, a transaction may time-out after certain amount of time has passed, or a transaction certificate may have already been used.
  • the payer transaction processor and the payee transaction processor are the same entity. In other embodiments they are different entities. For transparency it could be better to have separate payer and payee transaction processors, and for the payer and payee to register independently to each transaction processor if they wish to continue transacting.
  • the payer and payee transaction processors may be required to keep the transaction information for a certain period of time to analyze the flow of funds between payer and payee, e.g., to fight money laundering.
  • Fig. 5 provides a different view of the interactions and exchanges between a payer client device, payer transaction processor, payee transaction processor, and payee client device in accordance with embodiments of the invention by way of a message diagram. Although a specific process for performing anonymous electronic payments is discussed above with respect to Figs. 4 and 5, one skilled in the art will recognize that any of a variety of processes may be utilized in accordance with embodiments of the invention.
  • an end-user knows an individual identifier of his client device that he wants to use for content consumption. Besides this device identifier (e.g., a smartcard number, MAC address, serial number, etc.) the end-user can determine a content identifier (ID) which identifies the content that he wants to order.
  • ID can also identify a channel subscription for a defined time. This content ID can be provided through a web-interface through which the end-user orders his content. The ordering can also be performed on the device itself whereby the device ID can be accessible by the ordering application directly.
  • an end-user When an end-user (buyer) tries to order content, he utilizes a payer client device to send an order request to the operator containing his device ID and the content ID.
  • the content provider requests a payee certificate from his bank (payee transaction processor) and forwards the payee certificate to the end-user.
  • the end-user's payer client device requests his payer certificate from his bank (payer transaction processor) and creates, using the payee certificate, the payer certificate, and the payment data, which contains the device ID and the content-ID, his transaction certificate.
  • the data plus the transaction certificate are sent to the content provider which forwards the data to its bank (payee transaction processor) which verifies the payee certificate and forwards the data to the buyer's bank (payer transaction processor).
  • the buyer's bank verifies the payer certificate and the transaction certificate and transfers the money to the seller's bank which then transfers the money to the content provider's account and informs the content provider about the successful payment.
  • the content provider now creates an entitlement for the given device ID for the requested content ID, which enables playback of the particular piece of content.
  • the entitlement is provided to the payer client device or other playback device used by the buyer to play back the content.
  • the ordering can be performed directly using the device, e.g., using an EPG (electronic programming guide or on-screen guide) to select the content.
  • EPG electronic programming guide or on-screen guide
  • the end-user does not need to know the device ID nor the content ID when the device itself can obtain the identifiers. While a specific implementation of abstract payments with respect to pay TV content is discussed above, one skilled in the art will recognize that variations of such a design may be utilized in accordance with different embodiments of the invention.

Landscapes

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

Abstract

L'invention concerne, selon des modes de réalisation, des systèmes et des procédés de de paiement électronique anonyme . Dans un mode de réalisation, un procédé pour cacher les identités d'un payeur et d'un bénéficiaire consiste à fournir des informations de paiement à un dispositif client de payeur, à recevoir un certificat de payeur, le certificat de payeur comprenant des informations identifiant de manière unique le payeur uniquement au processeur de transaction de payeur, la réception d'un certificat de bénéficiaire, le certificat de payeur comprenant des informations identifiant de manière unique le payeur uniquement au processeur de transaction de payeur, l'envoi du certificat de bénéficiaire au dispositif client de payeur, générer un certificat de transaction, envoyer le certificat de payeur, le certificat de bénéficiaire et le certificat de transaction au dispositif client de bénéficiaire, envoyer le certificat de payeur reçu, le certificat de bénéficiaire, et le certificat de transaction au processeur de transaction de bénéficiaire, envoyer le certificat de payeur reçu, le certificat de bénéficiaire et le certificat de transaction au processeur de transaction de payeur, et transférer les fonds au processeur de transaction de bénéficiaire.
EP16926019.7A 2016-12-30 2016-12-30 Système de paiement électronique anonyme Withdrawn EP3563277A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/069595 WO2018125234A1 (fr) 2016-12-30 2016-12-30 Système de paiement électronique anonyme

Publications (1)

Publication Number Publication Date
EP3563277A1 true EP3563277A1 (fr) 2019-11-06

Family

ID=62710284

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16926019.7A Withdrawn EP3563277A1 (fr) 2016-12-30 2016-12-30 Système de paiement électronique anonyme

Country Status (2)

Country Link
EP (1) EP3563277A1 (fr)
WO (1) WO2018125234A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110889681A (zh) * 2019-10-31 2020-03-17 支付宝(杭州)信息技术有限公司 一种基于数字货币的匿名交易方法及系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6192142B1 (en) * 1994-11-28 2001-02-20 Smarttouch, Inc. Tokenless biometric electronic stored value transactions
KR100358426B1 (ko) * 1998-08-18 2003-01-29 한국전자통신연구원 전자현금거래방법
US8868467B2 (en) * 2002-10-23 2014-10-21 Oleg Serebrennikov Method for performing transactional communication using a universal transaction account identifier assigned to a customer
US20080228651A1 (en) * 2003-09-29 2008-09-18 Zan Tapsell Public Key Crytography Method and System
US20090198618A1 (en) * 2008-01-15 2009-08-06 Yuen Wah Eva Chan Device and method for loading managing and using smartcard authentication token and digital certificates in e-commerce
US20110208600A1 (en) * 2010-02-25 2011-08-25 Seergate Ltd. Point of Sale Payment System and Method
US10210497B2 (en) * 2011-04-06 2019-02-19 OnDot Systems, Inc. System and method for cashless peer-to-peer payment
US20140067661A1 (en) * 2012-08-30 2014-03-06 Strategic Engineering Group, LLC Virtual check system and method
US20140236819A1 (en) * 2013-02-18 2014-08-21 Bank Of America Corporation Payment System For Issuing And Depositing Paperless Checks
US20140337206A1 (en) * 2013-05-10 2014-11-13 Albert Talker Electronic Currency System

Also Published As

Publication number Publication date
WO2018125234A1 (fr) 2018-07-05

Similar Documents

Publication Publication Date Title
KR102322646B1 (ko) 블록체인 내의 스마트 계약에 기초하여 거래 활동의 민감한 데이터를 보호하기 위한 방법 및 디바이스
US20220051237A1 (en) Secure remote payment transaction processing using a secure element
US10511583B2 (en) Hybrid integration of software development kit with secure execution environment
US10846663B2 (en) Systems and methods for securing cryptocurrency purchases
CN108476227B (zh) 用于设备推送供应的系统和方法
AU2015259162B2 (en) Master applet for secure remote payment processing
CN105745678B (zh) 包括消费者认证的安全远程支付交易处理
JP5294880B2 (ja) メール注文及び電話注文における二要素認証を実施するための方法及びシステム
US20150278806A1 (en) E-payment architecture preserving privacy
US20120254041A1 (en) One-time credit card numbers
US11756029B2 (en) Secured end-to-end communication for remote payment verification
EP3837804A1 (fr) Clés de jeton pour générer des cryptogrammes pour des interactions de jeton
WO2018125234A1 (fr) Système de paiement électronique anonyme
Pant A secure online payment system
US11812260B2 (en) Secure offline mobile interactions

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20190708

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200701