WO2001065501A1 - A method of performing a transaction - Google Patents
A method of performing a transaction Download PDFInfo
- Publication number
- WO2001065501A1 WO2001065501A1 PCT/SG2001/000047 SG0100047W WO0165501A1 WO 2001065501 A1 WO2001065501 A1 WO 2001065501A1 SG 0100047 W SG0100047 W SG 0100047W WO 0165501 A1 WO0165501 A1 WO 0165501A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transaction
- customer
- card
- identification code
- payment card
- Prior art date
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
-
- 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/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
-
- 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
- G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
Definitions
- This invention relates to electronic (e-) commerce, in particular to a method of performing transactions (e.g. credit, debit or charge card) over the Internet or other data network.
- transactions e.g. credit, debit or charge card
- a user In an e-commerce transaction, a user (customer) will go to a desired merchant's on-line site either by surfing the world-wide-web to reach the merchant's website or, via a dedicated network, logging into either the merchant's server directly or on to a trading community's server.
- the user will select the products or services to be purchased.
- the user then proceeds to a payment instruction screen and typically the settlement is made with a credit card.
- the user keys in his credit card information which is sent to the merchant.
- the merchant then typically (not necessarily) sends the number on-line to the acquiring bank to verify that the credit card number is active (i.e. not suspended). If the acquiring bank confirms that the credit card number is valid, the merchant then proceeds to deliver the products/services to the user. After a period of time (e.g. few days or whatever has been agreed), the acquiring bank pays the merchant.
- the merchant when the merchant receives the credit card information from the user (customer), he can only verify through the acquiring bank if the card identified by the information is valid and active, or not. The merchant is not able to verify if the credit card information was passed to him by the bona fide owner or by someone 'posing' as the owner.
- the existing credit card policy under what is known as MOTO transactions (Mail Order Telephone Order) states that in the event that the credit card is not physically sighted (and thereby the owner does not physically sign the payment slip), the owner of the card is able to repudiate or reject payment for the transaction unless the merchant is able to prove otherwise that the bona fide user executed the transaction. In most e-commerce cases, this is not possible.
- a method of performing a transaction over a data network between a customer and a vendor using a payment card or account comprising the steps of: prior to a transaction using the method, assigning and advising a customer of an identification code associated with the number of the card or account and storing the identification code in association with the card or account number; and at the time the transaction occurs, receiving the identification code from the customer over the data network, establishing the card or account number from the identification code, communicating with the customer telephonically to confirm the transaction, obtaining an authorization of the confirmed transaction using the card or account number and communicating the authorization to the vendor.
- a confirmation code is provided to the customer and at the time of the transaction, the customer confirms the transaction using the confirmation code.
- the confirmation code may be a PIN or may be related to the biometrics of the customer.
- a telephone number of the customer is stored in association with the identification code and the method may further comprise the step, at the time the transaction occurs, of calling the customer using the telephone number to confirm the transaction or of the customer calling from the telephone number to confirm the transaction.
- the payment card is preferably a credit card, debit card or charge card.
- the identification code may be associated with more than one payment card or account with the method further comprising the step of requesting a selection of payment card/account by the customer. The selection may be made at the time the customer confirms the transaction.
- the step of communicating with the customer telephonically may be via one of a mobile telephone link or a fixed-line.
- the step of obtaining authorization of the confirmed transaction may comprise the step of the vendor's bank seeking authorization of the confirmed transaction from an institution associated with the payment card or account.
- the identification code may be stored in a central registry with the central registry informing the vendor's bank of the card or account number or the vendor's bank sends the identification code to the central registry which seeks authorization from the institution on behalf of the vendor.
- the institution may include the customer's bank, credit card company or a utility company.
- the identification code is preferably in a compatible format to the payment card or account number.
- the customer also preferably provides, at the time the transaction occurs, an identifier which identifies a transaction using the method and the identifier may comprise modified name information of the payment card or account or may form part of the identification code.
- the customer also provides payment card expiry date information or a substitute therefor.
- a method of modifying a payment card transaction over a data network in which a customer supplies payment card information to a vendor on-line, said information comprising a payment card number, a card name and a card expiry date and the information is supplied by the customer completing a virtual form to be sent to the vendor, the form having fields of a fixed configuration to receive the information, the modification comprising the steps of, prior to a transaction using the method, assigning and advising the customer of an identification code corresponding to the payment card number to be used in place thereof and storing the identification code in association with the card number; and at the time the transaction occurs, determining if a said identification code has been sent by the customer and if so, establishing the card number from the identification code, communicating with the customer telephonically to confirm the transaction and obtaining an authorization of the confirmed transaction using the card number and, if not, seeking authorization of the card number directly, and communicating the authorization to the vendor.
- the payment card may be a physical card or a virtual card.
- the data network may be the Internet or any other data network.
- the invention extends to apparatus for performing the claimed methods.
- no card or account information is passed by the customer over the data network to the vendor.
- the customer can simply send a pre-registered identification code which in itself is of no use if intercepted since it is not the code which confirms the transaction which is performed subsequently by the customer using the telephone.
- the step of confirmation by the customer provides a way for the vendor to confirm that the payment instruction is given by the bona fide user of the payment card.
- the described embodiment offers authorization by the registered user for unsighted credit card transactions (in an electronic way similar to having a user sign in black & white on the payment slip).
- the described embodiment uses commonly available digital cellular (or fixed line) telephones e.g. GSM, as an ID device to obtain authentication from the bona fide user.
- Digital phones e.g. GSM encrypt their identification number and also its transmission making this a secure channel. Combined with an optional secret PIN that the user keys in during the transaction process, make the telephone a mobile authentication device.
- Communication between the Central Registry and the mobile phone may be through standard network supported voice or data messaging, for example (but not limited to) simple DTMF signalling (Dual-Tone-Multi- Frequency) over a standard circuit switched network such that no enhancements or new features are required of the service/network provider.
- standard network supported voice or data messaging for example (but not limited to) simple DTMF signalling (Dual-Tone-Multi- Frequency) over a standard circuit switched network such that no enhancements or new features are required of the service/network provider.
- the invention does not exclude the use of an enhanced dedicated messaging system to facilitate communication.
- the interactive and active use of a telephone to authenticate and confirm the identity of the cardholder may be deemed to be equal to a physical signature on a vendor receipt that authorizes a contract between a vendor and a customer.
- the described embodiment also uses existing credit card payment infrastructure without having the user transmit his credit card information over the Internet for every transaction (this information is sent once to the Central Registry and thereafter kept in its record).
- the described embodiment is transparent to the merchant's software as long as this supports on-line credit card clearance with the acquiring bank.
- the described embodiment is able to work on standard digital cellular phones e.g. GSM and does not require any special or new features and does not require any special software or modifications from the network provider.
- FIGS. 1A-2C show the transaction steps when using the method of the described embodiment of the invention.
- a transaction using the method will now be described involving use of a credit card over the Internet.
- the described method is equally applicable for use with other types of payment card such as charge cards and debit cards over other kinds of data network such as a Wireless Application Protocol (WAP) network.
- WAP Wireless Application Protocol
- Customer Internet businesses or individual consumers that conduct commerce over the Internet.
- Current payment methods targeted include credit card and on-line debit payments
- Issuing Bank (3) Issuers of credit cards or on-line debit services
- Acquiring Bank (4) Acquirers of credit card and/or debit card merchant transactions in the Internet Commerce or physical payments world.
- Central Registry (6) A clearing and settlement facility that provides basis for identification with non-repudiation.
- the parties to the transaction are similar to the parties to a standard MOTO credit card settlement process discussed in the prior art. While the figures do not explicitly present the Internet infrastructure such as Internet portals and websites, it is implicit that there may be such intermediaries between a customer or a business and the central registry. The only difference is that the central registry is located with either the acquiring bank or with the credit card company for the purpose of validating and authenticating the user so that the credit card transaction becomes non- repudiable.
- the user 1 and merchant 2 are connected by the Internet.
- the connections between the merchant 2, central registry 6, acquiring bank 4 credit card company 5 and issuing bank 3 are by secure fixed lines.
- Central registry 6 also has an ability to telephone the user via a fixed or mobile line.
- a user 1 registers with the central registry 6 by providing details of the credit card, in particular the credit card number and, optionally, name and expiry date.
- the user may register more than one credit card of any other payment method but must indicate the preferred default payment card.
- the central registry then confidentially issues the user with an identification code, which may be of any format for example numerical or alpha-numerical but generally one that can be readily input using a computer keyboard and instructions for use in a transaction using the method.
- the format of the identification code is flexible according to implementation but must fulfil the following criteria (a) it should be distinguishable uniquely from a 'normal' card information (b) it should be able to pass through standard software seamlessly for example by being in a format similar to a 'normal' card.
- One example of an implementation is as follows:
- the identifier can be included in the identification code (below), for example by using a unique identifier for transaction using the described embodiment, in the first four digits of the code.
- a unique identification code is assigned, with the same field sequence as a standard credit card eg. XXXX-XXXX-XXXX- XXXX where "X" is a number from 0-9.
- X is a number from 0-9.
- Such a sequence is used in Visa and Mastercard, for example but other field sequences are used, for example by Diners Club which uses an XXXX-XXXXX-XXXX format.
- Existing credit card transaction software can deal with these different kinds of numbers already and only a requirement that the unique identification code is able to be passed on seamlessly through such software in a similar manner to a credit card number.
- the identification code may (but need not) be selected in dependence upon the format of the payment card with which it is associated.
- For the card expiry date field either this can remain the same or a substitute expiry date in the same month-year format i.e. MM-YY is assigned, for example relating to the expiry of usage of the transaction
- a user further provides the central registry with a telephone number with which the central registry can contact the user to confirm the transaction as will be hereinafter described and may be issued with a confidential confirmation code for this purpose.
- the confirmation code may be of any type, for example a PIN or a code other than a number, for example based on voice pattern recognition, with the user of providing, in a registration phase, a spoken phrase which, when prompted for the code subsequently, he speaks into his mobile phone. Other biometrics or other kinds of confirmation codes may also be used.
- the telephone number is of a mobile phone or two-way pager although, if the user can be sure that he will be contactable over a fixed line at his computer terminal, a fixed line telephone number can be given.
- the identification code provides two functions. The first is to provide information that enables the central registry 6 to distinguish the identification code from any ordinary credit card number which is received and the second is to provide a means to allow the user to be identified uniquely.
- step 3.1.1 the user reaches the on-line site of the merchant and decides that he wishes to purchase a product or service.
- the identification information (TMX) follows the same field and description format as the standard credit card information i.e. a name field (TM_NAME) which comprises the card name preceded by an identifier (e.g. TELEMONEY, as described above), credit card number (TM_CC#) which comprises the identification code and an expiry date (TM_EXP). Some sites may not require the name and expiry date information, in which case the identification code is all that is entererd.
- the user's purchase details and payment information are both passed on to the merchant via the on-line site (3.2.1 and 3.2.2).
- the merchant keeps the purchase to himself (to be used later on for delivery fulfillment) and passes on the payment information (TMX) to the Central Registry for clearance.
- TMX payment information
- the Central Registry On receipt of a payment clearance request by the merchant (3.3.1) the Central Registry begins a process to verify the user and the status of his credit card number (3.3.2). Based on the identification information (TMX), the Central Registry will check its database to retrieve the user's details (registered telephone number, PIN etc.) and his pre-selected credit card number to be billed for this transaction (CCN).
- TMX identification information
- the Central Registry To verify the user (3.3.3), the Central Registry establishes a phone connection with the user's predefined mobile phone. Either the Central Registry can call the user or the user can call the Central Registry to establish this connection. Once the connection is established, the Central Registry may then either prompt the user to key in his secret PIN on his mobile phone or simply hit one key to confirm and a different key to reject payment for the transaction or to reject payment. If the user rejects payment (3.1.4), the transaction is aborted and the Central Registry immediately sends a message to the merchant to inform him that payment was rejected.
- the Central Registry will receive the user's secret PIN and will cross-reference this PIN with the user's details stored in its database. If all the details check-out, the Central Registry will consider the payment as having been authorized by the bona fide user (3.3.4) In parallel or sequentially, the Central Registry having received the identification information (TMX) for the payment clearance request, will translate the data into the registered user's credit card information (CCN) (3.3.5). This credit card information will need to be verified through the acquiring bank's network to ensure that it is active and that the available credit balance will cover the payment being requested for (3.3.6). To do this, the Central Registry sends the user's credit card information (CCN) to the acquiring bank through the existing settlement network (3.4.1 )
- the acquiring bank then proceeds to acquire the transaction (3.4.2) as with any other credit card transaction and proceeds to verify that the card number and the value to be paid through its existing settlement network with the credit card company (3.4.3 and 3.5.1 through 3.5.4). If the card number is active and the value is approved, then the acquiring bank will receive an approval reference back from the settlement network (3.4.4).
- the acquiring bank Having received the approval reference, the acquiring bank then notifies the Central Registry (3.3.8) which similarly sends a message to the merchant that the payment request has been approved (3.2.3)
- the merchant on receiving the approval reference from the Central Registry will then complete the transaction process by optionally informing the user that the payment instruction has been approved (3.1.6) by providing an electronic receipt (which receipt may be given over the Internet connection, by separate e- mail or may be directed back to the central registry for onward transmission to the user's mobile telephone as a SMS message) and then subsequently following through with the delivery of the product or service (3.2.4).
- an electronic receipt which receipt may be given over the Internet connection, by separate e- mail or may be directed back to the central registry for onward transmission to the user's mobile telephone as a SMS message
- step 3.3.2 if the Central Registry determines that the identification information does not include an identification code and is, consequently a normal credit card number, the Central Registry jumps directly to step 3.4.1 so that the identification information is passed directly to the acquiring bank.
- the central registry may have a different position in the back-end, e.g.: a. between the merchant & the acquiring bank b. between the acquiring bank & the credit card co. c. 'with' the merchant d. 'with' the acquiring bank e. 'with' the credit card co. f. 'with' the issuing bank g. between the credit card co. and the issuing bank
- Streaming of transactions received by the merchants into those with normal credit card numbers and those with identification codes need not be made by the central registry but may, for example, be made by the acquiring bank.
- the identification code may be associated with more than one payment card, account or method, with a selection of account to be used being made by the user using his mobile phone at the time the notification of transaction and request for a confirmation code is received.
- the institution associated with the payment need not be a bank or credit card company but may, for example, be a finance company, utility company such as a telephone company or any other institutions with which the customer has a financial arrangement which allows payments to be made.
- the "payment card" would be wholly virtual in nature with the identification code simply being associated with an account number for the utility company from which any purchases would be debited.
- the use of the identification code thus provides a high degree of flexibility in the method of payment that may be used depending upon the accounts, payment methods and payment institutions which are associated with the identification code.
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP01918143A EP1269430A1 (en) | 2000-03-03 | 2001-02-22 | A method of performing a transaction |
AU45009/01A AU4500901A (en) | 2000-03-03 | 2001-02-22 | A method of performing a transaction |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SG200001130-4 | 2000-03-03 | ||
SG200001130 | 2000-03-03 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2001065501A1 true WO2001065501A1 (en) | 2001-09-07 |
Family
ID=20430536
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/SG2001/000047 WO2001065501A1 (en) | 2000-03-03 | 2001-02-22 | A method of performing a transaction |
Country Status (5)
Country | Link |
---|---|
US (1) | US20030120592A1 (en) |
EP (1) | EP1269430A1 (en) |
CN (1) | CN1418355A (en) |
AU (1) | AU4500901A (en) |
WO (1) | WO2001065501A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005055162A1 (en) * | 2003-11-26 | 2005-06-16 | Splat Thief, Incorporated | User self-authentication system and method for remote credit card verification |
EP1704530A2 (en) * | 2003-12-18 | 2006-09-27 | Safe-In Ltd. | System for the secure identification of the initiator of a transaction |
EP2015242A1 (en) * | 2007-06-26 | 2009-01-14 | Alcatel Lucent | Method and system for securing online transactions |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030018522A1 (en) * | 2001-07-20 | 2003-01-23 | Psc Scanning, Inc. | Biometric system and method for identifying a customer upon entering a retail establishment |
US10657561B1 (en) | 2008-08-20 | 2020-05-19 | Modiv Media, Inc. | Zone tracking system and method |
US10430798B2 (en) | 2002-10-23 | 2019-10-01 | Matthew Volpi | System and method of a media delivery services platform for targeting consumers in real time |
US20040128197A1 (en) * | 2002-10-23 | 2004-07-01 | Vayusa, Inc. | System and method of generating, distributing, and/or redeeming promotional offers using electronic devices |
US20040083170A1 (en) * | 2002-10-23 | 2004-04-29 | Bam Ajay R. | System and method of integrating loyalty/reward programs with payment identification systems |
US11257094B2 (en) | 2002-10-23 | 2022-02-22 | Catalina Marketing Corporation | System and method of a media delivery services platform for targeting consumers in real time |
US8783561B2 (en) | 2006-07-14 | 2014-07-22 | Modiv Media, Inc. | System and method for administering a loyalty program and processing payments |
US20050216354A1 (en) * | 2002-10-23 | 2005-09-29 | Vayusa, Inc. | System and method for coordinating payment identification systems |
US9811836B2 (en) | 2002-10-23 | 2017-11-07 | Modiv Media, Inc | System and method of a media delivery services platform for targeting consumers in real time |
WO2005024743A1 (en) * | 2003-09-05 | 2005-03-17 | International Business Machines Corporation | Granting access to a system based on the use of a card having stored user data thereon |
US7337956B2 (en) * | 2004-04-12 | 2008-03-04 | Rearden Capital Corporation | System and method for facilitating the purchase of goods and services |
US7748617B2 (en) * | 2004-04-12 | 2010-07-06 | Gray R O'neal | Electronic identification system |
US7275685B2 (en) * | 2004-04-12 | 2007-10-02 | Rearden Capital Corporation | Method for electronic payment |
US7324976B2 (en) * | 2004-07-19 | 2008-01-29 | Amazon Technologies, Inc. | Automatic authorization of programmatic transactions |
WO2008005011A1 (en) * | 2006-07-03 | 2008-01-10 | First Data Corporation | System and method for authorizing electronic payment transactions |
US20080126258A1 (en) * | 2006-11-27 | 2008-05-29 | Qualcomm Incorporated | Authentication of e-commerce transactions using a wireless telecommunications device |
US9172493B2 (en) * | 2006-12-18 | 2015-10-27 | International Business Machines Corporation | Caller-identity based security |
US7835988B2 (en) | 2007-06-05 | 2010-11-16 | Mastercard International, Inc. | Methods and apparatus for preventing fraud in payment processing transactions |
WO2009156200A1 (en) * | 2008-06-24 | 2009-12-30 | International Business Machines Corporation | Method and system for authenticating an electronic payment request |
US9195981B2 (en) * | 2008-10-23 | 2015-11-24 | Ims Health Incorporated | System and method for authorizing transactions via mobile devices |
US20100131397A1 (en) * | 2008-11-25 | 2010-05-27 | Patrick Killian | Providing "on behalf of" services for mobile telephone access to payment card account |
US8559923B2 (en) | 2009-05-18 | 2013-10-15 | Mastercard International Incorporated | Switching functions for mobile payments system |
US8688545B1 (en) * | 2011-03-24 | 2014-04-01 | Amazon Technologies, Inc. | Fail-safe ordering |
US10410187B2 (en) * | 2013-09-25 | 2019-09-10 | Patientpay, Inc. | Managing installment payments in a healthcare system |
JP6170844B2 (en) * | 2014-02-14 | 2017-07-26 | 株式会社Nttドコモ | Authentication information management system |
FR3024259A1 (en) * | 2014-07-28 | 2016-01-29 | Christophe Lassus | SYSTEM AND METHOD FOR PAYING MOBILE TELEPHONE INVOICE |
SG10201507849QA (en) * | 2015-09-21 | 2017-04-27 | Mastercard International Inc | A Method And System For Determining A Preference Of A Customer From An Aggregated Participation Level In Payment Card Campaigns |
SG10201609190TA (en) * | 2016-11-02 | 2018-06-28 | Mastercard International Inc | Method and device for making a payment transaction |
JP6666317B2 (en) * | 2017-09-25 | 2020-03-13 | 東芝テック株式会社 | Payment system and user management device |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577109A (en) * | 1994-06-06 | 1996-11-19 | Call Processing, Inc. | Pre-paid card system and method |
EP0745961A2 (en) * | 1995-05-31 | 1996-12-04 | AT&T IPM Corp. | Transaction authorization and alert system |
US5770843A (en) * | 1996-07-02 | 1998-06-23 | Ncr Corporation | Access card for multiple accounts |
US5914472A (en) * | 1997-09-23 | 1999-06-22 | At&T Corp | Credit card spending authorization control system |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5334823A (en) * | 1992-01-10 | 1994-08-02 | National Bancard Corporation | Systems and methods for operating data card terminals for transaction chargeback protection |
US5255182A (en) * | 1992-01-31 | 1993-10-19 | Visa International Service Association | Payment card point-of-sale service quality monitoring system, apparatus, and method |
US5815657A (en) * | 1996-04-26 | 1998-09-29 | Verifone, Inc. | System, method and article of manufacture for network electronic authorization utilizing an authorization instrument |
US6424706B1 (en) * | 1999-03-31 | 2002-07-23 | Imagine Networks, Llc | Method and system for transferring telecommunication-time units among accounts and exchanging same for goods or services |
US6227447B1 (en) * | 1999-05-10 | 2001-05-08 | First Usa Bank, Na | Cardless payment system |
-
2001
- 2001-02-22 WO PCT/SG2001/000047 patent/WO2001065501A1/en active Application Filing
- 2001-02-22 AU AU45009/01A patent/AU4500901A/en not_active Abandoned
- 2001-02-22 US US10/204,423 patent/US20030120592A1/en not_active Abandoned
- 2001-02-22 CN CN01805361.0A patent/CN1418355A/en active Pending
- 2001-02-22 EP EP01918143A patent/EP1269430A1/en not_active Withdrawn
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577109A (en) * | 1994-06-06 | 1996-11-19 | Call Processing, Inc. | Pre-paid card system and method |
EP0745961A2 (en) * | 1995-05-31 | 1996-12-04 | AT&T IPM Corp. | Transaction authorization and alert system |
US5770843A (en) * | 1996-07-02 | 1998-06-23 | Ncr Corporation | Access card for multiple accounts |
US5914472A (en) * | 1997-09-23 | 1999-06-22 | At&T Corp | Credit card spending authorization control system |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005055162A1 (en) * | 2003-11-26 | 2005-06-16 | Splat Thief, Incorporated | User self-authentication system and method for remote credit card verification |
EP1704530A2 (en) * | 2003-12-18 | 2006-09-27 | Safe-In Ltd. | System for the secure identification of the initiator of a transaction |
EP1704530A4 (en) * | 2003-12-18 | 2007-10-24 | Safe In Ltd | System for the secure identification of the initiator of a transaction |
EP2015242A1 (en) * | 2007-06-26 | 2009-01-14 | Alcatel Lucent | Method and system for securing online transactions |
Also Published As
Publication number | Publication date |
---|---|
EP1269430A1 (en) | 2003-01-02 |
CN1418355A (en) | 2003-05-14 |
AU4500901A (en) | 2001-09-12 |
US20030120592A1 (en) | 2003-06-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20030120592A1 (en) | Method of performing a transaction | |
US10467621B2 (en) | Secure authentication and payment system | |
US7742984B2 (en) | Secure authentication and payment system | |
AU2002315501A1 (en) | Secure authentication and payment system | |
US20060173776A1 (en) | A Method of Authentication | |
US20020181710A1 (en) | Mobile transaction system and method | |
JP2001512872A (en) | How to Retail on a Wide Area Network | |
EP1279149A2 (en) | Secure payment method and apparatus | |
NO313980B1 (en) | Mobile e-commerce process and module | |
EP1461897A1 (en) | System and method for facilitating electronic financial transactions using a mobile telecommunication device | |
EP1504320A2 (en) | Method and system for enabling electronic transactions via a personal device | |
WO2003047208A1 (en) | Credit card payment by mobile phone | |
WO2004049621A1 (en) | Authentication and identification system and transactions using such an authentication and identification system | |
JP2011044151A (en) | Method and system for safe payment by portable terminal | |
WO2001041093A1 (en) | A system and method for conducting a financial transaction | |
KR100592156B1 (en) | Method and system for servicing debit commerce by using mobile communication network | |
WO2001095546A2 (en) | A method for wireless telephony payment and an apparatus therefor | |
KR20020074534A (en) | Method for performing credit card settlement through the mobile phone terminal | |
AU2002349173B2 (en) | System and method for facilitating electronic financial transactions using a mobile telecommunication device | |
ZA200205258B (en) | A system and method for conducting a financial transaction. |
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 CR CU CZ DE DK DM DZ 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 PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA 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 ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 018053610 Country of ref document: CN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10204423 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2001918143 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2001918143 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
NENP | Non-entry into the national phase |
Ref country code: JP |