EP3563277A1 - Anonymous electronic payment system - Google Patents

Anonymous electronic payment system

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)
French (fr)
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/en
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)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Systems and methods for anonymous electronic payment transactions in accordance with embodiments of the invention are disclosed. In one embodiment, a method for hiding the identities of a payer and a payee includes providing payment information to a payer client device, receiving a payer certificate, where the payer certificate includes information uniquely identifying the payer only to the payer transaction processor, receiving a payee certificate, where the payer certificate includes information uniquely identifying the payer only to the payer transaction processor, sending the payee certificate to the payer client device, generating a transaction certificate, sending the payer certificate, the payee certificate, and the transaction certificate to the payee client device, sending the received payer certificate, payee certificate, and transaction certificate to the payee transaction processor, sending the received payer certificate, payee certificate, and transaction certificate to the payer transaction processor, and transferring the funds to the payee transaction processor.

Description

ANONYMOUS ELECTRONIC PAYMENT SYSTEM
FIELD OF THE INVENTION
[0001] The present invention relates generally to payment of funds electronically and more specifically to obscuring the identities of each party to a payment transaction.
SUMMARY OF THE INVENTION
[0002] Systems and methods for anonymous electronic payment transactions between two devices in accordance with embodiments of the invention are disclosed. In one embodiment, 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 to the payer client device, generating a transaction certificate from at least some of a set of transaction information, where the set of transaction information includes the payment information, the payer certificate, the payee certificate, and transaction seed data, where the transaction seed data is known only to the payer client device, sending, by the payer client device, the payment information, the payer certificate, the payee certificate, and the transaction certificate to the payee client device, verifying, using the payee client device, the payment information and the payee certificate received from the payer client device, sending, by the payee client device, the received payment information, payer certificate, payee certificate, and transaction certificate to the payee transaction processor when the received payee certificate is verified as correct, verifying, using the payee transaction processor, the received payee certificate, sending, by the payee transaction processor, the received payment information, payer certificate, payee certificate, and transaction certificate to the payer transaction processor when the received payee certificate is verified as correct, verifying, using the payer transaction processor, the received transaction certificate and payer certificate, and deducting funds that total to the payment amount from a payer's account by the payer transaction processor and transferring the funds to the payee transaction processor with a reference to the payee certificate when the received transaction certificate is verified as correct.
[0003] In a further embodiment, 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.
[0004] In another embodiment, the request for a payer certificate includes payment parameters and the payment parameters includes a maximum authorized amount.
[0005] In a still further embodiment, 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.
[0006] In still another embodiment, 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.
[0007] In a yet further embodiment, 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.
[0008] In yet another embodiment, the payee certificate is visually represented by and displayed as a QR-code.
[0009] In a further embodiment again, 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 | D | R2), where Rl and R2 are random information known only to the payer client device and D represents the data to be signed. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] 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.
[0011] Fig. 2A conceptually illustrates components of a payer client device in accordance with embodiments of the invention.
[0012] Fig. 2B conceptually illustrates components of a payer transaction processor in accordance with embodiments of the invention.
[0013] Fig. 3A conceptually illustrates components of a payee client device in accordance with embodiments of the invention.
[0014] Fig. 3B conceptually illustrates components of a payee transaction processor in accordance with embodiments of the invention.
[0015] 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.
[0016] 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.
DETAILED DISCLOSURE OF THE INVENTION
[0017] Turning now to the drawings, anonymous electronic payment systems utilizing payer and payee certificates in accordance with embodiments of the invention are disclosed. Many types of electronic and online payment systems are available to consumers. At the same time, there is a desire with some consumers for privacy and anonymity with respect to certain payment transactions or generally with all their online activity. While paying in cash provides the greatest possibility of masking the payer's identity, it is not always convenient. Many existing electronic payment methods always include some identifying information from a payer in the transaction to the payee. Debit and credit cards include the cardholder's name as an essential part of a transaction using such a card. Bitcoin identifies a payer to a payee when the same bitcoin address is used in a subsequent transaction.
[0018] 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. Similarly, 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. In many embodiments, 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).
[0019] In several embodiments, 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. In this way, the payer and/or payee can take part in a transaction without revealing account information, e.g., account number, credit card number, etc.
[0020] In further embodiments, 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.
Anonymous Payment System Architecture
[0021] In many embodiments of the invention, 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.
[0022] In the illustrated embodiment, payer client devices include mobile phone 104 and personal computer 106. Payee client devices include mobile phone 114 and personal computer 116. In other embodiments, 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.
[0023] Although a specific anonymous payment system architecture for processing payments is discussed above with respect to FIG. 1, any of a variety of architectures can be utilized in accordance with embodiments of the invention.
Payer Client Devices and Payer Transaction Processors
[0024] 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. In the illustrated embodiment, 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. In several embodiments, 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.
[0025] 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.
[0026] 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. In the illustrated embodiment, 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. In several embodiments, 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.
[0027] 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.
[0028] 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. In the illustrated embodiment, 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. In several embodiments, 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.
[0029] 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.
[0030] 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. In the illustrated embodiment, 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. In several embodiments, 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.
[0031] 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.
Payer and Payee Certificates
[0032] In many embodiments of the invention, 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.
[0033] Transaction information available to each party (payer and payee) 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. [0034] In many embodiments of the invention, 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). 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.
[0035] 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.
[0036] 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 | b symbolizes the concatenation of a and b with b following a. Then, a certificate can be generated as SHA(R1 | D | R2). As long as 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. For the transaction certificates, where the creation and verification are done by the same entity, even the algorithm can be different. In other embodiments, it is possible to use random data associated with the transaction number, stored together with the transaction number in a database, and only verify the random number. The stored certificates or random data can be stored encrypted in the database as well. 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. In several embodiments, 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. One skilled in the art will recognize that any of a variety of mechanisms can be utilized to generate a certificate by signing with symmetric or asymmetric algorithms in accordance with embodiments of the invention.
[0037] 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.
[0038] In further embodiments of the invention, 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.
Processes for Sending an Anonymous Electronic Payment
[0039] A process for sending an anonymous electronic payment using payer and payee certificates in accordance with embodiments of the invention is illustrated in Fig. 4. In several embodiments, 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. In some embodiments, 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. In the following interactions, the payee transaction data can accompany a payee certificate. However, in many embodiments the payee transaction data may not be used in generating a transaction certificate while the payee certificate is. Similarly, 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.
[0040] The payer client device requests and receives (414) a payer certificate from the payer transaction processor. In several embodiments, 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.
[0041] The payee client device requests and receives (416) a payee certificate from the payee transaction processor. In many embodiments, 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. In some embodiments, 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. In several embodiments, 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. In various embodiments, the transaction processor generates the certificate in response to the request.
[0042] Alternatively, 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. In additional embodiments, 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. In further embodiments, any of the above techniques could be combined. As mentioned, a payee transaction processor can conduct any of the same processes for a payee certificate for a payee client device.
[0043] The payee client device sends (418) the payee certificate to the payer client device. In other embodiments, 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. Thus, 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.
[0044] 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. In several embodiments, the transaction certificate includes a maximum authorized amount. In some embodiments, 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. In some embodiments, 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.
[0045] 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.
[0046] 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.
[0047] 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. In many embodiments, 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.
[0048] In some embodiments, when the money transfer with the payee certificate has reached the payee transaction processor, 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. [0049] Under several conditions, 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.
[0050] In some embodiments 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.
[0051] In further embodiments, 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.
[0052] 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.
Application in a Pay TV Environment
[0053] There might be situations in which a customer wants to consume video content without exposing his identity or bank details. Such situations have some conventional solutions for the buyer to remain anonymous, e.g., by buying a voucher at one place and using this voucher to order content from the service operator at another place.
[0054] With an anonymous payment system as described above, an anonymous ordering of content can be done in the following way, although others may be contemplated within the scope of embodiments of the invention.
[0055] Assume that 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. A content 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. [0056] 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. In response to this request, the content provider (seller) 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.
[0057] If the application on the payer client device can perform the payer-to-transaction processor operations 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. In such a situation 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.
Conclusion
[0058] Although the description above contains many specificities, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the presently preferred embodiments of the invention. Various other embodiments are possible within its scope. Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:
1. A method for hiding the identities of a payer and a payee from each other in an electronic payment transaction, the method comprising:
providing payment information to a payer client device making a payment transaction for a payer to a payee, wherein 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 comprises 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 comprises information uniquely identifying the payer only to the payer transaction processor and no other entity;
sending, by the payee client device, the payee certificate to the payer client device; generating a transaction certificate from at least some of a set of transaction information, where the set of transaction information comprises the payment information, the payer certificate, the payee certificate, and transaction seed data, where the transaction seed data is known only to the payer client device;
sending, by the payer client device, the payment information, the payer certificate, the payee certificate, and the transaction certificate to the payee client device;
verifying, using the payee client device, the payment information and the payee certificate received from the payer client device;
sending, by the payee client device, the received payment information, payer certificate, payee certificate, and transaction certificate to the payee transaction processor when the received payee certificate is verified as correct;
verifying, using the payee transaction processor, the received payee certificate;
sending, by the payee transaction processor, the received payment information, payer certificate, payee certificate, and transaction certificate to the payer transaction processor when the received payee certificate is verified as correct;
verifying, using the payer transaction processor, the received transaction certificate and payer certificate; and deducting funds that total to the payment amount from a payer's account by the payer transaction processor and transferring the funds to the payee transaction processor with a reference to the payee certificate when the received transaction certificate is verified as correct.
2. The method of claim 1, further comprising 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.
3. The method of claim 1, wherein the request for a payer certificate comprises payment parameters and the payment parameters comprises a maximum authorized amount.
4. The method of claim 1 , wherein generating a transaction certificate from at least some of a set of transaction information comprises taking a hash over the at least some of a set of transaction information and verifying the transaction certificate comprises taking a hash and comparing the result.
5. The method of claim 1 , wherein generating a transaction certificate from at least some of a set of transaction information comprises 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 comprises decrypting the encrypted transaction information using the payer's public key in the public-private key pair.
6. The method of claim 1, further comprising sending a request for purchase of a piece of content using the payer client device, where the request for purchase comprises 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.
7. The method of claim 1, wherein the payee certificate is visually represented by and displayed as a QR-code.
8. The method of claim 1, further comprising generating the payer certificate using the payer client device, where generating the payer certificate comprises taking a hash as SHA(R1 I D I R2), where Rl and R2 are random information known only to the payer client device and D represents the data to be signed.
EP16926019.7A 2016-12-30 2016-12-30 Anonymous electronic payment system Withdrawn EP3563277A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/069595 WO2018125234A1 (en) 2016-12-30 2016-12-30 Anonymous electronic payment system

Publications (1)

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

Family

ID=62710284

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16926019.7A Withdrawn EP3563277A1 (en) 2016-12-30 2016-12-30 Anonymous electronic payment system

Country Status (2)

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

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110889681A (en) * 2019-10-31 2020-03-17 支付宝(杭州)信息技术有限公司 Anonymous transaction method and system based on digital currency

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 (en) * 1998-08-18 2003-01-29 한국전자통신연구원 Electronic Cash Transaction Method
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
WO2014036452A1 (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 (en) 2018-07-05

Similar Documents

Publication Publication Date Title
KR102322646B1 (en) Method and device for protecting sensitive data of transaction activity based on smart contract in blockchain
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 (en) System and method for device push provisioning
AU2015259162B2 (en) Master applet for secure remote payment processing
CN105745678B (en) Secure remote payment transaction processing including consumer authentication
JP5294880B2 (en) Method and system for performing two-factor authentication in email and phone orders
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
WO2020036931A1 (en) Token keys to generate cryptograms for token interactions
WO2018125234A1 (en) Anonymous electronic payment system
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