WO2006049585A1 - Systeme de paiement - Google Patents

Systeme de paiement Download PDF

Info

Publication number
WO2006049585A1
WO2006049585A1 PCT/SG2005/000376 SG2005000376W WO2006049585A1 WO 2006049585 A1 WO2006049585 A1 WO 2006049585A1 SG 2005000376 W SG2005000376 W SG 2005000376W WO 2006049585 A1 WO2006049585 A1 WO 2006049585A1
Authority
WO
WIPO (PCT)
Prior art keywords
person
payment
transaction
database
payment system
Prior art date
Application number
PCT/SG2005/000376
Other languages
English (en)
Inventor
Eng Sia Lee
Original Assignee
Mobile Money International Sdn Bhd
Mobile Money (S) Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mobile Money International Sdn Bhd, Mobile Money (S) Pte Ltd filed Critical Mobile Money International Sdn Bhd
Publication of WO2006049585A1 publication Critical patent/WO2006049585A1/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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

  • the present invention relates to electronic transaction.
  • One common form of electronic payment is based on credit card facility, such that a person makes payment by drawing on borrowed money from a credit account.
  • a physical card is typically associated with the credit account holder (via a credit account number).
  • the card is imprinted with a sixteen-digit credit card number, expiry date of the credit card and the name of the credit account holder.
  • a magnetic strip on the back of the credit card carries similar information for electronic reading. To make a purchase using a credit card, the credit account holder presents the credit card
  • the card reader then processes the payment by contacting the credit card company to pay the merchant from the credit card owner's credit account.
  • the transaction is further sealed by the credit account holder placing his signature on a receipt produced by the card reader.
  • the back of the credit card also has a signature of the credit account holder, which the merchant uses to compare signatures to ensure that the signature placed on the receipt is authentic.
  • the credit card may be stolen and the signature of the credit account holder forged by a thief in making an illegal purchase.
  • Some credit cards in attempting to provide better security, print a picture of the credit account holder onto the credit card, to assist a merchant in determining that the person making the purchase is, in fact, the person shown in the picture as the credit account holder.
  • a payment web page of the merchant merely requires the input of identification data only, such as the credit card number with verification based on the purchaser entering the card's expiry date.
  • the credit card company may often insists on the credit account holder bearing responsibility for the lost card and the illegal transactions.
  • the present invention provides a payment system comprising a first database, the first database being linked to a monetary account of a first person, a transaction approval code issued by the first database to the first person; wherein on initiation by a second person, the first database is capable of instructing a transaction on the monetary account of the first person and sending the transaction approval code to the second user; whereby the first person and the second person receive the same transaction approval code.
  • the present invention provides a payment system comprising a first database, an identity code issued by the first database to a first person, the first database being linked to a monetary account of the first person, the identity code useable by a second person to initiate the first database to make a transaction on the monetary account of the first person; wherein the identity code is useable for initiating a pre-determi ⁇ ed number of transactions on the monetary account of the first person.
  • the present invention provides a method of performing a
  • payment transaction comprising the steps of issuing a transaction approval code generated in a database to a first person, making electronic payment by the first person to a second person via the database r -the second person
  • the present invention provides a method of performing a payment transaction comprising the steps of a payment facility issuing an identity code to a registered payer, a monetary account of the payer having been linked to the payment facility, the payer providing a payee the identity code, the payee initiating a taking of payment from the payer by sending the identity code to the payment facility, payment facility authenticating the identity code to be the one issued to the payer and payment facility effects a payment transfer from the monetary account of the payer.
  • the invention may provide a third party observation and confirmation on electronic transactions.
  • the third party confirmation to both a customer and a merchant provides a closed-loop security which is not available by the conventional methods.
  • Figure 1 is a relationship diagram between entities according to an embodiment of the present invention.
  • Figure 2 is a flowchart showing the relationships as illustrated in Figure 1 ;
  • FIG. 3 is another flowchart according to the embodiment of Figure 1.
  • Figure 1 illustrates a system 0001 comprising a payment facility 0300, a bank 0400 (or a bank-like institution or system), a customer's mobile phone 0100 which is registered with the payment facility 0300, a merchant's cashier system 0200 which is linked to communicate with the payment facility 0300 by conventional communication and network technology to the payment facility 0300.
  • Figure 2 is a flowchart showing the system of Figure 1.
  • the payment facility 0300 comprises a database which contains records of the customer's mobile phone 0100 number, the customer's identity and the customer's bank account.
  • the database of the payment facility 0300 also holds records of a merchant (not illustrated), who is the owner of the cashier system 0200, and his merchant account (not illustrated).
  • the payment facility 0300 is authorised to make transactions on the customer's account in the bank 0400, particularly in debiting the customer's account for payment to a third party, such as the merchant.
  • the payment facility 0300 is operated by an independent third party payment facilitator such as those with operations similar to that of VISA or other credit management supplementary services, but alternatively may be directly operated by the bank 0400. If the payment facility 0300 is operated independently by a third party, the payment facility may be linked to work with customers each having an account in a different bank 0400.
  • the customer may use the system 0001 to make a purchase from the merchant on the customer's account registered with the payment facility 0300.
  • the customer 0100 has to receive a six-digit random identity from the payment facility 0300 which he may use to identify himself in the system 0001.
  • the random identity in this embodiment, is randomly generated in the payment facility 0300 and may be sent by SMS to the customer's mobile phone 0100 registered with the payment facility 0300 (the random identity being six-digit is only exemplary and, in practice, the random identity need not be six-digit or even totally or partially numerical).
  • the customer's mobile phone number to which the SMS is sent therefore serves as a means of authenticating the customer in this embodiment.
  • the payment facility 0300 is able to keep record and track of the random identity. The random identity is therefore recognisable by the payment facility 0300 as having been assigned to the particular customer.
  • the customer 0100 also has to have received a personal identification number (PlN) from the payment facility 0300 (or, in a variation of the embodiment, from the bank 0400).
  • PlN personal identification number
  • the customer provides the random identity to the merchant.
  • the merchant then enters the random identity appended with the customer's PIN and purchase price into the cashier system 0200 to initiate electronic payment.
  • the merchant may enter the following string into his cashier system 0200:
  • delimiters such as "#” or “_” may be provided between the random identity, PlN and purchase price to help the payment facility 0300 parse the information.
  • a string with delimiters may look like "123456#0001_34.50".
  • the cashier system 0200 then communicates the above exemplary electronic payment string to the payment facility 0300 and, in doing so, instruct the payment facility 0300 to transact on the customer's account in the bank 0400. Furthermore, the cashier system 0200 also communicates the identity of the merchant to the payment system 0300 so that the payment system knows who to make the payment to. As is known in conventional bank 0400 systems, it is not necessary that the merchant must have an account with the same bank 0400 in order for the bank 0400 to transfer money to the merchant's account; the merchant can have an account in another bank 0400 which can nevertheless receive payment. Thus, if the merchant does not have an account which is registered with the payment facility 0300, information on the merchant's bank account to be credited with the payment may also be sent by the cashier system 0200 to the payment facility 0300 when initiating payment transaction.
  • the payment facility 0300 has the necessary computing and database infrastructure to parse the string containing the random identity, the customer's PIN and the bill amount sent by the merchant, and is able to authenticate that the random identity is the one issued to the same customer
  • the payment facility 0300 Upon confirmation that the customer having the PIN is also the one who has been issued with the random identity, the payment facility 0300 communicates with the bank 0400, at 2040, to transfer the transaction/bill amount out of the customer's account to the merchant's account.
  • the bank 0400 issues an indication of successful transaction to the payment facility 0300.
  • the payment facility 0300 responds to the merchant and/or customer with an indication of successful transaction.
  • the random identity only useable for a single transaction, after which the customer has to receive another random identity from the payment facility 0300, which he may use to make another purchase.
  • the PIN on the other hand, is permanent and reusable unlike the random identity.
  • the customer enters the random identity and/or PIN himself into the merchant's web page.
  • the random identity may be useable repeatedly for an unlimited number of times, a fixed number of time, or unlimited number of time within a certain time frame after which the random identity expires and a new one has to be issued to the customer. Furthermore, the random identity may expire automatically within a predetermined period of non- use.
  • the payment facility 0300 may issue the random identity through an Internet web page, an email or a phone call etc., instead of SMS.
  • the customer himself enters the random identity and/or PIN into the merchant's cashier system 0200 while the merchant enters only the bill amount and/or the random number. This could ensure that the merchant is not shown the PIN and the customer retains confidentiality on the PIN.
  • the payment amount, along with the random identity, with or without the PIN, may be entered all together by the customer himself into the merchant's cashier system 0200.
  • the customer is not provided with a PIN to be used with the random identity.
  • the customer and merchant use the random number alone to complete the transaction, without
  • the mobile phone 0100 represents the customer's means of communication.
  • other communication systems and devices such as the PDA, email or an Internet web page may be used.
  • the cashier system 0200 comprises a microphone or receiver, such that Interactive Voice Response (IVR) technology with voice recognition capability may be used by the merchant to articulate the random identity to take payment.
  • IVR Interactive Voice Response
  • IVR Interactive Voice Response
  • the account of the customer may be any debit or credit account.
  • the customer is also pre-issued with a transaction approval code (TAC).
  • TAC transaction approval code
  • the TAC is three-digit number.
  • the TAC is useable to indicate to the customer that the random identity has been used. For example, when a payment transaction via the system 0001 on the customer's account is successful and the bank 0400 indicates to the payment facility 0300 that the transaction is successful, the payment facility 0300 sends the TAC to the merchant who then shows the TAC to the customer. As the TAG has never beeri disclosed to the merchant, the TAG which the merchant receives from the payment facility 0300 matching the TAC which the customer has been pre-issued with would assure the customer that the random identity has indeed been used for the transaction. Since the random identity expires on a single use, matching the TAG between customer and merchant assures that the merchant has not kept the random identity and PIN to himself, without actually performing the transaction, and the random identity has indeed expired on use. This prevents occasions in which the merchant may surreptitiously obtain and use the random identity and PIN for his own purposes without the customer knowing.
  • the payment facility 0300 may have the security feature of a closed-loop system, wherein the customer may be assured by both the merchant and the payment facility 0300 of the transaction having been made.
  • the TAC may be sent to the merchant by the payment facility 0300 in the form of a printout from the cashier system 0200 (which may also be used as proof of receipt).
  • the TAC may be sent to the merchant by SMS, Internet, email or a telephone call etc..
  • the merchant may also match the TAC he received from the payment facility 0300 to confirm if the customer is the person authorised to make the purchase using the random identity. This is more secure than the credit card method in which the signature and/or picture of the authorised
  • the cardholder is to be authenticated by the merchant who is not expected to be trained to identify forgery.
  • the customer may obtain the TAC from the payment facility by calling the payment facility.
  • the payment facility may have a teller or an interactive voice response to issue the TAC.
  • the PIN is to be supplied to the payment facility before the customer could obtain the TAG, and the payment facility therefore uses both the caller ID of the customer's mobile phone and his PIN to authenticate the customer.
  • the TAG may alternatively be recited verbally over the phone to the customer or may be sent via SMS to the customer.
  • electronic transaction on the customer's account whether by convention electronic methods or by the afore-mentioned random identity, is disabled until the TAG is issued.
  • the TAG is also a randomly generated number which is re-issued each time the customer makes a purchase.
  • the TAC may be a number which is issued once and is re-useable for an unlimited number of purchase by the customer.
  • the same TAG may be used for a specific number of purchases before it has to be changed, for example, after making five puchases, the TAG has to be changed and the bank 0400 issues a new one for confirming further
  • the TAC may also be issued once and is useable for a specific period of time, such as a week or a month, after which the TAC expires and a new one has to be issued to the customer.
  • a specific period of time such as a week or a month
  • the TAC expires after a period of non-use.
  • the TAG comprises numerals, alphabetical letters or a mix of both.
  • the TAC may also be an incremental number which shows the customer a cumulative number of total transactions made on his bank 0400 account via the payment facility 0300. This provides a further security measure in that the customer may be alerted that a transaction has been made on the customer's account via the payment facility 0300 without him knowing, that is, if the TAC skips an increment.
  • the incremental TAC may be reset, for example, daily, weekly, monthly, yearly or whenever the customer wishes to reset the incremental TAG.
  • the TAC may be set to start at a certain number and is reduced decrementally as the customer makes purchase transactions on the system 0100 and transactions via the payment system 0300 is disabled when the TAC reaches a minimum figure, such as "000".
  • the resetting of the TAC may be password protected, which could be used to control and monitor purchases made on the customer's account, for example, by a parent permitting a fixed number of transactions executable by his child to until the TAC is reset.
  • the embodiment may also allow the customer to provide the random number to a third party to make a purchase for him, without having to worry about the third party making more than one ' purchase without permission.
  • the TAC is not pre-issued to the customer.
  • a new TAC is issued to both the customer and the merchant at the same time which they can compare at once to ensure that the purchase has been made, and that the correct customer account has been transacted on. This prevents the TAC from being written down, stolen and used by an unauthorised person.
  • the customer may make a purchase on the Internet and receive a confirmation of the purchase, with the transaction web page showing the TAC that the customer expects to see.
  • This provides closed-loop security for Internet purchases as the TAC is issued by the payment facility 0300 directly to the customer and the TAC is also shown by the merchant web page on a successful transaction.
  • the Internet application of the TAC to confirm a transaction may be used with the random identity aforementioned, with conventional credit card or Internet banking facilities.
  • purchases are transacted on the Internet via a web page hosted by the merchant.
  • the customer makes a purchase, or fund transfer, via a web page hosted by the payment facility (or bank or bank-like institute) itself, instead of a web page hosted by the merchant.
  • the web page may not be that of the customer but of the payment facility, and the payment in made in the form of a simple fund transfer to the merchant's account from the payment facility.
  • the payment facility that has pre-issued the customer with the TAG will again send or display the same TAG to the customer, i.e. a second time, when the customer has successfully made the fund transfer.
  • a 'phishing 1 web page is a tool in a recent illegal trend in which a fake web page looking exactly like the genuine web page of a bank or payment facility misleads a customer to furnish private login information to the creator of the 'phishing' web page.
  • Such 'phishing' web pages are on the rise in recent times and banks have resorted to fight such 'phishing' web pages by sending out alerting emails to their customers, which are not very effective.
  • the customer expects to see the TAG he was pre-issued with
  • TAC After having made a fund transfer or payment via a web page, receiving the expected TAG would prove that the web page facilitating the transaction is genuine; the TAC is able to confirm that the transfer or payment has been made with the right payment facility.or bank.
  • the 'phishing' web pages are not able to issue the TAC, as the TAC issued by the payment facility or bank is confidential to only the customer and the payment facility or the bank.
  • the TAC may be used not only with a merchant to confirm a successful purchase transaction, the TAC may also be used with the same payment facility (or bank) which issues the TAC to confirm a fund transfer.
  • the receiving account may be the merchant's account. It may be that of any recipient of the fund transfer, such as a dependent or a child of the customer.
  • the customer is pre-issued by the payment facility with only the random identity and the PIN and not with the TAC.
  • the customer wants to make a purchase, the customer firstly sends the payment facility 0300, preferably via SMS 1 the random identity issued to him.
  • the customer appends at the end of the random identity the PIN and also a TAC of his own composition.
  • the SMS is sent to the payment facility 0300, the TAC of the customer's own composition is then stored in the payment facility 0300's database.
  • the customer then provides the random identity, with or without the PIN, to the merchant in making a purchase.
  • the merchant then sends the random identity, with or without the PIN, and the bill amount to the payment facility 0300 to take a payment from the customer's account in the bank 0400.
  • the payment facility 0300 responds to the merchant with the very TAC composed by the customer, and the merchant then shows the customer the TAC to confirm that the transaction has indeed been made using the random identity.
  • the customer-composed TAC may be valid for a single use; once the customer- composed TAC has been used, the customer will need to compose and send to the payment facility 0300 another self-composed TAC or the payment facility 0300 will not allow anymore transactions.
  • the customer-composed TAC may be re-useable indefinitely.
  • the customer-composed TAC may be re-useable indefinitely within a certain time frame.
  • the customer-composed TAG may be re-useable for a pre ⁇ determined number of times.
  • the customer-composed TAC expires after a pre-determined period of non-use
  • the TAC may also be used with conventional credit card payment, i.e. without using the random identity.
  • a conventional credit card company may issue the TAC to the customer for confirmation of a purchase as afore- described, or the customer may pre-send a self-composed TAC to the credit card company by SMS for use in confirming a purchase later using his credit card.
  • This third embodiment thus may provide the advantage of a personalised security measure.
  • Figure 3 is a flowchart further illustrating an embodiment.
  • a customer having an account accessible by the payment facility 0300 is supplied with a random number by the payment facility 0300, i.e. the random identity.
  • the random identity is issued by SMS through the customer's mobile phone 0100 and the random identity is recognisable by the payment facility 0300 for instructing, preferably, only one financial transaction from the customer's bank 0400 account.
  • the payment facility 0300 is linked to the customer's account in a bank 0400.
  • the customer is also been supplied with a PIN and a 3 digit TAC by the credit payment facility 0300.
  • the customer makes a purchase from the merchant and, in doing so, provides the merchant the random identity and PIN for electronic payment.
  • the merchant sends the random identity and the PIN of the client, as well as the payment amount, through the merchant's cashier system 0200 to the payment facility 0300 to take payment from the customer's bank 0400 account.
  • the payment facility 0300 authenticates that the random identity and the PIN are those that were supplied to the same account holder. If the random identity and the password were those of the same account holder, the payment facility 0300 communicates with the bank 0400 of the customer to transfer money, at 1050, from the customer's account to the merchant's account.
  • the merchant's account need not be in the same bank 0400, but could be in another bank 0400 to which the customer's bank 0400 may make a transfer.
  • step 1060 if the transaction is not successful, which may be because the random identity and/or the PIN is not recognised by the payment facility 0300, the payment facility 0300 will issue a rejection notice to the merchant and the customer, at step 1070. If the transaction is successful, at step 1060, the payment facility 0300 will inform the merchant that the transaction is successful, at step 1075. The payment facility 0300 will also send the TAC to the merchant.
  • the merchant shows the TAC to the customer to prove that the transaction has been made using the customer's random identity.
  • the customer checks to ensure that the TAC is the one he expects
  • the process repeats when the customer receives another random credit facility and TAG to make another purchase.
  • the TAG is reusable so that the customer receives another random credit facility only, without the TAG.
  • the random identity and the PIN as mentioned in the embodiments may also be termed interchangeably, the random identity may be called a random PIN while the PIN may also be termed a virtual account number.
  • the random identity may be seen as a PIN in the relationship of the parts of the system.
  • the TAG, the random identity and/or the PIN may be issued by an interactive voice response (IVR), such as those used in machine-based tellers in phone banking. It is preferable to use IVR instead of SMS where the SMS system is not suitable for the customer to receive the SMS messages without delay. Furthermore, receiving the TAG, random identity or the PIN through IVR prevents the TAC, random identity or the PIN from being read by an unauthorised person who has stolen the mobile phone or email password of the IVR.
  • IVR interactive voice response

Landscapes

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

Abstract

L'invention porte sur un système et sur un procédé de paiement sécurisé selon lequel la sécurité proposée est une confirmation en boucle fermée utilisant un code d'approbation d'application envoyé à la fois au commerçant et au client. En outre, l'invention porte également sur une identité aléatoire qui peut être utilisée conjointement avec le code d'approbation pour un achat unique, ce qui empêche le recyclage du nombre aléatoire par des malfaiteurs ayant effectué des achats de manière illégale.
PCT/SG2005/000376 2004-11-05 2005-11-02 Systeme de paiement WO2006049585A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
MYPI20044611 2004-11-05
MYPI20044611 2004-11-05
MYPI20053649 2005-08-05
MYPI20053649 2005-08-05

Publications (1)

Publication Number Publication Date
WO2006049585A1 true WO2006049585A1 (fr) 2006-05-11

Family

ID=36319466

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2005/000376 WO2006049585A1 (fr) 2004-11-05 2005-11-02 Systeme de paiement

Country Status (1)

Country Link
WO (1) WO2006049585A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008020257A1 (fr) * 2006-08-16 2008-02-21 Debitcode Kft. Procédé et système de réalisation de transactions financières électroniques
WO2012070997A1 (fr) * 2010-11-24 2012-05-31 Exformation Communication Ab Procédé de vérification sécurisée de transactions électroniques
WO2012141495A2 (fr) 2011-04-11 2012-10-18 Samsung Electronics Co., Ltd. Appareil et procédé pour fournir un service de transaction

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6078908A (en) * 1997-04-29 2000-06-20 Schmitz; Kim Method for authorizing in data transmission systems
DE20014381U1 (de) * 2000-08-21 2000-11-30 Rent A Brain Gmbh Vorrichtung zur Legitimationsprüfung
US6182894B1 (en) * 1998-10-28 2001-02-06 American Express Travel Related Services Company, Inc. Systems and methods for authorizing a transaction card
WO2002013154A1 (fr) * 2000-08-09 2002-02-14 Vodafone Holding Gmbh Procede pour le paiement a l'aide d'un telephone mobile dans des points de vente ou de prestation de services quelconques
WO2003075192A1 (fr) * 2002-03-04 2003-09-12 Creative On-Line Technologies Limited Système de transfert électronique
US20040030642A1 (en) * 2000-09-29 2004-02-12 Per Vindeby Method and arrangement for the transfer of an electronic sum of money from a credit store
US20040039651A1 (en) * 2000-09-14 2004-02-26 Stefan Grunzig Method for securing a transaction on a computer network
WO2004031899A2 (fr) * 2002-09-30 2004-04-15 Scott Sampson Validation de paiement electronique au moyen de jetons d'autorisation de transactions
US20040083168A1 (en) * 2002-07-01 2004-04-29 Rainer Kuth Payment system for cashless payment transactions

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6078908A (en) * 1997-04-29 2000-06-20 Schmitz; Kim Method for authorizing in data transmission systems
US6182894B1 (en) * 1998-10-28 2001-02-06 American Express Travel Related Services Company, Inc. Systems and methods for authorizing a transaction card
WO2002013154A1 (fr) * 2000-08-09 2002-02-14 Vodafone Holding Gmbh Procede pour le paiement a l'aide d'un telephone mobile dans des points de vente ou de prestation de services quelconques
DE20014381U1 (de) * 2000-08-21 2000-11-30 Rent A Brain Gmbh Vorrichtung zur Legitimationsprüfung
US20040039651A1 (en) * 2000-09-14 2004-02-26 Stefan Grunzig Method for securing a transaction on a computer network
US20040030642A1 (en) * 2000-09-29 2004-02-12 Per Vindeby Method and arrangement for the transfer of an electronic sum of money from a credit store
WO2003075192A1 (fr) * 2002-03-04 2003-09-12 Creative On-Line Technologies Limited Système de transfert électronique
US20040083168A1 (en) * 2002-07-01 2004-04-29 Rainer Kuth Payment system for cashless payment transactions
WO2004031899A2 (fr) * 2002-09-30 2004-04-15 Scott Sampson Validation de paiement electronique au moyen de jetons d'autorisation de transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DATABASE WPI Derwent World Patents Index; Class T05, AN 2001-042136 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008020257A1 (fr) * 2006-08-16 2008-02-21 Debitcode Kft. Procédé et système de réalisation de transactions financières électroniques
WO2012070997A1 (fr) * 2010-11-24 2012-05-31 Exformation Communication Ab Procédé de vérification sécurisée de transactions électroniques
WO2012141495A2 (fr) 2011-04-11 2012-10-18 Samsung Electronics Co., Ltd. Appareil et procédé pour fournir un service de transaction
EP2697760A2 (fr) * 2011-04-11 2014-02-19 Samsung Electronics Co., Ltd. Appareil et procédé pour fournir un service de transaction
EP2697760A4 (fr) * 2011-04-11 2014-11-19 Samsung Electronics Co Ltd Appareil et procédé pour fournir un service de transaction

Similar Documents

Publication Publication Date Title
US10521798B2 (en) Digital financial transaction system
US6834270B1 (en) Secured financial transaction system using single use codes
US7600676B1 (en) Two factor authentications for financial transactions
KR101915676B1 (ko) 카드 결제 단말 및 카드 결제 시스템
US7500602B2 (en) System for increasing the security of credit and debit cards transactions
US20060005022A1 (en) Authentication system
US20110302089A1 (en) Electronic credit card with fraud protection
KR20010025234A (ko) 지문정보를 이용한 카드거래 인증방법 및 그 시스템
JP2005521961A (ja) クレジットカードおよびデビットカードの安全な取引のためのシステムと方法
WO2007047901A2 (fr) Systemes et procedes de prevention de la fraude sur les cartes de credit
JP2002537619A (ja) クレジットカードシステム及び方法
US20060206350A1 (en) Security method and apparatus for preventing credit card fraud
JP2004054897A (ja) カード認証サーバ装置及びカード認証プログラム
WO2014108916A1 (fr) Système et procédé mis en oeuvre par ordinateur pour transactions sans carte et sans numéraire
JP3103327B2 (ja) 個人確認システム
WO2006049585A1 (fr) Systeme de paiement
US20020184143A1 (en) Khater plus system
JP2002109439A (ja) 電子決済システム、ｉｃカード、決済装置、及びそのプログラムを記録した記録媒体
WO2007006084A1 (fr) Appareil et procédé de traitement de carte
JP2007095020A (ja) カード、及び該カードを使った店頭ショッピングの取引確認及び決済処理方法、及び該カードを使ったオンラインショッピングの取引確認及び決済処理方法、及びオンラインショッピングにおける取引処理装置、及びそのプログラム並びに記録媒体。
KR100565546B1 (ko) 암호알고리즘에 의해 고유번호를 부여한 보안카드의금융거래시스템 및 그 방법과 그 방법에 대한 컴퓨터프로그램을 저장한 기록매체
JP2005182129A (ja) 自動取引装置における本人確認方法および自動取引装置
US20200410493A1 (en) Computer Implemented System and Method for Cashless and Cardless Transactions
JP2006040062A (ja) カード処理システム
JP4731362B2 (ja) 電子決済口座の認証パスワード管理装置および電子決済口座の認証パスワード管理方法

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 BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY 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): BW GH GM KE LS MW MZ NA 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 HU IE IS IT LT LU LV MC NL PL PT RO SE SI 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
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05799853

Country of ref document: EP

Kind code of ref document: A1