WO2004049273A1 - Systeme de paiement electronique entre homologues - Google Patents

Systeme de paiement electronique entre homologues Download PDF

Info

Publication number
WO2004049273A1
WO2004049273A1 PCT/SG2002/000275 SG0200275W WO2004049273A1 WO 2004049273 A1 WO2004049273 A1 WO 2004049273A1 SG 0200275 W SG0200275 W SG 0200275W WO 2004049273 A1 WO2004049273 A1 WO 2004049273A1
Authority
WO
WIPO (PCT)
Prior art keywords
peer
broker
stamp
digital note
digital
Prior art date
Application number
PCT/SG2002/000275
Other languages
English (en)
Inventor
Lakshminarayanan Anantharaman
Feng Bao
Original Assignee
Institute For Infocomm Research
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 Institute For Infocomm Research filed Critical Institute For Infocomm Research
Priority to AU2002368386A priority Critical patent/AU2002368386A1/en
Priority to PCT/SG2002/000275 priority patent/WO2004049273A1/fr
Publication of WO2004049273A1 publication Critical patent/WO2004049273A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • 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
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction

Definitions

  • the present invention relates to a peer-to-peer electronic-payment system and refers particularly, though not exclusively, to such a payment system wherein digital money is generated in a distributed manner.
  • Electronic payment systems can be broadly classified into two categories: cash-like systems and bank-account-based systems.
  • cash-like or electronic cash systems the payer/customer withdraws electronic cash tokens through an account established with a bank before purchases are made.
  • the electronic cash tokens have denomination values and may be spent with a payee/shop who in turn deposits the tokens in its own account established with the same or another bank.
  • Bank-account-based electronic payment systems include pay-now systems and pay-later systems.
  • pay-now system the payer's account is debited at the time of payment.
  • pay- later systems the payee's bank account is credited the amount of sale before the payer's account is debited.
  • bank-account-based payment systems In bank-account-based payment systems, a payment is conducted by sending an information object, whether it is a cheque or a credit card slip, from the payer to the payee.
  • the object should be self-contained with all information needed to complete the payment.
  • the information object issued by the payer carries the exact amount of payment. Since payer anonymity is not a concern in bank-account-based payment systems, such systems are naturally suited for home billing, electronic ordering, and medium-to-high value payments for electronic shopping.
  • An important problem in the design of bank-account-based payment systems is how to prevent a payer from over drawing their bank account.
  • the payee When the payee accepts to cheque from the payer, the payee should be assured that the payer's account has sufficient funds available to meet the payment.
  • One approach suggested in is analogous to that of a certified check.
  • the payer draws a check and provides the details (the cheque number, the payee and the amount) to his bank.
  • the bank places a hold on the amount of money and returns an authorization token to the payer certifying that the payer has sufficient funds to cover the check.
  • the payer presents the authorization token and the cheque to the payee. While this method works in preventing overdrawing of payer's account, it may not be suitable for on-line transactions where the amount of the payment may be negotiated in real time.
  • Peer-to-peer (P2P) systems are distributed systems where all nodes are peers in the sense that they have equal roles and responsibilities. Peer-to-peer systems presently available are mostly for free sharing of files and computation resources amongst a community of peers, such as Napster, Gnutella and Freenet. Much research has been done on peer-to-peer systems in recent years.
  • every peer can be both a merchant - to sell something - and a customer - to buy something.
  • a peer who sells something is called a merchant peer while the peer who buys something is called a customer peer.
  • An example of such a peer-to-peer commerce environment could be a community of video enthusiasts, who shoot their own videos on various topics and trade the videos with each other for entertainment.
  • the attractive feature of peer-to-peer commerce is that a person can make money provided the person has something other people want.
  • the present invention provides a peer-to-peer payment system that is similar in operation to an electronic cash system in that payers need to withdraw money (digital tokens) from a bank in advance and the tokens have fixed denomination values.
  • the system is for macro- payments catering mainly to low-to-medium value payments.
  • the system does not support full anonymity (unlinkability) for the customer, which can only be achieved using public key cryptosystems.
  • the system uses relatively lightweight computation, and avoids public key operations.
  • the system prevents double spending in a "preventio ⁇ -before-the-facf manner, where there is no need for payees to check online with banks.
  • the payee authenticates the payment directly.
  • the payment system of the present invention has a trusted party that is required to play the role of a bank.
  • a trusted bank is always necessary and must be involved whenever a payment system is created.
  • the trusted party of the present invention doesn't know what the merchant peer is selling and the merchant peer doesn't require any sensitive personal information from the customer.
  • the trusted party is not the party that produces the digital money. Instead, the money is generated by every merchant peer in a distributed manner and is validated by the trusted party by adding a stamp.
  • digital signatures are normally not used for stamping the money to keep computational requirements as low as possible. Hence, public key cryptography operations are normally not used.
  • the broker is the most trusted entity.
  • a bank or a credit card authority may be the broker role.
  • the peers involved are customer peers and merchant peers, depending on their role during a transaction. As already mentioned, these two roles are interchangeable.
  • a customer peer can be a merchant peer and vice versa.
  • a merchant peer generates digital notes in several fixed denomination values, which reflect the prices of the goods/services it is selling. Each peer has only a finite set of fixed prices for its goods. This is a reasonable assumption for a peer-to-peer commerce environment where peers mainly trade digital goods such as pictures, e-books, video/audio files etc.
  • the generated digital notes are submitted to the broker by the merchant peer for validation and stamping.
  • the notes are preferably spent only at the particular merchant peer.
  • the broker validates the notes by generating stamps for the notes, but the broker will not give the stamps to the merchant peer. Instead, the broker returns a stamp verification code to the merchant peer so that the merchant peer is able to check whether a stamp verification code from a customer peer is valid during an electronic purchase.
  • no peer can generate other peer's notes. More preferably, the broker cannot generate merchant peer's notes.
  • a customer peer withdraws the digital cash of a merchant peer - from whom an electronic purchase is desired - from the broker.
  • the customer peer purchases digital cash or notes from the broker using macro payment mechanisms such as for example, credit card payment schemes.
  • the broker gives not only the notes but also the broker stamps to the customer peer.
  • the customer peer will spend the notes at the merchant peer by giving both the notes and the stamp.
  • the merchant peer checks both the received note with its own database, and the stamp by checking it with the stamp verification code received from the broker. The merchant peer need not check online with the broker to prevent double spending.
  • a merchant peer can claim money from the broker by giving the broker stamps it received (from the customer peer) to the broker.
  • a customer peer is allowed to refund the notes and the associated stamps from the broker if the customer has not spent the money. To prevent the customer cheating by refunding spent notes, there may be specified time limits for both merchant redemption and customer refund.
  • All the previous e-payment systems adopt at least one of the following three approaches, public key cryptography, secret sharing between bank and merchant, or online checking with a trusted bank to prevent double spending.
  • the present invention does not use any of the above three approaches.
  • Public key cryptographic operations consume much computation, while online checking always decreases efficiency and introduces operational delay. Sharing of secrets between bank and merchant could lead to some advantages during the verification of digital money, however it jeopardizes the security and reliability of the system.
  • the broker is always online.
  • Merchant and customer peers are not necessarily always online.
  • Notes submission from merchant peer to broker can be done in batches. Notes can be obtained from the broker at any time, either in batches or individually.
  • the merchant peer may redeem money from the broker at any time before the deadline for redemption.
  • the customer peer can only refund notes that have not been spent after the refund starting time and before the expiry time. Refund should preferably be processed in batches to make the process more efficient.
  • Figure 1 is a schematic arrangement of the relationship between the parties when the merchant peer generates digital notes
  • Figure 2 is a view similar to Figure 1 when the merchant peer transfers the notes to the broker for stamping;
  • Figure 3 is a view similar to Figure 2 when the customer peer purchases digital money
  • Figure 4 is a view similar to Figure 3 when a customer peer purchases from a merchant peer;
  • Figure 5 is a view similar to Figure 4 when a merchant peer obtains a redemption from the broker.
  • Figure 6 is a view similar to Figure 5 when a customer peer refunds un-spent money.
  • KeyedHash ⁇ A(X) means that X is hashed using a secret key K A .
  • a Keyed-hashing algorithm is also referred to as MAC (message authentication code) algorithm
  • Hash(X) means that X is hashed with a one-way hash algorithm
  • the present invention includes the following variables:
  • K erchantPeer is the secret key used by the merchant peer (and known only to the merchant peer) to key hash the digital notes.
  • KBroker is the secret key used by the broker (and known only to the broker) to key hash the digital notes.
  • IDMerchantPeer is the identification of the merchant peer.
  • 4- ID ⁇ roker is the identification of the broker.
  • IDCustomer i the identification of the customer.
  • SerNum is the unique serial number associated with every digital note. The merchant peer generates this serial number.
  • Value refers to the denomination value of the digital note. There can be multiple denomination values but it may be necessary to have notes with reasonably low denomination values since the protocol does not support the concept of change. The exact amount has to be supplied during a purchase.
  • T1 is the expiry time for the merchant peer to seek redemption from the broker.
  • T2 is the start time for the customer peer to seek refund from the broker.
  • T3 is the expiry time for the digital note.
  • SVC is the stamp verification code explained in the next section.
  • IDMaterial IDMerchantPeer, Value, SerNum, TO, T1, T2, T3
  • the Merchant Peer then transfers the created digital notes to a broker, and the broker adds a broker stamp.
  • the broker then transfer the SVC to the merchant peer and the stamped digital note is ready for circulation.
  • the stamped unspent digital note should be kept secret and protected by the entity possessing it, either by the broker or customer As shown in Figure 3, customer peers may have a long-term relationship with the broker.
  • the merchant peer then approves the transaction and transfers the goods/services purchased to the customer peer.
  • the customer peer transfers the broker stamp (whose hash should be equal to the SVC).
  • a merchant peer can redeem the value of digital cash before time T1 associated with the digital cash.
  • the merchant peer has to reveal the broker stamp to the broker, the broker stamp having been transferred to the merchant peer by customer peer during the transaction.
  • the broker checks for validity of the broker stamp, and if valid, credits the merchant peer's account.
  • FIG 6 there is shown the process by which a customer peer can seek refund of any unused digital cash.
  • time T2 has elapsed and before time T3 (expiry time)
  • a customer peer can approach the broker for a refund.
  • a customer peer cannot seek refund of digital cash already spent because the merchant peer would have redeemed real money in lieu for spent digital cash transferred to it by the customer.
  • the broker checks for the validity of the unspent digital cash (especially the broker stamp) and refunds the customer peer.
  • the digital cash is considered invalid.
  • the merchant peer should have redeemed real money for any digital cash spent by a customer peer at its site by time T1.
  • ⁇ specifies the maximum tolerable difference in time between the clock of the broker (assumed to have a reliable clock) and a peer.
  • the creation of digital cash and its purchase by customer peers remains the same.
  • a merchant peer should seek redemption before T1.
  • the broker should however entertain redemption requests up to T1 + ⁇ , according to the broker's clock.
  • a customer peer should seek refund from the broker between time T2 and time T3. However, the request should be made (according to the broker's clock) any time after T2 - ⁇ , but before T3 + ⁇ .
  • the broker may eliminate notes after expiry at T3 + ⁇ .
  • the system of the present invention does not use a public key operation. Moreover, double spending does not require verification with a centralized server. As such the system can be highly efficient.
  • the customer peer the most vulnerable entity, has sufficient safeguards to protect against fraud by the merchant peer (which should be considered less trustworthy than a established web commerce site). Moreover this scheme also ensures that the merchant peer does not have to obtain sensitive customer information to complete a transaction. As such, a compromise of a merchant peer is not severe, and damage can be easily localized.
  • the system can prevent and deter wrongdoing on the part of any of the entities involved, especially the peers, in a peer-to-peer environment.
  • the digital notes generated by the merchant peer are protected by the keyed hash of the merchant peer. So it is impossible for any other party to create the digital notes.
  • the digital notes are stamped (keyed hash of the broker) by the broker and the SVC transferred to the merchant peer.
  • the merchant peer does not know the broker stamp at that time and cannot create broker stamps of its own. Only the customer peer and the broker know the broker stamp as well as the SVC.
  • the merchant peer When a customer peer uses digital cash, the merchant peer removes the particular digital stamped note from its database. This prevents double spending. The customer peer cannot spend the digital money at any other merchant peer. The customer peer cannot seek refund for digital money before time T2. This prevents the customer peer from spending money and still seeking refund from the broker.
  • the merchant peer cannot seek redemption of spent digital cash from the broker unless it can provide the correct broker stamp for each digital note. So the merchant peer cannot seek redemption for fraudulent money it creates on its own.
  • Each stamped digital note has an expiry date. So compromises are time limited. Compromise of the merchant peer's secret key will not compromise the system since the attacker also needs the broker's secret key to create valid digital money.
  • the main module used by the customer peer will be a wallet software.
  • the wallet software is preferably capable of securely communicating with the broker as well as various merchant peers. It also preferably maintain an audit log of all transactions and manage digital notes from various merchant peers.
  • the wallet preferably has the customer peer's machine inform the customer peer of impending refund expiry times of digital cash stored in it the customer's machine.
  • the digital money of the various customer peers may be stored on a central server, possibly by the broker.
  • a merchant peer is an entity that is interested in selling goods/services on-line. They may not be a well-established e-merchant, and might not have the resources to be a full-time e- merchant It is possible that they can be students or amateurs. Hence, they may not be meticulous in managing their on-line site. Moreover they might not be on-line all the time.
  • the merchant peer may have a payment gateway and a "digital money creation" module. Since the broker stamps the digital notes created by the merchant peer, even if an attacker compromises the merchant peer server and steals digital notes (even with the SVCs), they will not be able to be use because when a customer peer makes a purchase, the customer peer has to reveal the broker stamp (whose hash is the original SVC). Only the broker and the relevant customer peer know the broker stamp. So even if the merchant peer database is stolen, it cannot be misused.
  • the broker is preferably the most trusted entity and may be operated by a bank or a credit card institution, or a similar organization.
  • the broker has secure facilities to house servers to which merchant and customer peers make connections.
  • the broker is preferably on-line all the time.
  • the relationship between the broker and a customer peer may be long-term.
  • the broker may be the guarantor for the customer peers.
  • the broker redeems stamped digital notes from the merchant peer only when it receives the correct broker stamps before time T1.
  • the merchant peer should possess valid broker stamps only if a customer peer has transferred them to the merchant.
  • real money is transferred to the merchant peer only when the broker is fully satisfied that the customer peer has transferred the broker stamps to the merchant peer.
  • the three main entities, broker, merchant peer and customer peer need to communicate with each other. They may use standard network security protocols such as SSL over HTTP (HTTPS).
  • SSL over HTTP HTTPS
  • the broker in this protocol plays that role.
  • the broker may use traditional risk management strategies used by banks, and other financial institutions to associate risk with a peer.
  • Merchant peers as well as customers peers may be rated according to their credit history.
  • a customer peer can become a merchant peer and credit histories of one kind can be used to determining risk category of another. For example, a new merchant peer might fall into a "very risky" category while a long-standing merchant peer might fall into a "reliable" category.
  • the evaluation of "risk” should be done by the broker, and can be determined not only on the credit history of the merchant peer but also based on factors such as reliability and load handling capabilities of the merchant peer servers, merchant peer's management practices, whether the merchant peer servers have been compromised earlier, and so forth.
  • the broker may charge a transaction fee on each digital note transacted.
  • the broker may request for a deposit from the merchant peer, especially for a new merchant peer. Risk categories can change with time. In this way, the broker can not only protect its own interests but also the interests of other peers. Brokers may reveal ratings of merchant peers to a requesting customer peer to enable the customer peer to evaluate the risk involved in a transaction.
  • Customer peers may also be rated.
  • a new customer peer may be considered unreliable with regard to a longstanding customer.
  • Customer peer rating can be used to determine the liability the broker is willing to accept if there is a purchase dispute between the customer peer and merchant peer. For example, if a long standing customer peer complains about a transaction with an unreliable merchant peer, the broker might be willing to compensate the customer peer and deduct an equivalent amount from the deposit submitted by the merchant peer.
  • the broker may be a computer system of a financial or other organization, and both the merchant and customer peers may be computers of a merchant and customer respectively.
  • the present invention also extends to a computer usable medium comprising a computer program code configured to cause a processor to execute one or more functions to perform the methods described herein.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention a trait à un procédé de transactions financières entre homologues comportant les étapes suivantes : la génération par un premier homologue d'au moins un billet numérique et la soumission dudit au moins un billet numérique à un courtier pour validation et affranchissement, le courtier produisant un timbre pour ledit au moins un billet numérique et un code de vérification de timbre ; et l'envoi du code de la vérification de timbre au premier homologue ; l'achat par un deuxième homologue dudit au moins un billet numérique à partir du courtier, le courtier fournissant au moins ledit un billet numérique et le timbre au deuxième homologue ; la fourniture par le deuxième homologue au premier homologue dudit au moins un billet numérique affranchi et le code de vérification de timbre, mais sans le timbre du courtier, en contrepartie pour des biens/services ; la vérification par le premier homologue dudit au moins un billet numérique et du code de vérification de timbre ; et le transfert par le deuxième homologue au premier homologue du timbre du courtier.
PCT/SG2002/000275 2002-11-27 2002-11-27 Systeme de paiement electronique entre homologues WO2004049273A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2002368386A AU2002368386A1 (en) 2002-11-27 2002-11-27 Peer to peer electronic-payment system
PCT/SG2002/000275 WO2004049273A1 (fr) 2002-11-27 2002-11-27 Systeme de paiement electronique entre homologues

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2002/000275 WO2004049273A1 (fr) 2002-11-27 2002-11-27 Systeme de paiement electronique entre homologues

Publications (1)

Publication Number Publication Date
WO2004049273A1 true WO2004049273A1 (fr) 2004-06-10

Family

ID=32391121

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2002/000275 WO2004049273A1 (fr) 2002-11-27 2002-11-27 Systeme de paiement electronique entre homologues

Country Status (2)

Country Link
AU (1) AU2002368386A1 (fr)
WO (1) WO2004049273A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130254052A1 (en) * 2012-03-20 2013-09-26 First Data Corporation Systems and Methods for Facilitating Payments Via a Peer-to-Peer Protocol
AU2011207108B2 (en) * 2010-01-19 2014-06-26 Bluechain Pty Ltd Method, device and system for securing payment data for transmission over open communication networks
CN105205666A (zh) * 2014-06-17 2015-12-30 中国银联股份有限公司 基于蓝牙的面对面支付方法及系统
WO2019214235A1 (fr) * 2018-05-07 2019-11-14 北京三快在线科技有限公司 Traitement de transaction électronique
US11379824B2 (en) * 2018-06-20 2022-07-05 International Business Machines Corporation Privacy preserving transactions with probabilistic transaction fees

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0391261A2 (fr) * 1989-04-03 1990-10-10 Nippon Telegraph And Telephone Corporation Méthode et dispositif pour réaliser de la monnaie électronique
WO1997009688A2 (fr) * 1995-08-29 1997-03-13 Microsoft Corporation Moyen de paiement electronique anonyme
US5802497A (en) * 1995-07-10 1998-09-01 Digital Equipment Corporation Method and apparatus for conducting computerized commerce
US5850442A (en) * 1996-03-26 1998-12-15 Entegrity Solutions Corporation Secure world wide electronic commerce over an open network
US6021399A (en) * 1996-11-25 2000-02-01 Xerox Corporation Space efficient method of verifying electronic payments

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0391261A2 (fr) * 1989-04-03 1990-10-10 Nippon Telegraph And Telephone Corporation Méthode et dispositif pour réaliser de la monnaie électronique
US5802497A (en) * 1995-07-10 1998-09-01 Digital Equipment Corporation Method and apparatus for conducting computerized commerce
WO1997009688A2 (fr) * 1995-08-29 1997-03-13 Microsoft Corporation Moyen de paiement electronique anonyme
US5850442A (en) * 1996-03-26 1998-12-15 Entegrity Solutions Corporation Secure world wide electronic commerce over an open network
US6021399A (en) * 1996-11-25 2000-02-01 Xerox Corporation Space efficient method of verifying electronic payments

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2011207108B2 (en) * 2010-01-19 2014-06-26 Bluechain Pty Ltd Method, device and system for securing payment data for transmission over open communication networks
US11263625B2 (en) 2010-01-19 2022-03-01 Bluechain Pty Ltd. Method, device and system for securing payment data for transmission over open communication networks
US20130254052A1 (en) * 2012-03-20 2013-09-26 First Data Corporation Systems and Methods for Facilitating Payments Via a Peer-to-Peer Protocol
US9818098B2 (en) * 2012-03-20 2017-11-14 First Data Corporation Systems and methods for facilitating payments via a peer-to-peer protocol
CN105205666A (zh) * 2014-06-17 2015-12-30 中国银联股份有限公司 基于蓝牙的面对面支付方法及系统
WO2019214235A1 (fr) * 2018-05-07 2019-11-14 北京三快在线科技有限公司 Traitement de transaction électronique
US11379824B2 (en) * 2018-06-20 2022-07-05 International Business Machines Corporation Privacy preserving transactions with probabilistic transaction fees

Also Published As

Publication number Publication date
AU2002368386A1 (en) 2004-06-18

Similar Documents

Publication Publication Date Title
TWI822653B (zh) 以令牌化來進行以區塊鏈為基礎的匯兌
US5956699A (en) System for secured credit card transactions on the internet
US6119229A (en) Virtual property system
US7596530B1 (en) Method for internet payments for content
US6157920A (en) Executable digital cash for electronic commerce
US6889325B1 (en) Transaction method and system for data networks, like internet
Hwang et al. A simple micro-payment scheme
EP2624190A1 (fr) Authentification de transactions de paiement utilisant un alias
JP2002543523A (ja) インターネットのようなデータネットワークの取引方法及びシステム
Banerjee et al. A prototype design for DRM based credit card transaction in E-commerce.
JP2004503018A (ja) 少額決済処理を管理するためのシステム及び方法、並びに対応するクライアント端末及び小売商装置
WO2001044968A2 (fr) Systeme et procede de transaction
Masseport et al. Proof of usage: User-centric consensus for data provision and exchange
Catalano et al. A fair micro-payment scheme for profit sharing in P2P networks
WO2004049273A1 (fr) Systeme de paiement electronique entre homologues
CN106203986A (zh) 一种网络支付方法、装置、资金管理服务器和系统
Herzberg Micropayments
JPWO2020010383A5 (fr)
TW201229934A (en) An trusted transaction evidence method
Al-Meaither Secure electronic payments for Islamic finance
Peláez et al. Application of electronic currency on the online payment system like PayPal
Balasubramanian et al. Electronic payment systems and their security
Papaioannou et al. Towards a Blockchain-Enabled Trustworthy Market Framework
Nguyen et al. A secure and efficient micropayment system
Fram et al. Altered states: electronic commerce and owning the means of value exchange

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP