EP1490846A2 - Systeme et procede permettant de realiser des transactions securisees de cartes de credit et de debit - Google Patents

Systeme et procede permettant de realiser des transactions securisees de cartes de credit et de debit

Info

Publication number
EP1490846A2
EP1490846A2 EP03715081A EP03715081A EP1490846A2 EP 1490846 A2 EP1490846 A2 EP 1490846A2 EP 03715081 A EP03715081 A EP 03715081A EP 03715081 A EP03715081 A EP 03715081A EP 1490846 A2 EP1490846 A2 EP 1490846A2
Authority
EP
European Patent Office
Prior art keywords
host computer
customer
response code
merchant
card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03715081A
Other languages
German (de)
English (en)
Inventor
Winston Donald Keech
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Swivel Secure Ltd
Original Assignee
Swivel Secure 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
Priority claimed from GB0207705A external-priority patent/GB2387253B/en
Application filed by Swivel Secure Ltd filed Critical Swivel Secure Ltd
Publication of EP1490846A2 publication Critical patent/EP1490846A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system

Definitions

  • the present invention relates to a system and method for improving security in relation to credit and debit card transactions and the like.
  • Card fraud Credit and debit card fraud (hereinafter referred to together as "card fraud”) is a growing problem, especially in on-line (“e-commerce”) transactions.
  • the banking industry has responded to this with a short-term solution to combat fraud until more sophisticated approaches can be developed.
  • This short-term solution is known as "CW2" approach, and is relatively simple.
  • the CVN2 code is a three digit decimal number, generally printed on the back of a credit or debit card by the card issuer, which is separate from the card number (“PAN” or “payer account number”) and not electronically coded onto the card by way of its magnetic strip or embedded chip (this helps to prevent the CNV2 code from being “skimmed” by a fraudster).
  • the CNN2 code is printed on the card but not readable from the magnetic stripe.
  • Verification is achieved by obtaining the card number from an online source and then checking it to see if the CNV2 code supplied is correct.
  • a merchant conducting a non-cardholder- present transaction e.g. an on-line or telephone transaction
  • the merchant then makes an on-line check to verify that the CNN2 code and the given cardholder delivery address correspond with the details held by the card issuer in connection with the card associated with the given PAN.
  • a person attempting to make a fraudulent transaction requires the PAN, the cardholder address, the card expiry date and the CW2 code, and the CW2 approach therefore assumes that a fraudster will not initially know how to steal this information.
  • the drawback is that the CW2 approach is relatively easily overcome, since many techniques for stealing a PAN may be trivially extended to steal the CNN2 code and the cardholder address.
  • CNN2 is a temporary measure to slow down the growth in fraud.
  • the infrastructure needed to support the CNN2 approach is already installed and in operation. This means that merchants' equipment (e.g. EPOS and EFTPOS terminals and the like) and computer (“IT") systems are already designed and adapted to request a three digit decimal number as an additional security measure.
  • Embodiments of the present invention are adapted to make use of this existing infrastructure to provide a level of anti-fraud security that is higher even than the new smartcard-based approaches.
  • the method and system involves transmission of a pseudo-random string to a person's mobile telephone or the like prior to making a card transaction.
  • the person then applies a mask code in the form of a personal identification number ("PIN") to the pseudorandom string in a predetermined manner so as to generate a volatile one-time transaction identification code that is passed to -the merchant and then on to an authentication server where it is checked against an independently calculated volatile one-time identification code so as to verify the identity of the cardholder.
  • PIN personal identification number
  • a method of authorising secure transactions between a customer and a merchant comprising the steps of:
  • a secure transaction system for authorising transactions made between a customer and a merchant, the system comprising a host computer and at least one customer-operated electronic device, wherein:
  • customer information including a customer account number and an associated personal identification number (PIN) is stored on the host computer;
  • the host computer generates a pseudorandom security string and transmits the pseudorandom security string to the at least one customer-operated electronic device;
  • the electronic device receives an input from the customer comprising the PIN and a transaction amount when the customer conducts a transaction with the merchant;
  • the electronic device generates a response code by applying a predetermined cryptographic algorithm to the pseudorandom security string, the PIN and the transaction amount;
  • the host computer uses the customer account number to retrieve the PIN and the pseudorandom string, and then applies the predetermined cryptographic algorithm to the pseudorandom string, the PIN and the transaction amount so as to generate a check code;
  • the host computer compares the check code and the response code and, if they match, authorises the transaction.
  • the response code generated by the electronic device is preferably displayed on a display of the electronic device and is transmitted verbally or otherwise to a merchant with whom the customer is conducting a transaction.
  • the response code may be transmitted directly from the electronic device operated by the customer to an electronic device (e.g. an EPOS or EFTPOS terminal) operated by the merchant by any convenient technique (e.g. Bluetooth® or other standard communications techniques, typically using modulated electromagnetic radiation signals).
  • an electronic device e.g. an EPOS or EFTPOS terminal
  • the response code may be entered in an appropriate field of the website for transmission to the merchant.
  • the response code, the transaction amount and the customer account number will generally be transmitted for authorisation to the host computer by the merchant rather than the customer, possibly by way of an EPOS or EFTPOS terminal or by way of any suitable computer device.
  • the electronic device is preferably a mobile telephone, personal digital assistant (PDA), a pager or a similar electronic communications device.
  • the pseudorandom security string may be transmitted from the host computer to the electronic device by way of the short messaging service (SMS) protocol, or by any other appropriate communications protocol, including voice messaging, e-mail or other means.
  • SMS short messaging service
  • a customer is first assigned and issued with a credit or debit card in the usual way.
  • the card is printed with an account number unique to the customer.
  • the customer registers the card with an authentication centre which maintains the host computer, and registers the card number, a communications address for the customer's electronic device (e.g. the customer's mobile telephone or PDA number, e-mail address or the like) and a PIN.
  • the PIN may be selected by the customer or assigned to him or her by the host computer, but is not divulged to third parties.
  • the PIN will generally be a decimal number, often four digits in length, but may be of other lengths and may possibly be an alphanumeric string.
  • the customer account number, communications address and PIN are stored in the host computer in association with each other. Once this has been done, the host computer transmits a pseudorandom security string to the customer's electronic device, for example by sending the pseudorandom security string to the customer's mobile telephone by way of the SMS protocol.
  • the pseudorandom security string may be an n digit randomly generated decimal number, or may be an alphanumeric string or the like.
  • the system and method of the present invention may be used in an e-commerce scenario or in a more traditional shopping scenario.
  • a customer makes a selection of goods and/or services from a merchant website in the usual manner.
  • the customer enters or otherwise provides his or her card number (customer account number) and determines a total amount to be paid.
  • the customer then enters the total amount to be paid, together with his or her PIN, into the electronic device, and these are then hashed with the pseudorandom security string by the predetermined cryptographic algorithm or hashed with the One Time Code extracted from the pseudorandom security string by the predetermined cryptographic algorithm so as to generate the response code.
  • the response code is a three digit decimal number of the same format as existing CNN2-type codes printed on the back of known credit or debit cards.
  • the response code may be of arbitrary length and may be non-decimal or an alphanumeric string, depending on the nature of the cryptographic algorithm used.
  • suitable algorithms that can perform a hashing function on the three inputs so as to generate an appropriate response code, as will be apparent to those of ordinary skill in the art, and the . resent application is therefore not concerned with the specifics of such algorithms.
  • the standard well-known SHA-1 cryptographic hash [FIPS PUB 180-1] algorithm may be used to produce a 160-bit value, the remainder then being determined when dividing this by 1000.
  • the cryptographic algorithm may be stored on the telephone's SIM ("Subscriber Interface Module") card or possibly in a separate memory device forming part of the mobile telephone.
  • the cryptographic algorithm preferably runs as an applet in the SIM card, taking the pseudorandom security string received by the telephone as one input, the total amount to be paid as a second input and the PIN as a third input.
  • the second and third inputs may be made manually by way of a keypad provided on the mobile telephone in the usual manner.
  • the cryptographic algorithm may run on any appropriate electronic device (e.g. a PDA, pager, personal computer etc.) in a similar manner, using standard memory and processing devices.
  • the response code After the response code has been calculated by the algorithm, it may be displayed on a display of the electronic device.
  • the customer may then enter the response code in an appropriate data entry field of the merchant website (this may be a data field currently adapted for entry of a standard CNN2 code), and then take the appropriate action to cause the customer account number, the transaction amount and the response code to be transmitted to the merchant in the usual manner by way of a webserver operated by the merchant. Additional security information, such as a card expiry date and a customer address may also be provided.
  • the merchant can then obtain authorisation for the transaction from the card issuer in the usual way, by passing on the customer account number, the transaction amount, the response code and any other security information to a verification server operated by the card issuer.
  • the verification server can determine from the customer account number that the card in question has been registered with the host computer forming part of the present invention, and can then contact the host computer to pass on the customer account number, transaction amount and response code.
  • the host computer upon receiving this information, then uses the customer account number to retrieve the pseudorandom security code initially issued to the customer's electronic device, and also the customer's PIN, since both of these are stored in the host computer. It is then a simple matter for the host computer to run the same predetermined cryptographic algorithm as used in the electronic device, operating on the pseudorandom security string, the transaction amount and the customer's PIN so as to generate the check code. The host computer then compares the check code with the received response code to see if they match and, if they do, then contacts the card issuer's verification server to report that the transaction is authorised. The card issuer can then debit the customer's card and credit the merchant's account in the usual manner.
  • the transaction is not authorised, and the card issuer's verification server can then deny the transaction. If more than a predetermined number (for example, three) transaction attempts initiated in relation to a particular customer account number fail the authorisation procedure, then the customer account number may be blocked by the host computer and, optionally, the card issuer's verification server, since repeated authorisation failure is an indication that the card has been stolen and is being used by an unauthorised person without knowledge of the customer's PIN or the pseudorandom security string. The customer account number may be unblocked only upon further communication between the customer/cardholder, the card issuer and/or the authentication centre, which may result in the customer being issued with a new card with a new account number.
  • a predetermined number for example, three
  • the host computer If the transaction is authorised by the host computer, the host computer then generates a new pseudorandom security string and transmits this to the customer's electronic device as before. The customer may then make a further transaction, with the same or a different merchant, in the same manner. However, because the pseudorandom security string is different for each transaction, it is very difficult for a fraudster or hacker to make use of any intercepted communications to try to break the system.
  • the new pseudorandom security string may be transmitted as part of a message including further information, such as details of the most recent transaction, an account balance, remaining credit limit and the like.
  • the present invention operates in a very similar manner when used in a traditional transaction scenario, for example where a customer makes a purchase in a shop or store, or makes a transaction by telephone.
  • the transaction instead of interfacing with the merchant by way of a website, the transaction is conducted face-to-face or over the telephone.
  • a customer wishes to make a purchase, he or she asks the merchant for the total transaction amount, enters this into the electronic device together with the PIN, and then passes the computed response code to the merchant.
  • the customer also passes the customer account number and optional security details (e.g. card expiry date) to the merchant, generally by way of handing over the credit or debit card to the merchant for passing through an electronic card reader such as an EPOS or EFTPOS machine.
  • the computed response code may be given to the merchant verbally, or may be transmitted electronically from the electronic device directly to the EPOS or EFTPOS machine, for example.
  • the merchant then uses the EPOS or EFTPOS machine or the like to transmit the customer account number, the transaction amount and the response code to the verification server operated by the card issuer in the usual manner, and the verification and authorisation process proceeds as before.
  • the system and method of the present invention may still be implemented in a convenient manner. It is well known that card authorisations may be made by a merchant by way of telephoning a verification centre and verbally passing over details of a customer account number and transaction amount. Accordingly, it is easy for the merchant to do this as usual, also providing the response code handed over by the customer. Authorisation and verification can then proceed as before.
  • This attack on security involves a criminal obtaining a credit card (customer account) number (perhaps by hacking a merchant's website or by picking up a discarded transaction receipt bearing the number) and then attempting to run a fraudulent transaction.
  • This attack has a low chance of success in the present invention since the criminal has to guess a valid response code (for example, there is a 1:1000 chance of guessing a three digit decimal response code successfully).
  • the host computer blocks the card (possibly informing the cardholder via an SMS message or the like) and notifies the card issuer. The card issuer can then enter into a dialog with the cardholder to unblock the card.
  • This attack involves a criminal obtaining the credit card number and a valid response code.
  • the criminal might be a waiter in a restaurant (or a subverted web site) and gain access to the customer's card number and response code.
  • the criminal waiter can run a fraudulent transaction for the same value that the customer has authorised, but the genuine transaction cannot succeed. This means that the criminal waiter can run a single fraudulent transaction for goods that total exactly the same value as the restaurant meal, but that the restaurant transaction will fail. This fraud is easily detected (the restaurant owner will soon notice the missing money) and hence is an unlikely scenario.
  • This attack involves a criminal obtaining the credit card number and then calculating a valid response code.
  • the criminal needs to know both the PIN and the current pseudorandom security string.
  • the approach to inferring the PIN relies on obtaining a number of response codes, perhaps by subverting a web site frequented by the targeted cardholder.
  • to infer the PIN requires knowledge of the security string (the string is in effect a one-time pad which consists of a block of random numbers in a tear-off pad, a sheet then being torn off for each message, this being an encryption technique known to be wholly secure).
  • the criminal needs to attack the encryption on the GSM network, to attack the host computer directly, or to attack the link between the host computer and an associated SMS message centre (SMC) of a mobile network operator.
  • SMC SMS message centre
  • the criminal needs to be able to attack a secure infrastructure at the same time as intercepting transactions (in face-to-face or e-commerce situations). This form of attack is therefore extremely unlikely to be successful or worthwhile.
  • Embodiments of the present invention provide a secure method and system for verifying credit and debit card transactions, with some or all of the following advantages:
  • the transaction value is secured. This means that a merchant cannot run unauthorised transactions or add hidden charges to a transaction. • The cardholder is informed of each transaction automatically by SMS message or the like. • The cardholder does require a mobile phone or equivalent elecfronic device. However, there is no need for a special mobile phone or device. The cardholder does require the SIM card in the telephone to be programmed with an applet including the predetermined cryptographic algorithm. Some mobile telephone operators are able to install appropriate applets using "over the air" (“OTA”) programming into existing SIMs. Applets suitable for use with the present invention can be very simple and hence need not use much space in the SIM card.
  • OTA over the air
  • the SIM card in the mobile telephone does not require cardholder-specific PINs, keys or certificates to be stored.
  • setting up a cardholder requires no SIM programming (other than ensuring the aforementioned applet is installed in the SIM).
  • the process of re-issuing a card does not require alteration of the SIM card.
  • some embodiments of the present invention require that a new pseudorandom security string is used for each fransaction (in effect, the security string is a one-time pad, as previously defined.
  • the pseudorandom security string can be delivered via an SMS message or the like after each transaction.
  • it is inconvenient for the cardholder to have to wait for a new SMS message or the like in order to make the next fransaction for example, the cardholder may be in a shop that has no mobile telephone coverage yet wants to make more than one fransaction.
  • embodiments of the present invention may be adapted to allow multiple transactions.
  • a single transmission (e.g. an SMS message) is made from the host computer to the electronic device including a set of m pseudorandom security strings (where m is an integer, for example 12).
  • the applet consumes the strings one by one for each fransaction processed.
  • the cardholder may need to select a 'confirm' menu item (as opposed to the previously described embodiments of the invention in which the confirmation is implicitly selected by the reception of a new SMS message or the like with a single security string).
  • n being less than the total number of security strings m initially transmitted to the elecfronic device; for example, n may be 6)
  • a new message is sent from the host computer to the elecfronic device that contains a further set of security strings.
  • This approach allows the cardholder to make up to m purchases without needing to receive any transmissions from the host computer, which is useful when, for example, there is no mobile telephone network coverage or the like.
  • a simple message can be sent from the host computer to the cardholder's electronic device to act as a confirmation and mini-statement (indicating the merchant, transaction amount, current balance and remaining credit).
  • the host computer When (or if) the first merchant does come to process the fransaction, the host computer is very likely to be able to determine whether to accept or reject the transaction. There will have been between n and m security strings outstanding (i.e. strings that have not yet been used to validate fransactions) when the re-set was triggered. The host computer has a record of these security strings and the transaction from the first merchant can be run against the oldest of the outstanding security strings to see if there is a match. There are two possibilities for a match failing: (i) the transaction has failed (it is fraudulent, or the cardholder has made a mistake, or the merchant has made a mistake), or (ii) there is more than one transaction that has not been processed immediately. In case (ii) the host computer can attempt to run the transaction against a different security string. Of course, the transaction can simply be rejected on the basis that the merchant has failed to follow the correct procedures.
  • n and m security strings outstanding i.e. strings that have not yet been used to validate fran
  • Adopting the present invention changes the security status of the information being processed in a fransaction (for example, knowing the card number and the response code is insufficient for making a fraudulent transaction). This means that alternative methods of supplying the required fransactional information (card or customer account number, response code, transaction amount, etc.) to the host computer can be used.
  • a mobile telephone or PDA or the like provides an excellent means by which a merchant may access the processing system.
  • a fransaction can be described in an SMS message or the like (using a pre-defined format) and sent to a telephone number set up by an appropriate acquiring network.
  • the acquiring network receiving the message extracts the fransactional information (inferring the merchant identity from the source telephone number of the mobile telephone or the like) and then processes the transaction in the normal way (checking credit limits, accessing the host computer, and so on).
  • the acceptance or rejection of the transaction is sent back to the merchant via an SMS message or the like to the original mobile telephone or the like.
  • This approach provides a low-cost way for a merchant to be part of the card processing network, and is particularly useful for small businesses with little capital to invest. It also allows cards to be processed in areas where obtaining fixed-line infrastructure would be difficult (for example in a taxi).
  • FIGURE 1 shows a schematic outline of the infrastructure of an embodiment of the present invention.
  • FIG. 1 there is shown a host computer 10 which acts as an authorisation server.
  • a host computer 10 which acts as an authorisation server.
  • the customer When a card is issued to a customer by a card issuer, the customer must first register the card with the host computer 10, giving details of a customer account number (card number), a PIN, a mobile telephone number or the like and any other useful information, such as a customer name and address.
  • the host computer 10 generates at least one pseudorandom security string and transmits this via step 1 to a mobile communications device 11 operated by the customer, which device 11 may be a mobile telephone, PDA, pager or the like.
  • the transmission 1 may be by way of an SMS message, e-mail or the like.
  • the host computer 10 associates the at least one pseudorandom security string in its memory with the customer account number and the PEN.
  • the customer When the customer wishes to make a transaction with a merchant 13, the customer enters a transaction amount and the PEN into the mobile communications device 11 by way of a keypad or the like.
  • An applet running in a SIM card or the like provided in the device 11 and programmed with a one-way cryptographic hashing algorithm 12 takes the user-input transaction amount and PEST, together with the pseudorandom security string supplied via step 2, and hashes these together so as to generate a 3 digit response code that is passed to the merchant 13 by way of step 3.
  • the response code may be given to the merchant 13 verbally in a face-to-face or telephone transaction, or by way of a merchant website when conducting an e-commerce fransaction.
  • the merchant 13 takes the customer account number and the transaction amount, possibly by way of swiping the card through an EPOS or EFTPOS terminal, or by any other appropriate means, and then passes this information, together with the response code, to a Card Acquirer Network Server (CANS) 14 in a known manner by way of step 4.
  • the merchant 13 also transmits merchant identity information to the CANS 14 by way of step 4, thereby enabling the CANS 14 to associate the transaction with the merchant 13 as well as with the customer (by way of the customer account number).
  • the CANS 14 passes the customer account number, transaction amount and response code to the host computer 10 in a known manner by way of step 5.
  • the host computer 10 uses the customer account number received from the CANS 14 to retrieve the customer PIN and the pseudorandom security string (originally transmitted at step 1 to the mobile communications device 11) from its memory, and then inputs the pseudorandom security string, the customer PEN and the transaction amount into the same one-way cryptographic hashing algorithm 12 as that running in the applet in the mobile communications device 11, except that this time the algorithm 12 is running in the host computer 10.
  • the algorithm outputs a 3 digit check code which will match the supplied response code when the fransaction is valid, since the algorithm 12 running in the host computer 10 will have operated on the same inputs as the algorithm 12 running in the applet in the mobile device 11. Accordingly, if the supplied response code and the calculated check code are found by the host computer 10 to match, the fransaction is authorised, and an authorisation signal is then sent from the host computer 10 to the CANS 14 by way of step 6.
  • the fransaction will be rejected by the host computer 10 and a rejection signal is sent to the CANS ' 14 by way of step 6.
  • the CANS 14 receives an authorisation signal from the host computer 10, the customer's card account is debited in the usual manner with the transaction amount, the debited fransaction amount being associated with the identity of the merchant 13.
  • the CANS 14 credits a merchant account with the amount of the fransaction in the normal manner.
  • the CANS 14 also passes an authorisation signal to the merchant 13 by way of step 7, and the merchant then notifies the customer by way of step 8 that the fransaction has been authorised.
  • the host computer 10 has authorised the fransaction, it transmits a new pseudorandom security string to the customer's mobile communications device 11 by way of step 1 , together with optional information confirming authorisation of the fransaction, the transaction amount and a card account balance.
  • the CANS 14 passes a rejection signal to the merchant 13 by way of step 7 without debiting the customer's card account or crediting the merchant's account.
  • the merchant 13 can refuse the fransaction, or request a further response code from the customer.
  • the host computer 10 can block the customer's account and issue a signal to that effect to the CANS 14, thus preventing further use of the card until the customer has liaised with an authentication centre operating the host computer 10. It may have been that the customer's card was stolen and is being used fraudulently by a third party without knowledge of the PIN or pseudorandom string, and a new card may need to be issued.
  • Alice has decided that she wants to get a card for use with the present invention. She wants to do this for two reasons. Firstly, she wants to make sure that she can shop safely on the Internet (she has read about how easy it is for hackers to break into web sites and steal credit card numbers, names, addresses, telephone numbers, and so on). Secondly, she wants a card and no-one else will give her a card: Alice is 15 years of age and is too young to obtain a credit card. But because a card protected by way of the present invention protects the merchant 13 and the cardholder from each other's potential misbehaviour, several banks are prepared to issue pre-pay protected cards to teenagers.
  • the bank starts processing the request for a card. It checks that the mobile operator uses SIMs programmed with an appropriate applet for use with the present invention. The bank then creates a card for Alice and transmits the card number, Alice's PEN, and her mobile phone number to the host computer 10 operated by the independent authentication centre (the host computer 10 does not need any other information).
  • Alice's card arrives in the post. Alice goes to her Internet bank account to tell the bank that the card arrived. She also transfers €150 on to the card. A few seconds later she gets (step 1) a text message on her phone 11 saying that her card is ready to be used (the message also contains twelve security strings, but she is not necessarily aware of this).
  • She goes shopping on the web, looking to buy a birthday present for her mother. She visits a web site 13 that sells gardening equipment and finds an ideal present: a gold-plated watering can. The cost is €50.00 including postage. She goes to the 'checkout' page and gets out her card to pay. The site asks for the last three digits on the back of her card. On her card, the last three digits are marked '***'. She looks closer and notes that the card includes the words 'use response code for ***'. She remembers reading about this in an information leaflet sent with the card. She gets out her mobile phone 11 and selects 'Card payment' from the menu (this activates the applet), enters (step 2) her PIN and presses the 'OK' key.
  • step 2 She then keys in (step 2) the transaction amount of 50.00 and presses 'OK'.
  • the applet running in the SIM card of the phone 11 then applies the algorithm 12 to the PIN, the transaction amount and the security string (supplied at step 2) so as to generate a 3 digit response code, and the phone 11 then displays 'Response code: 132'.
  • She types '132' (step 3) into the box in the web site 13 where it asks for the three digits.
  • the web site 13 displays 'Processing order...'.
  • the web merchant's server hands over the transaction details (the card number, the amount, Alice's address, and the three digit code it thinks is the CW2 code) to a card processing computer (the web merchant is using a service company to process card transactions).
  • This computer looks at the card number and contacts (step 4) the appropriate Card Acquirer Network Server (CANS) 14. It hands over the same fransaction details.
  • CANS Card Acquirer Network Server
  • the CANS 14 checks that there is sufficient money on the card to make the payment. This check passes (the card account contains €150 and the transaction is for €50.00).
  • the CANS 14 then calls (step 5) the host computer 10 with the card number, the amount and the three digit response code.
  • the host computer 10 uses the card number to look up Alice's PEN and the security string that it issued to Alice's mobile phone 11. It runs the same cryptographic hash algorithm 12 that the applet in the SIM in Alice's mobile phone 11 runs (using the security string and PIN it looked up plus the transaction amount handed over by the CAN server 14).
  • the host computer 10 works out the check code corresponding to the response code that Alice read from the display of her mobile phone: 132.
  • the computed check code and the response code given to the host computer 10 by the CAN server 14 match, and the transaction is therefore deemed valid and authorised.
  • the host computer 10 tells (step 6) the CANS 14 that the security check passes and creates a new security string.
  • the CANS 14 tells the host computer 10 the merchant 13 identity and the current balance on her card.
  • the host computer 10 takes this information and sends it in a text message (step 1) to Alice's mobile phone 11, along with a new security string.
  • the CANS 14 tells the card processing computer that the fransaction has cleared.
  • the card processing computer tells this to the web merchant's server 13.
  • the web server 13 tells Alice that payment has been accepted. A few seconds later Alice gets a text message (step 1) on her mobile phone 11 from the host computer 10.
  • the text message says 'Presents Direct €50.00. Balance €100.00'.
  • step 4 the Card Acquirer Network Server 14 (CANS) used by Alice's bank.
  • the CANS 14 at the other end of the phone call asks the EPOS machine 13 to read the fransaction amount.
  • the clerk keys in 20.55.
  • the CAN server 14 asks for the response code.
  • the clerk asks Alice for the response code, and Alice says to the clerk "451".
  • the clerk then enters the response code into the EPOS machine 13, and the response code is passed to the CANS 14 (step 4).
  • the CANS 14 checks that there is sufficient money on the card to make the payment and then calls (step 5) the host computer 10 with the card number, the amount and the response code.
  • the host computer 10 works out the check code which should match the response code that Alice has read from the display of her mobile phone: 451.
  • the computed check code and the response code given to the host computer 10 by the CAN server 14 are found to match, and the transaction is therefore valid.
  • the host computer tells (step 6) the CANS 14 that the security check passes and creates a new security string.
  • the CANS 14 tells the host computer 10 the merchant identity and the current balance on Alice's card.
  • the host computer 10 takes this information and sends it (step 1) in a text message to Alice's mobile phone 11, along with a new security string.
  • the CANS 14 tells (step 7) the EPOS machine 13 that the transaction has cleared.
  • the EPOS machine 13 displays an 'OK' message to let the clerk know that the transaction has cleared.
  • the clerk hands Alice her card and a bag with her books. Alice leaves the shop and finds that it is raining hard. She decides that she will take a taxi home and crosses the street.
  • she gets a text message (step 1) on her phone 11. It says 'Acme Books €20.55. Balance €79.45'. What she does not see is that the message has also put a new security string into her mobile phone 11 , ready for the next time she uses her card.
  • the taxi driver tells her the fare is €22.50. She tells him to take €25.00 including tip. She hands the driver her card and selects 'Card payment' from the menu on her mobile phone 11 , enters (step 2) her PIN and presses 'OK'. She then keys in (step 2) 25.00 and presses 'OK'.
  • the phone 11 applies the algorithm 12 to the PEN, fransaction amount and a security string and then displays 'Response code: 722'.
  • the taxi driver has started to write a new text message in his mobile phone 13. He keys in Alice's card number and the transaction amount of 25.00. He then asks Alice for her response code and she says "722" (step 3). He types 722 into the message and sends it (step 4) to the CANS 14 mobile number (stored in the address book of his phone 13).
  • the CANS 14 receives the message. It looks up the sender's telephone number and finds that it is registered to the taxi driver (he is a one-man company). The CANS 14 checks that Alice's card account has enough money for the fransaction (it has €79.45 and the transaction amount is €25.00). Then the CANS 14 contacts the host computer 10 and hands over (step 5) the card number, the amount ( €25.00) and the response code (722). The host computer 10 checks that the response code is valid by comparing it with the independently-calculated check code, and indicates success to the CANS 14 (step 6). The CAN server 14 sends (step 7) an SMS message to the taxi driver's phone 13 indicating that the transaction has succeeded and tells the host computer 10 the merchant identity and the new card balance ( €54.45).
  • the taxi driver receives (step 7) a text message from the CANS 14 saying 'Transaction authorised'. He tells Alice the payment is OK (step 8) and she gets out of the taxi. A few seconds later she gets a text message (step 1) on her mobile phone 11 that says 'John's Taxicabs €25.00. Balance €54.45'. Alice goes into her house.
  • Embodiments of the present invention are therefore a major improvement over the existing CNN2 protocol. They provide protection against fraud for all parties. For example, cardholders are protected from errant merchants (or their staff), and merchants are protected against stolen cards or fraudulent cardholders.
  • embodiments of the present invention provide direct benefits to the cardholder: replacing a lost or stolen card is not tiresome, and close scrutiny of card statements is not essential.

Abstract

L'invention concerne un procédé et un système permettant de réaliser des transactions sécurisées de cartes de crédit et de débit entre un client et un commerçant. Le client reçoit une chaîne de caractères de sécurité pseudo-aléatoire d'un ordinateur hôte, cette chaîne de sécurité étant envoyée sur le téléphone mobile du client. Un algorithme cryptographique exploité dans une carte SIM du téléphone mobile exécute un hachage sur la chaîne de sécurité ou le code unique extrait de la chaîne de caractères de sécurité, un PIN client et un montant de transaction, ces derniers étant entrés au moyen d'un clavier du téléphone mobile. Un code de réponse à trois chiffres est généré par l'algorithme, puis envoyé au commerçant. Le commerçant transmet ensuite le code de réponse, le montant de la transaction et un numéro de compte client (numéro de carte) à l'ordinateur hôte, la chaîne de caractères de sécurité pseudo-aléatoire et le PIN étant extraits de la mémoire. L'ordinateur hôte applique ensuite le même algorithme à la chaîne de caractères de sécurité, au PIN et au montant de la transaction de manière à générer un code de vérification, et si ce code correspond au code de réponse transmis par le commerçant, la transaction est alors autorisée. Les modes de réalisation de cette invention utilisent une infrastructure de sécurité CVV2 existante, mais fournissent un degré de sécurité sensiblement supérieur. Ces modes de réalisation peuvent être utilisés pour des transactions ordinaires face à face ou pour des transactions téléphoniques, ainsi que pour des transactions de commerce en ligne (sur le Web) et pour des transactions de commerce mobile (via un téléphone mobile).
EP03715081A 2002-04-03 2003-03-14 Systeme et procede permettant de realiser des transactions securisees de cartes de credit et de debit Withdrawn EP1490846A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB0207705A GB2387253B (en) 2002-04-03 2002-04-03 System and method for secure credit and debit card transactions
GB0207705 2002-04-03
US10/131,489 US20030191945A1 (en) 2002-04-03 2002-04-25 System and method for secure credit and debit card transactions
US131489 2002-04-25
PCT/GB2003/001075 WO2003083793A2 (fr) 2002-04-03 2003-03-14 Systeme et procede permettant de realiser des transactions securisees de cartes de credit et de debit

Publications (1)

Publication Number Publication Date
EP1490846A2 true EP1490846A2 (fr) 2004-12-29

Family

ID=28676501

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03715081A Withdrawn EP1490846A2 (fr) 2002-04-03 2003-03-14 Systeme et procede permettant de realiser des transactions securisees de cartes de credit et de debit

Country Status (11)

Country Link
EP (1) EP1490846A2 (fr)
JP (1) JP2005521961A (fr)
CN (1) CN1672180A (fr)
AU (1) AU2003219276A1 (fr)
BR (1) BR0308965A (fr)
CA (1) CA2505920A1 (fr)
EA (1) EA006395B1 (fr)
MX (1) MXPA04009725A (fr)
NZ (1) NZ535428A (fr)
TW (1) TWI229279B (fr)
WO (1) WO2003083793A2 (fr)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040098315A1 (en) 2002-11-19 2004-05-20 Haynes Leonard Steven Apparatus and method for facilitating the selection of products by buyers and the purchase of the selected products from a supplier
GB2416892B (en) * 2004-07-30 2008-02-27 Robert Kaplan Method and apparatus to enable validating entitlement to VoIP services
CN101523449B (zh) * 2006-09-27 2011-04-13 黄金富 传送码加自定算式等于银行密码的加密传送方法和系统
WO2008121389A2 (fr) * 2007-03-31 2008-10-09 Synccode Llc Système de traitement de transactions bancaires
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
KR101606655B1 (ko) 2007-09-24 2016-03-25 애플 인크. 전자 장치 내의 내장형 인증 시스템들
JP2009130882A (ja) * 2007-11-28 2009-06-11 Oki Electric Ind Co Ltd チェックバリュー確認方法及び装置
US8799069B2 (en) * 2007-12-21 2014-08-05 Yahoo! Inc. Mobile click fraud prevention
US8600120B2 (en) 2008-01-03 2013-12-03 Apple Inc. Personal computing device control using face detection and recognition
GB2457445A (en) * 2008-02-12 2009-08-19 Vidicom Ltd Verifying payment transactions
JP4656458B1 (ja) 2009-11-09 2011-03-23 Ｎｅｃインフロンティア株式会社 ハンディターミナル、及びハンディターミナルによる決済方法
CN102096968A (zh) * 2009-12-09 2011-06-15 中国银联股份有限公司 一种代授权业务中pin正确性验证的方法
US8649766B2 (en) 2009-12-30 2014-02-11 Securenvoy Plc Authentication apparatus
EP2355028B1 (fr) * 2009-12-30 2018-09-05 SecurEnvoy Ltd Appareil d'authentification
CA2704864A1 (fr) 2010-06-07 2010-08-16 S. Bhinder Mundip Methode et systeme permettant de controler l'acces a un compte a valeur monetaire
US9002322B2 (en) 2011-09-29 2015-04-07 Apple Inc. Authentication with secondary approver
US8769624B2 (en) 2011-09-29 2014-07-01 Apple Inc. Access control utilizing indirect authentication
WO2014162294A1 (fr) 2013-04-05 2014-10-09 Visa International Service Association Systèmes, procédés et dispositifs de transaction
US9898642B2 (en) 2013-09-09 2018-02-20 Apple Inc. Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs
CN105849675B (zh) 2013-10-30 2019-09-24 苹果公司 显示相关的用户界面对象
TWI494880B (zh) * 2013-11-14 2015-08-01 Nat Univ Tsing Hua 用以防範塑膠貨幣盜用之方法及塑膠貨幣
CN206193905U (zh) * 2014-05-29 2017-05-24 苹果公司 电子设备
US10482461B2 (en) 2014-05-29 2019-11-19 Apple Inc. User interface for payments
US9967401B2 (en) 2014-05-30 2018-05-08 Apple Inc. User interface for phone call routing among devices
US9336523B2 (en) 2014-07-28 2016-05-10 International Business Machines Corporation Managing a secure transaction
US10339293B2 (en) 2014-08-15 2019-07-02 Apple Inc. Authenticated device used to unlock another device
US10066959B2 (en) 2014-09-02 2018-09-04 Apple Inc. User interactions for a mapping application
US9547419B2 (en) 2014-09-02 2017-01-17 Apple Inc. Reduced size configuration interface
FR3028639B1 (fr) * 2014-11-17 2016-12-23 Oberthur Technologies Procede de securisation d'un jeton de paiement
EP3234932A1 (fr) * 2014-12-19 2017-10-25 Diebold Nixdorf, Incorporated Transactions atm préétablies
US20160224973A1 (en) 2015-02-01 2016-08-04 Apple Inc. User interface for payments
US9574896B2 (en) 2015-02-13 2017-02-21 Apple Inc. Navigation user interface
US10216351B2 (en) 2015-03-08 2019-02-26 Apple Inc. Device configuration user interface
US9940637B2 (en) 2015-06-05 2018-04-10 Apple Inc. User interface for loyalty accounts and private label accounts
US20160358133A1 (en) 2015-06-05 2016-12-08 Apple Inc. User interface for loyalty accounts and private label accounts for a wearable device
GB201522762D0 (en) * 2015-12-23 2016-02-03 Sdc As Data security
DK179186B1 (en) 2016-05-19 2018-01-15 Apple Inc REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION
US10776780B2 (en) * 2016-05-27 2020-09-15 Visa International Service Association Automated reissuance system for prepaid devices
US10621581B2 (en) 2016-06-11 2020-04-14 Apple Inc. User interface for transactions
DK201670622A1 (en) 2016-06-12 2018-02-12 Apple Inc User interfaces for transactions
US20180068313A1 (en) 2016-09-06 2018-03-08 Apple Inc. User interfaces for stored-value accounts
US10860199B2 (en) 2016-09-23 2020-12-08 Apple Inc. Dynamically adjusting touch hysteresis based on contextual data
US10496808B2 (en) 2016-10-25 2019-12-03 Apple Inc. User interface for managing access to credentials for use in an operation
KR102389678B1 (ko) 2017-09-09 2022-04-21 애플 인크. 생체측정 인증의 구현
KR102185854B1 (ko) 2017-09-09 2020-12-02 애플 인크. 생체측정 인증의 구현
US11170085B2 (en) 2018-06-03 2021-11-09 Apple Inc. Implementation of biometric authentication
US11100349B2 (en) 2018-09-28 2021-08-24 Apple Inc. Audio assisted enrollment
US10860096B2 (en) 2018-09-28 2020-12-08 Apple Inc. Device control using gaze information
US11328352B2 (en) 2019-03-24 2022-05-10 Apple Inc. User interfaces for managing an account
US11481094B2 (en) 2019-06-01 2022-10-25 Apple Inc. User interfaces for location-related communications
US11477609B2 (en) 2019-06-01 2022-10-18 Apple Inc. User interfaces for location-related communications
AU2020356269B2 (en) 2019-09-29 2023-04-06 Apple Inc. Account management user interfaces
US11169830B2 (en) 2019-09-29 2021-11-09 Apple Inc. Account management user interfaces
DK202070633A1 (en) 2020-04-10 2021-11-12 Apple Inc User interfaces for enabling an activity
US11816194B2 (en) 2020-06-21 2023-11-14 Apple Inc. User interfaces for managing secure operations
JP7429819B1 (ja) 2023-04-05 2024-02-08 株式会社セブン銀行 取引システム、取引装置、取引方法、およびプログラム
CN116092623B (zh) * 2023-04-12 2023-07-28 四川执象网络有限公司 一种基于基层医学质控的健康数据管理方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020029342A1 (en) * 2000-09-07 2002-03-07 Keech Winston Donald Systems and methods for identity verification for secure transactions

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0691526B2 (ja) * 1985-03-08 1994-11-14 株式会社東芝 通信システム
AU1390395A (en) * 1994-01-14 1995-08-01 Michael Jeremy Kew A computer security system
GB2328310B (en) * 1996-05-15 1999-12-08 Ho Keung Tse Electronic transaction apparatus and method therefor
SE508844C2 (sv) * 1997-02-19 1998-11-09 Postgirot Bank Ab Förfarande för behörighetskontroll med SIM-kort
DE19820422A1 (de) * 1998-05-07 1999-11-11 Giesecke & Devrient Gmbh Verfahren zur Authentisierung einer Chipkarte innerhalb eines Nachrichtenübertragungs-Netzwerks
FI115355B (fi) * 2000-06-22 2005-04-15 Icl Invia Oyj Järjestely suojatun järjestelmän käyttäjän tunnistamiseen ja todentamiseen
US20030055738A1 (en) * 2001-04-04 2003-03-20 Microcell I5 Inc. Method and system for effecting an electronic transaction

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020029342A1 (en) * 2000-09-07 2002-03-07 Keech Winston Donald Systems and methods for identity verification for secure transactions

Also Published As

Publication number Publication date
CA2505920A1 (fr) 2003-10-09
EA006395B1 (ru) 2005-12-29
AU2003219276A1 (en) 2003-10-13
TWI229279B (en) 2005-03-11
CN1672180A (zh) 2005-09-21
WO2003083793A3 (fr) 2003-12-31
WO2003083793A2 (fr) 2003-10-09
MXPA04009725A (es) 2005-07-14
JP2005521961A (ja) 2005-07-21
BR0308965A (pt) 2005-02-01
TW200306483A (en) 2003-11-16
NZ535428A (en) 2006-08-31
EA200401187A1 (ru) 2005-04-28

Similar Documents

Publication Publication Date Title
US20030191945A1 (en) System and method for secure credit and debit card transactions
WO2003083793A2 (fr) Systeme et procede permettant de realiser des transactions securisees de cartes de credit et de debit
US7014107B2 (en) Wireless payment processing system
US7600676B1 (en) Two factor authentications for financial transactions
US8271335B2 (en) Mobile communication terminal and method for electronic money settlement
US6847816B1 (en) Method for making a payment secure
US20020059146A1 (en) Systems and methods for identity verification for secure transactions
US20110251955A1 (en) Enhanced smart card usage
EP1393271A2 (fr) Systemes et procedes d'approbation de transactions de comptes de credit/debit au moyen d'un appareil sans fil
EP2731065A1 (fr) Procédé de traitement d'un paiement et système et dispositif électronique pour la mise en oeuvre de ce procédé
JP2007521556A (ja) クレジット・カードと関連装置により支払命令を許可する方法
WO2002021767A1 (fr) Carte de paiement virtuelle
US20040039709A1 (en) Method of payment
KR20010087564A (ko) 개인 휴대단말기를 이용한 사용자 인증 처리 시스템 및 그방법
KR20080079714A (ko) 이동통신단말기를 이용한 신용카드 결제의 사용자인증시스템 및 그 방법
CN116711267A (zh) 移动用户认证系统和方法
JP4903346B2 (ja) 擬似或いは代理口座番号なしでコンピュータネットワークを越えて安全な支払いを処理するための改善された方法およびシステム
CA2475275C (fr) Systeme de traitement de donnees sans fil pour le paiement par carte de credit
WO2005066907A1 (fr) Systeme et procede de traitement de transactions
WO2008047330A2 (fr) Système et procédé pour des transactions financières
EP1308912A2 (fr) Méthode et dispositif pour créditer des comptes de services prépayés
US20040059675A1 (en) System and method for replacing identification data on a portable transaction device
JP2002074225A (ja) カード決済加盟店端末、カード決済サービスシステム、及びカード決済におけるカード有効性判断方法
NZ544070A (en) Electronic transaction authorisation with authentic terminal verification
NZ523709A (en) Transaction processing system and method of creating stored transaction authorisation information at a remote location

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040927

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

17Q First examination report despatched

Effective date: 20101102

STAA Information on the status of an ep patent application or granted ep patent

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

18D Application deemed to be withdrawn

Effective date: 20170411