Classifications

• • 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
• • 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/20—Point-of-sale [POS] network 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
• • 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
• • 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/403—Solvency checks
• • 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/403—Solvency checks
  • G06Q20/4037—Remote solvency checks
• • 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

• the present invention relates to a secure transaction system and in particular, to a card transaction system in which the card owner's validation is required to complete a card transaction.
• Credit or debit card details may also become available for fraudulent use, for example, from over the counter transactions.
• a receipt and a carbon copy is printed which includes the transaction details and the credit or debit card details. If a third party obtains such a receipt, the card details printed on the receipt are then available for fraudulent use, for example, to make a transaction over the telephone or the Internet .
• Telephone and Internet transactions typically only require basic card details such as the card number and the name on the card and these card details are readily available from a typical receipt.
• card details transmitted to an on-line merchant may be intercepted by a fraudster.
• the stolen card details may then be fraudulently used as described above.
• the card owner may not become aware of such use until he receives his or her next credit card bill or debit card statement, or when the credit or debit card is declined because the credit or debit limit has been exceeded. This may be an inconvenience when the card owner wishes to make a purchase using the credit or debit card and is unable to do so because the card is declined. The card owner then has to identify the fraudulent transactions or request a new credit or debit card.
• an electronic transaction system comprising: a merchant terminal associated with a merchant who provides goods or services to a user and comprising: i) first input means for receiving details of a transaction; ii) second input means for receiving user identification data for a user associated with the transaction; and iii) means for transmitting an authorisation request for the transaction, the request including said transaction data and said user identification data; and a transaction server operable to receive the authorisation request and comprising: i) means for storing, for each user, one or more mobile communications device numbers associated with user identification data; ii) means for using the user identification data in the received authorisation request to retrieve a stored mobile communications device number for the user associated with the transaction; iii) means for transmitting a communication for authorisation of the transaction to the user's mobile communications device using the retrieved mobile communications device number; iv) means for receiving authorisation for the transaction from the user; and v) means for transmitting an authorisation signal for
• FIG. 1 is a block diagram showing the main components of an electronic transaction system embodying the present invention
• Figure 2a is a block diagram showing the main functional elements of an Electronic Point of Sale Terminal shown in Figure 1;
• Figure 2b is a block diagram illustrating the main elements of an authorisation request generated by the Electronic Point of Sale Terminal shown in Figure 2a;
• FIG 3 is a block diagram showing the main functional elements of a Merchant Acquirer Server shown in Figure 1;
• FIG 4 is a block diagram showing the main functional elements of a Mobile Telephone Transaction Card Issuer Server shown in Figure 1;
• Figure 5 which comprises Figures 5a and 5b, illustrates the data structure used to store user account details in the Mobile Telephone Transaction Card Issuer Server shown in Figure 4 ;
• Figure 6 is a block diagram showing the main functional elements of a mobile telephone shown in Figure 1;
• Figure 7 is a block diagram showing the main functional elements of the mobile telephone shown in Figure 6 when configured to perform the instructions of a mobile transaction authentication module;
• Figure 8 which comprises Figures 8a to 8m, is a flow diagram illustrating the main processing steps performed by the components in Figure 1 in processing a transaction;
• Figure 9, which comprises Figures 9a to 9e, illustrates a sequence of display screens of the mobile telephone during the transaction processing illustrated in Figure 8;
• Figure 10 illustrates an Internet enabled computing environment which enables users to set up and manage their mobile transaction user account
• Figure 11 which comprises Figures Ila to llf, illustrates a sequence of screens displayed to the user when setting up their user account in the Mobile Telephone Transaction Card Issuer Server shown in Figure 11.
• the electronic transaction system 1 of the present embodiment comprises an Electronic Point of Sale (EPOS) Terminal 3, a Merchant Acquirer (MA) Server 5, a Mobile Telephone Transaction Card (MTTC) Issuer Server 7 and a Credit Card Issuer Server 9 which communicate electronically with one another.
• EPOS Electronic Point of Sale
• MA Merchant Acquirer
• MTTC Mobile Telephone Transaction Card
• the MTTC Issuer Server 7 also communicates with the user's mobile telephone 19 via mobile telephone network 8.
• the user After the merchant has entered the transaction details for the product into the EPOS terminal 3 , the user provides their Mobile Telephone Transaction Card (MTTC) 11 (which is issued by the MTTC Issuer Server 7) to the merchant.
• the MTTC 11 is not, however, a credit or debit card. It is a "valueless" card in that it cannot be used directly to pay for the goods or services other than through the payment system to be described below.
• the merchant swipes the MTTC 11 through a card reader (not shown) in the EPOS terminal 3 to read the card details 13 (including a card issuer identification number 15 and a user identification number 17) from a magnetic stripe or electronic chip on the card 11.
• the EPOS terminal 3 then sends an authorisation request (including the card details 13 and the transaction details) to the MA Server 5, in the usual way.
• the MA Server 5 uses the card details in the received authorisation request in the usual way to direct the request to the MTTC Issuer Server 7.
• the MTTC Issuer Server 7 uses the card details to retrieve the user's mobile telephone number which it has stored in memory (not shown) .
• the MTTC issuer server 7 then initiates a communication to the user's mobile telephone so that the user can authorise the specific transaction.
• the user's authorisation Once the user's authorisation has been received by the MTTC Issuer Server 7, it generates an authorisation request for a "shadow transaction" (using the original transaction details and real credit card or debit card details that are also stored in the MTTC Issuer Server 7) which it transmits back to the MA Server 5.
• the MA Server 5 processes the received shadow authorisation request just like any other authorisation request and passes the shadow authorisation request to the appropriate card issuer server 9 (defined by the real credit/debit card details) .
• the MA Server 5 returns the appropriate authorisation code back to the MTTC Issuer Server 7 which then authorises the original authorisation request by sending an appropriate authorisation request back to the MA Server 5.
• the MA Server 5 then forwards the authorisation code back to the EPOS terminal 3, which then prints a receipt including the transaction details to complete the authorised transaction.
• FIG 2a shows the functional elements of the Electronic Point of Sale (EPOS) Terminal 3 used in this embodiment .
• the EPOS Terminal 3 includes a controller 31 which carries out processing operations in accordance with instructions stored in a memory 33 and in response to input received from the keypad 35 and the card reader 37.
• the memory 33 also stores merchant details 39 for identifying the EPOS Terminal 3 and the associated merchant .
• the EPOS Terminal 3 also includes a display 41, a printer 43 and a Merchant Acquirer Interface Unit 45 for transmitting data to and receiving data from the MA Server 5.
• the Merchant Acquirer Interface Unit 45 includes an encryption/decryption unit 47 for encrypting transaction authorisation requests which are to be transmitted to the MA Server 5, and for decrypting transaction authorisation status messages received back from the MA Server 5.
• the merchant to initiate a purchase transaction operation, the merchant enters details of the transaction into the EPOS Terminal 3 via the keypad 35, such as the price and quantity of the goods.
• the EPOS Terminal 3 may include other means for entering details about the goods being purchased, for example, using a bar code scanner or a touch screen keyboard (not shown) etc .
• the controller 31 stores the received transaction details 40 (including a calculated total cost of the transaction) in the memory 33 and prompts the merchant via the display 41 to insert the user's Mobile Telephone Transaction Card (MTTC) 11 into the card reader 37.
• the card reader 37 then reads the card details 13 (including the card issuer identification number 15 and a user identification number 17) from the card 11.
• the read card details 13 are then passed to the controller 31, which generates a transaction authorisation request 42, which is shown in more detail in Figure 2b.
• the generated authorisation request 42 includes the entered transaction details 40, the merchant details 39 stored in the memory 33, and the read card details 13 (which include the issuer identification number 15 and the user identification number 17) .
• the controller 31 then passes the generated authorisation request 42 to the Merchant Acquirer Interface Unit 45, which encrypts the authorisation request 42 and transmits the encrypted request to the MA Server 5.
• the EPOS terminal 3 receives a transaction failed or transaction authorised message from the MA Server 5, the message is decrypted by the Merchant Acquirer Interface Unit 45 and passed back to the controller 31 which displays the message to the merchant on the display 41. If the received message is a transaction authorisation message then the controller 31 outputs a receipt for the user on the printer 43.
• the receipt includes the transaction details 40 and the authorisation code received from the MTTC Issuer Server 7.
• the Merchant Acquirer (MA) Server 5 effectively functions as a router which routes authorisation requests received from different merchants to the appropriate card issuer server and then, once authorisation has been given or is declined, returns the appropriate authorisation message back to the appropriate merchant .
• FIG. 3 shows the functional elements of the MA Server 5 used in this embodiment.
• the MA Server 5 includes a controller 51 which carries out processing operations in response to authorisation requests received from the EPOS terminals via the EPOS Terminal Interface Unit 53 or from the card issuer servers via the Card Issuer Interface Unit 55.
• the EPOS Terminal Interface Unit 53 and the Card Issuer Interface Unit 55 also include encryption/decryption units 47 for encrypting authorisation requests to be transmitted and for decrypting received authorisation requests and transaction authorisation or failed messages.
• the MA Server 5 also includes a Card Issuer Look-up Table (LUT) 57 which stores a list of issuer identification numbers 59 of known Card Issuers along with the corresponding Card Issuer details 61.
• LUT Card Issuer Look-up Table
• the MA Server 5 receives transaction authorisation requests from the EPOS Terminal 3 and receives shadow transaction authorisation requests from the MTTC Issuer Server 7.
• the controller 51 stores the received authorisation request 42 together with a unique MA transaction ID 64 in the pending requests data store 63.
• the unique MA transaction ID 64 is also appended to the authorisation request 42 and is used later to identify the stored authorisation request 42 when a subsequent transaction authorisation or failure message is received having the appended MA transaction ID 64.
• the controller 51 also extracts the card issuer identification number 15 from the received card details 13 and locates the card issuer identification number 15 in the Card Issuer LUT 57. The controller 51 then retrieves the corresponding card issuer details
• the authorisation request 42 (with the appended MA transaction ID 64) is then encrypted by the encryption/decryption unit 47 and the encrypted authorisation request is then transmitted to the appropriate Card Issuer Server 7 or 9 identified by the Card Issuer details 61.
• the controller 51 identifies the unique MA transaction ID 64 included in the received message, and then moves the corresponding authorisation request 42 from the pending requests data store 63 to the authorised requests data store 65 or the failed requests data store 67.
• the controller 51 also stores the received authorisation or failed message with the request.
• the controller 51 then sends a corresponding transaction authorisation message or transaction failed message back to the terminal which originally sent the authorisation request 42, which is identified by the merchant details 39 included in the received authorisation request 42.
• FIG 4 shows the functional elements of the Mobile Telephone Transaction Card (MTTC) Issuer Server 7 used in this embodiment.
• the MTTC Issuer Server 7 includes a controller 71 which carries out processing operations in response to i) transaction authorisation requests received from the MA Server 5 via a Merchant Acquirer Interface Unit 73; ii) user authentication received from the mobile telephone 19 via a Mobile Telephone Interface Unit 75; and iii) user account management instructions received via the Internet 78, an Internet Interface Unit 77 and a User Account Management Unit 79.
• the Merchant Acquirer Interface Unit 73 also includes an encryption/decryption unit 47 for encrypting transaction authorisation requests and authentication messages which are transmitted to MA Server 5 and for decrypting the transaction authorisation requests received from the MA Server 5.
• the MTTC Issuer Server 7 also includes a user account details data store 81 comprising a user identification number Look-up Table (User ID LUT) 83, a user details data store 85 and a users transaction history data store 87.
• a user account management unit 79 creates and modifies the account details stored in the user account details data store 81 in response to user input received via the Internet Interface Unit 77.
• Figures 5a and 5b illustrate the data structure used in this embodiment to store the user account details in the user account details data store 81.
• Figure 5a illustrates the data structure used to store user account details in the User ID LUT 83 and the user details data store 85; and
• Figure 5b illustrates the data structure used to store user transaction history details in the user's transaction history data store 87.
• the User ID LUT 83 includes a list of user identification numbers 83-1 for all the users who have created an account with the MTTC Issuer Server 7 and the corresponding user account numbers 83-3.
• Corresponding user account details 85-1 are stored in the user details data store 85 for each user account number 83-3 in the User ID LUT 83.
• the stored user account details 85-1 include the user's name 85-5, the user's billing address 85-7, the user's Personal Identification Number (PIN) 85-9, the user's security password 85-11, the user's credit card details 85-13 and the user's mobile telephone details 85-15.
• a user may have more than one credit card and, as shown, the user details data store 85 stores credit card details 85-C1, ... , 85-Cj for each of the user's credit cards .
• the stored credit card details for each credit card 85-C1 include a credit card description 85-17 provided by the user to identify the particular card (e.g. "my Visa") , the credit card number 85-19, the name that appears on the credit card 85-21, the credit card issue date 85-23, the credit card expiry date 85-25, the credit card issue number (if available) 85-27, the security number 85-29 which is printed on the credit card (if available) and the billing address 85-31 for the credit card 85-C1.
• the user may also include debit card details within the "credit card details" store 85- 13.
• a user may have more than one mobile telephone 19 and the user details data store 85 stores mobile telephone details 85-M1, ... , 85-Mk for each mobile telephone 19 that the user has registered.
• the stored mobile telephone details for each mobile telephone 85-Ml include the mobile telephone number 85-33, the mobile telephone network operator 85-35 and the mobile telephone handset make 85-37 and model 85- 39.
• the users transaction history- data store 87 includes, for each transaction authorisation request 42 received from the MA Server 5: i) a field 87-1 for storing a transaction ID 46 generated by the MTTC issuer server 7; ii) a field 87-3 for storing the received authorisation request 42; iii) a field 87-5 for storing the current request status 48 which can either be pending, failed or authorised; iv) a field 87-7 for storing a shadow authorisation request 50; v) a field 87-9 for storing a shadow request status 52; and vi) a field 87-11 for storing a user authorisation message 54.
• a separate table 87-Ul, ..., 87-Ui of transaction history data is stored for each user to facilitate billing and the handling of user account queries.
• the controller 71 receives the authorisation request 42 which includes the user identification number 17 from the MA Server 5. In response, the controller 71 retrieves the account number 83-3 from the User ID LUT 83 that corresponds to the received user identification number 17. The controller 71 then retrieves the transaction history table 87-Ul corresponding to the user's account number from the users transaction history data store 87 and generates the unique MTTC transaction ID 46 for the current authorisation request 42. The controller 71 then populates the user's transaction history table 87- UI with the authorisation request 42 under the unique MTTC transaction ID 46 and sets the current status 48 for the request 42 to pending.
• the controller 71 After storing the received authorisation request 42, the MTTC transaction ID 46 and the request status 48 in the user transaction history table 87-Ul, the controller 71 retrieves the user account details 85-1 corresponding to the user's account number 83-3 from the user details data store 85. In particular, the controller 71 retrieves the user's mobile telephone details 85-15 and a list of the card descriptions 85- 17 from the user's credit card details 85-13. The controller 71 then passes the retrieved mobile telephone and credit card details together with the transaction details 40 (extracted from the current authorisation request 42) and MTTC transaction ID 46 for the current authorisation request 42, to the Mobile Telephone Interface Unit 75.
• the Mobile Telephone Interface Unit 75 In response, the Mobile Telephone Interface Unit 75 generates a mobile telephone text message suitable for the user's mobile telephone, using a suitable message template chosen from a message template data store 89.
• the interface unit 75 uses the make 85- 37 and model 85-39 details to select an appropriate text message template from the template data store 89.
• the interface unit 75 then populates the template message with the transaction details 40 and the credit card details 85-13 and then sends the message to the user's mobile telephone 19 using the retrieved telephone number.
• the controller 71 then waits for a reply from the user's mobile telephone 19.
• the controller 71 determines if the received message is a transaction authorisation message or a transaction not authorised message from the user. If the message is a transaction not authorised message, then the controller 71 identifies the MTTC transaction ID 46 from the received message and changes the corresponding request status 48 to failed and then transmits a transaction not authorised message to the MA Server 5 via the Merchant Acquirer Interface Unit 73.
• the received mobile telephone message is a user authorisation message
• the received message will also include the user's selection of which credit card to use for the current transaction.
• the controller 71 retrieves the credit card details 85-13 for the selected credit card from the user details data store 85 and the transaction details 40 from the stored authorisation request 42.
• the controller 71 then sends the transaction details 40, the selected credit card details and the corresponding MTTC transaction ID 46 to an Electronic Point of Sale Unit 93 included in the MTTC Issuer Server 7.
• the Electronic Point of Sale (EPOS) Unit 93 then generates a shadow transaction authorisation request 50 including the received transaction details 40, the selected credit card details 85-13 and the MTTC transaction ID 46.
• the EPOS Unit 93 also stores "merchant details" 94 for identifying the MTTC Issuer Server 7 as the merchant, which are also included within the shadow transaction authorisation request 50 so that the shadow transaction reply message will be returned to the MTTC Issuer Server 7.
• the EPOS unit 93 then passes the shadow transaction authorisation request 50 back to the controller 71 which stores the shadow authorisation request 50 in the appropriate field 87-7 of the user transaction history table 87- Ul.
• the controller 71 also sets the corresponding shadow request status 52 to pending.
• the original transaction details and the shadow transaction details are both associated with the same MTTC transaction ID 46 so that the original transaction can be identified when authorisation for the shadow transaction authorisation request 50 has been received.
• the controller 71 then transmits the shadow transaction authorisation request 50 to the MA Server 5 via the Merchant Acquirer Interface Unit 73.
• the controller 71 updates the shadow request status 52 in the user transaction history table 87-Ul and retrieves the corresponding original authorisation request 42. If the shadow transaction fails, then the controller
• the controller 71 sends the transaction details to a Validation and Authorisation Code Generator 91 which generates an authorisation code for the original transaction which it passes back to the controller 71.
• the controller 71 transmits the MTTC authorisation code together with the MA transaction ID to the MA Server 5 via the Merchant Acquirer Interface Unit 73 , which indicates that the transaction has been successfully authorised and processed.
• the controller 71 then updates the request status 48 for the original authorisation request 42 to authorised and also stores the generated authorisation code with the updated status.
• the controller 71 then sends a mobile telephone message to the user's mobile telephone 19 via the mobile telephone Interface Unit 75 to inform the user that the transaction has been successful.
• Mobile Telephone Figure 6 shows the functional elements of the mobile telephone 19 used in this embodiment.
• a microprocessor 101 is arranged to process inputs from a keypad 23 and to control output on a display 21, and also to provide control and processing for the other functional units.
• a working memory 103 is provided for use by the microprocessor 101 and the other functional units .
• Microprocessor 101 is also operable to receive mobile telephone authorisation request messages from and send authorisation messages to the MTTC Issuer Server 7 via a Communications Interface Unit 105.
• the mobile telephone 19 also includes a mobile transaction authentication module 107 and a transaction validation code generator module 109 which store processing instructions used to control the operation of the microprocessor 101 in response to user input from the keypad 23 and mobile telephone authorisation request messages received from the MTTC Issuer Server 7 via the Communications Interface Unit 105.
• FIG. 7 illustrates the functional elements of the mobile telephone 19 when configured to carry out the processing operations in accordance with the instructions stored in the mobile transaction authentication module 17.
• the functional elements include a central controller 111 which is arranged to process inputs from the keypad 23 via a user input receiver 113 , and mobile telephone authorisation request messages received from the Communications Interface Unit 105 via the message decoder 115.
• the message decoder 115 receives the mobile telephone authorisation request messages from the MTTC Issuer Server 7 via the Communications Interface Unit 105 and decodes the message to retrieve the transaction details 40 and the list of credit card descriptions 85-17, which are then stored in a memory 117.
• the controller 111 controls a prompt generator 119 to generate an appropriate user prompt screen which is displayed to the user on the display 21 to prompt the user to authorise the transaction and to choose one of their credit cards to carry out the
• the mobile telephone 19 also includes a message generator 121 which generates, if the transaction is authorised, an authorisation message including the user's authorisation, the transaction details 40 and the user's selected credit card description. On the other hand, if the transaction is not authorised, then the message generator 121 generates a "transaction not authorised" message.
• the mobile telephone 19 also stores message templates in a message template data store 123 which are used by the message generator 121 to generate the appropriate message. The generated message is then transmitted back to the MTTC Issuer Server 7 via the Communications Interface Unit 105.
• FIG 8 which comprises Figures 8a to 8m, there are shown the principal processing steps which are performed to complete a purchase transaction using the secure transaction system of the present embodiment .
• the EPOS Terminal 3 receives the transaction details 40 entered by the merchant for the products that the user wishes to purchase.
• the EPOS terminal 3 prompts the merchant to insert the user's card into the card reader 37, and once inserted reads the user's card number 13 (which includes the issuer identification number 15 and the user identification number 17) .
• the MTTC 11 has a sixteen digit card number 13. The first four digits of the card number 13 is the card issuer identification number 15 which is used by the MA server 5 to identify the MTTC Issuer Server 7, and the remaining twelve digits is the user identification number 17 which is used by the MTTC issuer server 7 to identify the user or card owner.
• the EPOS Terminal 3 sends an authorisation request (which includes the transaction details 40 and the card number 13) to the MA Server 5 via the Merchant Acquirer Interface Unit 45, which receives the authorisation request at step S7.
• the MA Server 5 generates a unique MA transaction ID 64 for the received transaction authorisation request 42 and stores the authorisation request 42 together with the generated MA transaction ID 64 in the pending requests data store 63.
• the MA Server 5 retrieves the card issuer details 61 corresponding to the received issuer ID number 15 from the Card Issuer Look-up Table (LUT) 57 and identifies the location of the card issuer so that the authorisation request 42 can be sent to the corresponding card issuer server.
• the MA Server 5 then sends, in step S13, the authorisation request 42 including the MA transaction ID 64 to the card issuer server identified at step Sll.
• the received card issuer ID number 15 corresponds to the MTTC Issuer and therefore, the MA server 5 sends the request to the MTTC Issuer Server 7.
• the MTTC Issuer Server 7 receives the authorisation request 42 from the MA Server 5.
• the MTTC Issuer Server 7 then retrieves, in step S17, the user's account number 83-3 corresponding to the user ID number 17 in the received authorisation request from the User ID LUT 83.
• the user's transaction history table 87-Ul is located and a unique MTTC transaction ID 46 is generated for the received request 42.
• the generated MTTC transaction ID 46 is also stored in step S19, in the user's transaction history table 87-Ul along with the received authorisation request 42.
• the request status 48 is also updated in step SI9 to record the request's pending status .
• the controller 71 retrieves, in step S21, the user's mobile telephone details 85-15 from the user details data store 85 as well as a list of credit card descriptions 85-17 from the user's credit cards details 85-13 which it passes to the interface unit 75.
• the mobile telephone details 85-15 are received by the mobile telephone Interface Unit 75 at step S8-23 which uses them to generate a mobile telephone message including the transaction details and the list of credit card descriptions.
• the generated message is then sent to the user's mobile telephone 19 at step S25 which is received by the mobile telephone 19 at step
• step S31 After sending the message at step S25, the MTTC Issuer Server 7 proceeds to step S31 which checks if a reply message from the mobile telephone 19 has been received. If no message has been received yet, then the processing proceeds to step S33 where it is determined if a predetermined waiting time has elapsed. If the waiting time has not elapsed, then processing returns to step S8-31. If a reply is not received within the time out period, then the processing proceeds to step S35 where the MTTC Issuer Server 7 determines if the user has another mobile telephone and, if so, retrieves the mobile telephone details 85-15 for the next mobile telephone from the user details data store 85 at step S37. The processing then returns to step S23 so that another message can be sent to the new mobile telephone.
• step S31 This operation continues until a reply message has been received at step S31 or until there are no more mobile telephone numbers registered in the MTTC Issuer Server 7. In this case, none of the user's mobile telephones has been able to receive the mobile telephone messages and processing therefore proceeds from step S35 to step S201 (shown in Figure 8k) where user authorisation is obtained in an "offline" manner, which will be described in more detail later.
• the mobile transaction authentication module 107 is initiated at step S39 and processing instructions are loaded into the working memory 117 to configure the mobile telephone 19 to perform the processing operations to deal with the received message.
• the message is decoded by the message decoder 115 to extract the transaction details 40 and the list of credit card descriptions 85-17, which are then stored in the memory 117.
• the prompt generator 119 then displays the transaction details 40 and prompts the user to confirm them in step S41.
• Figure 9a shows the prompt screen 131 which is generated and displayed at step S41 in this embodiment.
• the prompt screen 131 includes the heading "Authorisation” 133, the transaction details 40 and a prompt to the user to confirm if the user wants to authorise the transaction.
• the transaction details 40 included in the prompt screen 131 displayed to the user include the merchant details 39 (in this case, the merchant's name, "The Curry Centre") and the total cost of the transaction (in this case, £27-50) .
• the generated prompt screen 131 also includes two options for the user to select, in this case, a "Yes” option 139 to proceed with the transaction authorisation procedure, and a "No” option 141 to terminate the transaction authorisation procedure .
• buttons 143 and 145 which correspond to the user selectable options "Yes” 139 and "No” 141. Buttons 143 and 145 form part of the keypad 23 of the mobile telephone 19 and are located, adjacent and below the corresponding displayed option, so that the user is prompted to press the appropriate button to select the corresponding option.
• the keypad 23 also includes four directional buttons: an UP button 147-1, a RIGHT button 147-2, a DOWN button 147-3 and a LEFT button 147-4. In this embodiment, the directional buttons are not used when the present prompt screen 131 is displayed.
• step S42 the mobile telephone 19 waits for the user to press button 143 or 145 in response to the prompt screen 131. As shown, the processing remains at step S42 until the user has pressed a button. When the user has pressed a button the processing proceeds to step S43, where the controller 111 determines if the user pressed button 145 corresponding to the "No" option 141 or button 147 corresponding to the "yes" option.
• step S43 the controller 111 determines that the user has pressed button 145 indicating that the user does not authorise the transaction, then the processing proceeds to step S44 where a "Transaction Not Authorised” message is generated by the message generator 121 (which includes the transaction details 40 and the MTTC transaction ID 46) .
• step S45 the "Transaction Not Authorised” message is sent to the MTTC Issuer Server 7 and the mobile telephone message is received at step S47 and decoded to retrieve the transmitted data.
• the MTTC issuer server 7 extracts the MTTC transaction ID 46 from the received message and the appropriate field 87-5 in the user's transaction history table 87-Ul is updated to indicate that user authorisation has not been given.
• the processing then proceeds to step S51, where a "Transaction Not Authorised” message together with the corresponding MA transaction ID 64 (obtained from the authorisation request 42) are sent back to the MA Server 5 and received at step S53.
• the MA Server 5 retrieves the MA transaction ID 64 from the received message and locates, in step S55, the corresponding authorisation request 42 in the pending requests data store 63.
• the controller 51 then moves, in step S55, the authorisation request from the pending requests data store 63 to the failed requests data store 67 and a "Transaction Not Authorised” message is sent back to the appropriate EPOS Terminal 3 (identified by the merchant details 39 in the authorisation request 42) in step S57.
• the EPOS Terminal 3 receives the "Transaction Not Authorised” message from the MA Server 5 and displays an unsuccessful transaction message to the merchant on display 41 at step S61, to complete the unsuccessful transaction.
• step S43 if on the other hand, the controller 111 determines that the user pressed button
• step S63 the prompt generator 119 generates a second prompt screen which is displayed to the user to prompt the user for his or her PIN number 85-9, as well as two randomly chosen letters from the user's security password 85-11.
• Figure 9b shows the prompt screen 151 generated at step S63 in this embodiment.
• the prompt screen 151 includes the heading "Authenticating" 153 , a prompt "Please enter your PIN:", a text box 157 for the user to enter his or her PIN 85-9 via the keypad 23, prompts for two letters randomly chosen from the user's secret password 85-11 by the prompt generator 119 and two corresponding text boxes 161-1 and 161-2 for the user to enter the appropriate letters via the keypad 23.
• the prompt screen 151 also includes a "Submit” option 163 which allows the user to submit the PIN and password letters after they have been entered and a "Back" option 165 which allows the user to view the previous prompt screen 131 shown in Figure 9a.
• Figure 9b also shows buttons 143 and 145 as well as the directional buttons 147-1 to 147-4 as described above.
• button 143 corresponds to the "Submit” option 163 and button 145 corresponds to the "Back" option 165.
• the UP 147-1 and DOWN 147-3 directional buttons are used to select the input text boxes 157, 161-1 and 161-2 so that the corresponding input can be entered.
• the RIGHT 147-2 and LEFT buttons 147-4 are used to move a cursor (not shown) within the selected text box in order to insert or delete characters at a specific position within the text box.
• step S65 processing waits for the user to enter the PIN and the specified letters from the security password, and to press button 143 corresponding to the "Submit” option 163 or button 145 corresponding to the "back” option. Once button 143 or 145 has been pressed, the processing proceeds to step S67 when the controller 111 determines which button has been pressed. If the user pressed button 145 for the "Back" option 165, then the processing returns to step S41 and the prompt generator 119 re-generates the prompt screen 131 shown in Figure 9a to redisplay the transaction details 40 to the user and re-prompt the user to authorise the transaction details.
• step S69 the prompt generator 119 retrieves, via the controller 111, the list of descriptions of the user's credit cards stored in the memory 117 and generates a prompt screen to display the list of credit cards to the user and prompting the user to select one card to use for the current transaction.
• Figure 9c shows the prompt screen 171 which is generated at step S69 in this embodiment.
• the prompt screen 171 includes a heading "Choose card” 173, a prompt "Choose card for current transaction:” 175, and a list of credit card descriptions 175. Three descriptions are shown in the example prompt screen 171, however the list 175 will include a description for each credit card stored in the user details data store 85 on the MTTC Issuer Server 7.
• the prompt screen 171 also includes a "Select” option 177 and a "Cancel” option 179.
• Figure 9c also shows buttons 143 and 145 as well as the directional buttons 147-1 to 147-4 as described above.
• button 143 corresponds to the "Select” option 177 and button 145 corresponds to the "Cancel” option 179.
• the UP 147-1 and DOWN 147-3 directional buttons are used to select a card description from the list of card descriptions 175 (by moving the rectangular selection window 180) , and the RIGHT 147-3. and LEFT 147-4 directional buttons are not used for this prompt screen 171.
• step S71 the controller 111 waits for the user to make a selection or press the cancel button 145.
• the processing then proceeds to step S8-73, where the controller determines if the user has pressed the Cancel button 145. If he has, then the processing returns to step S44 where the message generator 121 generates a "Transaction Not Authorised” message and processing continues as described above to communicate the "Transaction Not Authorised” message back to the EPOS Terminal 3 via the MTTC Issuer Server 7 and the MA Server 5.
• step S73 the user has selected a card and pressed the Select button 143, then the processing proceeds to step S75, where the prompt generator 119 generates a prompt screen to prompt the user to confirm authorisation for the transaction with the credit card selected at step S71.
• Figure 9d shows the prompt screen 181 generated at step S75 in this embodiment.
• the prompt screen 181 includes a heading "Final summary” 183, a prompt for the user to confirm the transaction details with the selected credit card, and two options "Yes” 187 and “No” 189.
• Figure 9d also shows buttons 143 and 145 corresponding to the options 187 and 189, as well as the directional buttons 147-1 to 147-4 which are not used when prompt screen 181 is displayed.
• step S77 the controller 111 determines if the user has pressed button 143 or 145. If the user has pressed button 145 indicating that confirmation is not given, then the processing returns to step S69 where the prompt screen 171 is displayed again to the user allowing them to select another credit card. On the other hand, if the controller 111 determines at step S77 that the user has pressed button 143 to confirm authorisation of the transaction with the selected credit card, then at step S79, the message generator 121 generates a user authentication message including the PIN and password letters entered by the user and data identifying which letters from the password were chosen, the credit card selected by the user at step S71 and the MTTC transaction ID 46 for the current transaction (which is stored in the memory 117) .
• the MTTC Issuer Server 7 receives the user authentication message from the user's mobile telephone 19, and controller 71 identifies the user's account number 85-3 from the user's mobile telephone number 85-33 which is included in the received message.
• the controller 71 retrieves, in step S83, the user's PIN 85-9 and password 85-11 from the user details data store 85 at step S83 and at step S85 the controller 71 determines if the user entered PIN and the password letters are correct by comparing them to the retrieved PIN and the appropriate letters from the retrieved password (as indicated by the data identifying the letters from the password that were chosen, which is included in the authorisation message received from the mobile telephone 19) .
• step S85 the processing returns to step S49 where the appropriate request status 48 in the user's transaction history table 87-Ul is updated to indicate that the request has failed.
• the processing then continues as described above to communicate the unsuccessful authorisation back to the merchant at the EPOS Terminal 3.
• step S87 the user authorisation message received at step S81 is stored in the appropriate field 87-11 of the user's transaction history table 87-Ul (which is identified using the MTTC transaction ID 46 that is included in the received message) .
• the controller 71 uses the MTTC transaction ID 46 in the received message to retrieve the transaction details 40 from the corresponding authorisation request 42 stored in the user's transaction history table 87-Ul and the account number 85-3, to retrieve the credit card details 85-13 for the user selected credit card from the user details data store 85.
• a shadow authorisation request 50 is then generated, in step S91, by the Electronic Point of Sale (EPOS) Unit 93 which includes the transaction details 40, the retrieved card details 85-13 for the user selected credit card, the MTTC transaction ID 46 and the MTTC merchant details 94 stored in the EPOS Unit 93 (which identify the MTTC Issuer Server 7 as the "merchant" for the shadow transaction) .
• EPOS Electronic Point of Sale
• the generated shadow authorisation request 50 is then stored, in step S93, in the appropriate field 87-7 of the user's transaction history table 87-Ul and the shadow request status 52 is set to "pending".
• the shadow authorisation request 50 is then sent to the MA Server 5 at step S95, and this is received by the MA server 5 at step S97.
• the controller 51 extracts the credit card issuer's ID number from the shadow authorisation request 50 and uses this to retrieve the corresponding credit card issuer details from the card issuer LUT 59.
• the controller 51 then generates a unique MA transaction ID for the shadow authorisation request 50 and stores, in step S101, the shadow authorisation request 50 along with the generated MA transaction ID 64 in the pending requests data store 63.
• the controller 51 sends the shadow authorisation request 50 and the corresponding MA transaction ID 64 to the Credit Card Issuer Server 9 identified by the credit card issuer details retrieved in step S99.
• the shadow authorisation request 50 is received by the Credit Card Issuer Server 9 at step S105 and processed in the usual way in step S107 to determine if the request can be authorised or not .
• this processing step will include, for example, verifying that the selected credit card is valid and that the user has sufficient credit to make the purchase. If, at step S109, the card issuer server 9 determines that the shadow transaction cannot be authorised, for example, if the credit card is not valid or the user does not have sufficient credit to make the purchase, then at step Sill, a card declined message (which includes the MA transaction ID 64) is sent back to the MA Server 5.
• the MA Server 5 receives the card declined message and uses the MA transaction ID 64 to locate the corresponding stored shadow authorisation request 50 in the pending requests data store 63.
• the located shadow authorisation request 50 is then moved to the failed requests data store 67 at step S115, and at step S117, a "Transaction Not Authorised” message together with the MTTC transaction ID 46 (that associates the shadow authorisation request 50 with the real transaction authorisation request 42) is sent back to the MTTC Issuer Server 7.
• the "Transaction Not Authorised” message is received by the controller 71 together with the MTTC transaction ID 46.
• the controller 71 uses the MTTC transaction ID 46, in step S121, to locate and to update the corresponding shadow request status 52 to indicate that the shadow authorisation request 50 has failed.
• the controller 71 retrieves, in step S121, the original authorisation request 42 corresponding to the failed shadow authorisation request 50 and identifies from it the MA transaction ID 64 for the original request 42.
• the controller 71 then sends, in step S123, an authorisation failed message (which includes the MA transaction ID 64) back to the MA Server 5.
• the authorisation failed message is received by the MA Server 5 at step S125 and the processing returns to step S55 (discussed above) , where the associated authorisation request 42 is moved from the pending requests data store 63 to the failed requests data store 67 and the unsuccessful request is communicated to the merchant at the EPOS Terminal 3.
• the controller 51 also causes an authorisation failed message to be sent, in step S127, to the user's mobile telephone 19, and the message is received at step S129 and displayed to the user at step S131 to complete the unsuccessful transaction.
• step S109 the Credit Card Issuer Server 9 determines that the transaction is authorised
• the processing proceeds to step S133 (shown in Figure 8i) , where the card issuer server 9 generates and sends an authorisation code to the MA Server 5 together with the MA transaction ID 64 that was included in the shadow authorisation request 50.
• the card issuer authorisation code is received, at step S135 together with the MA transaction ID 64.
• the controller 51 uses the MA transaction ID 64 to locate and move the corresponding shadow authorisation request 50, in step S137, from the pending requests data store 63 to the authorised requests data store 65.
• the controller 51 then sends, in step S139, the card issuer authorisation code for the shadow transaction 50 (together with the MTTC transaction ID 46 for the shadow transaction) to the MTTC Issuer Server 7.
• the card issuer authorisation code for the shadow authorisation request 50 is received, together with the MTTC transaction ID 46.
• the controller 71 uses the MTTC transaction ID 46 to locate the corresponding shadow transaction authorisation request 50 in the user's transaction history table 87-Ul, to update, in step S147, the shadow request status 52 to authorised (and to include the card issuer's authorisation code) .
• the code generator 91 generates a MTTC transaction authorisation code for the original authorisation request 42 corresponding to the authorised shadow authorisation request 50.
• the controller 71 updates the request status 48 to indicate that it has been authorised and stores with it, in step S1 7, the generated MTTC transaction authorisation code.
• the controller 71 then sends, in step S149, the MTTC transaction authorisation code (together with the MA transaction ID 64 for the original authorisation request 42) to the MA Server 5.
• the Mobile Telephone Interface Unit 75 generates and sends to the user's mobile telephone 19 a transaction success message (including the MTTC authorisation code) .
• the transaction success message is received by the mobile telephone 19 and the message is displayed to the user on the display 21 at step S155.
• FIG. 9e An example of the transaction success message which is displayed to the user at step S155 is shown in Figure 9e.
• the mobile telephone display 191 includes the heading "Finished” 193 and provides an "Options” option 197 (which allows the user to access details of the transaction) and a "Close” option 199 which allows the user to close the displayed message.
• buttons 143 and 145 which correspond to the two user-selectable options 197 and 199, and directional buttons 147-1 to 147-4 which are not used when the transaction success message is displayed.
• the MA Server 5 receives the MTTC transaction authorisation code together with the MA transaction ID 64 from the MTTC Issuer Server 7.
• the controller 51 moves the authorisation request corresponding to the received MA transaction ID 64 from the pending requests data store 63 to the authorised requests data store 87.
• the controller 51 then sends, in step S161, the generated MTTC transaction authorisation code back to the EPOS Terminal 3.
• the EPOS Terminal 3 receives the MTTC transaction authorisation code from the MA Server 5 and displays a transaction successful message to the merchant at step S165.
• the EPOS terminal 3 prints a receipt which includes the MTTC transaction authorisation code and the transaction details 40.
• step S35 the MTTC issuer server 7 assumes that the user's mobile telephone is switched on but not within the coverage of the mobile telephone network, and it proceeds to carry out an "offline" authorisation procedure .
• step S35 the processing proceeds from step S35 to step S201 (shown in Figure 8k) where the authorisation code generator 91 generates an offline authorisation code which is sent, in step S203, by the controller 71 back to the MA Server 5 together with the MA transaction ID 64 and the MTTC transaction ID 46.
• the MA Server 5 receives, in step S205, the offline authorisation code together with the MA and MTTC transaction IDs for the authorisation request 42.
• the controller 51 uses the MA transaction ID 64 to identify the merchant details 39 associated with the authorisation request 42 so that it can forward the offline authorisation code to the appropriate EPOS terminal 3 in step S207.
• the EPOS terminal 3 receives the offline authorisation code (together with the MA and MTTC transaction IDs and displays, in step S211, the offline authorisation code to the merchant on the display 41 together with a prompt for the user to enter a validation code .
• the EPOS terminal 3 then waits, in step S213, for a validation code to be input by the user.
• the validation code is generated by the user's mobile telephone 19 when the user initiates the transaction validation code generator module 109. This process will now be described with reference to Figure 81.
• the user initiates the transaction validation code generator module 109 on the mobile telephone 19 and enters the offline authorisation code
• the validation code generator module 109 then prompts the user, in step S217 to enter their PIN number and selected letters from their secret password (using for example the prompt screen 153 shown in Figure 9b) .
• the validation code generator module 109 generates a validation code using the offline authorisation code received at step S215 and the PIN number and password data entered at step S217, using a predetermined algorithm stored in the transaction validation code generator module 109.
• the mobile telephone 19 displays the validation code on display 21 so that the user can enter the validation code into the EPOS terminal 3 at step S213.
• the EPOS Terminal 3 sends the user entered validation code together with the MA and MTTC transaction IDs to the MA Server 5 at step S223.
• the MA Server 5 receives the user entered validation code and the MA and MTTC transaction IDs at step S225 and uses the MTTC transaction ID 46 to forward the user entered validation code to the MTTC Issuer Server 7 at step S227.
• the MTTC Issuer Server 7 receives the user entered validation code together with the MTTC transaction ID 46 and at step S231 uses the MTTC transaction ID 46 to identify the user account 83-3 corresponding to the authorisation request 42 and to retrieve the corresponding user's PIN 85-9 and password 85-11 from the user details data store 85.
• the retrieved user PIN 85-9 and password 85-11 and the offline authorisation code (generated at step S201) are then sent to the Validation and Authorisation Code Generator 91 which uses the same algorithm used in the mobile telephone 19 to regenerate the validation code .
• the controller 71 compares the validation code generated at step S231 with the user generated validation code.
• step S235 the validation code is stored in the "user authorisation message" field 87-11 of the user's transaction history table 87-Ul.
• step S89 shown in Figure 8f
• the user is able to select a default credit card to be used for such offline transactions and, accordingly, at step S87, the credit card details 85-13 for the default-selected credit card are retrieved from user details data store 85.
• step S233 the controller 71 determines that the two validation codes are not the same, then the user entered validation code is determined to be not authentic, and the processing returns to step S49 (shown in Figure 8d) where the unsuccessful transaction request status 48 is updated to failed in the user's transaction history table 87-Ul, before the processing continues to communicate the unsuccessful authorisation back to the merchant at the EPOS Terminal 3.
• the user is issued with a Mobile Telephone Transaction Card (MTTC) 11 with a unique card number 13 by the MTTC Issuer Server 7.
• MTTC Mobile Telephone Transaction Card
• the user then creates their user account on the MTTC Issuer Server 7 via the user account management unit 79 and the Internet 78.
• the entered user account details are stored in the user details data store 85. The way in which user account management operates in this embodiment will now be described with reference to Figures 10 and 11.
• the Internet enabled computing environment which enables users to set up and manage their mobile transaction user account comprises a user terminal 201 and the MTTC Issuer Server 7. Attached to the user terminal 201 is a monitor 203 for displaying data to the user, a keyboard 205 and a mouse 207 which provide a user interface to the user terminal 201 and a modem 209 for providing a communications link with the MTTC issuer server 7 via the Internet 78.
• this setup web page 221 includes a text box 225 for entering the MTTC number 13 that is marked on their MTTC card 11, a text box 227 for the user's name and text boxes 229-1 to 229-4 for the user's billing address.
• the MTTC card number 13 has the same form as a typical credit or debit card number having 16 digits.
• the user After the user has entered their personal details as prompted on display screen 221, the user clicks the "Next" button 235 provided toward the bottom of the page which results in the user entered details being transmitted 211 back to the MTTC Issuer Server 7 via the Internet 78 and received by the User Account Management Unit 79 via the Internet interface unit 77.
• the User Account Management Unit 79 retrieves the user account details 85-1 corresponding to the user entered card number 13 from the user details data store 85.
• the account number 83-3 is generated automatically when the MTTC card 11 is issued, and no account details are initially stored in the account details 85-1 for the associated account.
• the User Account Management Unit 79 then stores the user entered name and the billing address in the user account details data store 85.
• the user's name, entered in text box 227, and the user's billing address, entered in text boxes 229-1 to 229-4, are stored in the fields 85-5 and 85-7 respectively of the user account details 85-1.
• the MTTC Issuer Server 7 then sends a second account set-up web page 241 shown in Figure lib.
• the web page 241 also includes a header "Set Up Mobile Telephone Transaction Card Account" 243, and a prompt to the user to enter his or her security details, including text boxes 245 and 247 for the user to enter an authorisation PIN number and a login password.
• the authorisation PIN comprises four digits and the login password comprises a sequence of letters .
• the display screen 241 also includes a button "Back" 249 which allows the user to view and change the previously displayed screen 221 to, for example, modify the personal details entered in the previous screen.
• the user can press the "Next" button 251, which causes the user entered data to be transmitted back to the MTTC Issuer Server 7 via the Internet 78.
• the received user entered PIN and password are then stored as the user's PIN number 85-9 and security password 85-11 in the user account details 85-1.
• MTTC Issuer Server 7 then sends data for the next setup web page 261 which is shown in Figure lie.
• the web page 261 includes a header "Set Up Cards” 263 and a prompt for the user to enter his or her card details for a first of the user's cards, for example, a credit card or debit card as described above.
• the display screen 261 includes text input boxes 265, 267 and 269 for the user to enter a card description, the card number and the name of the card holder respectively.
• a list of card types 271 is also displayed so that the user can select the type of card which has been entered, for example, Visa card, MasterCard, American Express card, Switch card etc.
• Input text boxes 273, 275, 277, 279 and 281 are also provided for the user to enter the card's issue date, expiry date, issue number (if available) , the card security number (which is usually printed on the back of the card) and the card holder's billing address including the city and postcode.
• the user can also select, using the check box 285, whether the present card is to be used as the default card for "offline" transactions as described above.
• the display screen 261 also includes a "Back" button 287 which allows the user to view the previously displayed screen 241 so that the user can modify, if necessary, any of the previously entered details. Alternatively, if the user has entered all of the card details for the present card, the user presses the "Next" button 289 and the user entered card details are transmitted back to the MTTC Issuer Server 7 via the Internet 78.
• the user entered card details are received by the User Account Management Unit 79 via the Internet interface unit 77, and the received card details are stored as a first card in card details 85-C1 in the user details data store 85.
• Data for the next set-up web page 291 shown in Figure lid is then sent to the user terminal 201 for display to the user on the display 203.
• the web page 291 also includes a header "Set Up Cards” 293 and displays a confirmation that the user entered card details have been stored in the Mobile Telephone Transaction Card Issuer Server 7.
• the user is also asked if there are any more card details to be entered. If the user clicks on the "Yes" button 295, then the user account management unit 79 receives the user choice to add another card, and sends data back to the user terminal 201 to display web page 261 again, prompting the user for the details of the other card.
• the user account management unit 79 sends data for the next account setup web page 321 shown in Figure lie for display to the user on display 203.
• the web page 321 includes a header "Set Up Authorisation Contact Details" 323 and a prompt for the user to enter their mobile telephone details .
• An input text box 325 is provided for the user to enter a mobile telephone number, and pop-up menus are provided for the user to select the mobile telephone operator 327 associated with the mobile telephone number and the make 329 and model 331 of the mobile telephone handset 1 .
• the web page 321 also includes a "Back" button 333 which allows the user to view the previously displayed screen 291 so that the user can enter further card details if necessary.
• the web page 321 also includes a "next" button 335 that the user can click on after they have entered their mobile telephone details which results in the user entered mobile telephone details to be transmitted back to the MTTC Issuer Server 7 and stored as mobile telephone details 85-15 in the user details data store 85. Data for the next web page 341 shown in Figure llf is then sent to the user terminal 201 for display to the user on the display 203.
• the web page 341 also includes a header "Set Up Authorisation Contact Details" 343 and displays confirmation to the user that the mobile telephone details entered on the previous web page 321 have been stored in the user details data store 85. The user is also asked if they wish to add another mobile telephone. If the user clicks on the "Yes" button 345, then the user's selection is transmitted back to the user account management unit 79 and data for previous web page 321 is transmitted back to the user terminal 201 for display to the user on the display 203, in order to prompt the user to enter details for the next mobile telephone.
• the user clicks the "No" button 347 then the user's selection is transmitted back to the user account management unit 79 which then transmits data to the user terminal 201 for display to the user on the display 203 confirming that the user's account details 85-1 have successfully been stored in the user details data store 85 and that the user's account is now set up and ready for use in a transaction operation.
• the mobile telephone interface unit 75 sends the mobile transaction authentication module 107 and the transaction validation code generator module 109 to the users mobile telephone (s) 19 so that it can operate in a transaction system.
• the card details of the MTTC are useless to a third party who has fraudulently obtained the card details (unless they also obtain the user's mobile telephone and secret PIN and password) . Additionally, the user is prompted to authenticate and authorise every transaction before the transaction will be authorised by the credit card issuer, thereby giving peace of mind to the user and the merchant and reducing the chances of fraudulent transactions for the credit card issuer.
• the user also has the convenience of only having to carry a single card with them, instead of a number of different credit and debit cards . This also reduces the chances of the user losing or misplacing all or some of their cards, which would allow the credit card details to be used by someone else.
• the above described transaction system also has the advantage that the merchant EPOS terminal 3 , the merchant acquirer server 5 and the credit card issuer server 7 operate in a conventional manner.
• the system can therefore be easily incorporated into existing credit and debit card authorisation systems.
• the MTTC Issuer Server stored user account details which included the details of credit and debit cards registered by the user.
• the MTTC Issuer Server may also store details of loyalty cards together with user preferences as to which credit and debit cards and which loyalty cards are to be used with different merchants. In such an embodiment, the MTTC Issuer Server would ensure that the user's loyalty card details are returned to the merchant's EPOS terminal when the authorisation is provided for the current transaction.
• the preferences that the user can specify may include preferences of using certain cards for certain retailers and/or preferences for using different cards depending on the value of the transaction. For example, the user may specify to use a certain credit card for all transactions over a certain value.
• the MTTC Issuer Server would compare the user defined preferences with the transaction details and select the card based on the user's preferences .
• the user could still be given the opportunity to change this selection during the communication between the MTTC Issuer Server and the user's mobile telephone.
• the MTTC Issuer Server sent all of the credit and debit card details to the user's mobile telephone in order that the user can select the card to be used for the current transaction.
• the MTTC Issuer Server may use the details of the merchant contained in the authorisation request to filter out the credit and debit cards that the MTTC Issuer server knows that the merchant will not accept. In this way, the user is only provided with a list of credit and debit cards that the user can use with the current merchant.
• the terminals and servers communicate with one another via a direct dial telephone link.
• the terminals may be connected together via the Internet, a local area network (LAN) , a wireless LAN or a wide area network
• WAN Virtual Private Network
• VPN Virtual Private Network
• the user and the MTTC card are at a point of sale terminal in a physical shop.
• the user may use the MTTC card to perform a transaction with a remote merchant via the Internet.
• the merchant ' s EPOS terminal does not receive the user' s card number by inserting the MTTC into a card reader.
• the transaction details and the user entered card number are then transmitted to an EPOS module, for example, on the merchant's web site server.
• the EPOS module then processes the received transaction details and card number to generate an authorisation request as described above with reference to the flow diagram shown in Figure 8. Thereafter, the EPOS module will receive the authorisation signal and transmit the authorisation signal to the merchant's web site server, which will then display an appropriate authorisation message to the user to complete the transaction.
• the operation of the MTTC issuer server and the user's mobile telephone will be the same as in the first embodiment .
• the EPOS Terminal, the MTTC Issuer Server and the Credit Card Issuer Server all communicate with the same Merchant Acquirer Server.
• one or all of these terminals and servers may be able to communicate with several different Merchant Acquirer Servers .
• the MTTC issuer server may use a different MA server for the shadow transaction request than the one used for the original request .
• the data communicated between terminals and servers within the electronic transaction system is encrypted and decrypted.
• the data may not need to be encrypted if the terminals and servers communicate electronically with one another via secure data channels.
• only selected data may be encrypted, for example, data which includes the user's credit card number and details.
• look-up tables are used to store ID numbers of known card issuers along with the corresponding card issuer details and a list of user ID numbers and the corresponding account numbers.
• this data does not need to be stored in a look-up table, and instead, may be stored using another data structure such as, for example, a list or a hash table.
• a mobile transaction authentication module (stored in the mobile telephone) is triggered when a message is received from the MTTC Issuer Server.
• the received mobile telephone message may include a user-selectable link to a web page stored on the MTTC Server.
• the user can provide authorisation for the transaction using, for example, a web browser stored in their mobile telephone and the mobile telephone does not need to store any additional software modules .
• the users transaction history data store stores a separate transaction history table for each of the users.
• the transaction history details for all of the users may be stored in a single table.
• the user ID number or account number would be stored along with the transaction details to identify a transaction with its corresponding user.
• the MTTC Issuer Server may also include a completed transactions history data store for storing transaction history details for both successful and unsuccessful transactions such that the user's transaction history table only stores transaction details for the pending transactions .
• an offline authorisation code is displayed by the EPOS terminal and entered manually by the user into their mobile telephone. The mobile telephone then generates and displays a validation code which the user manually enters into the EPOS terminal .
• the codes may, instead, be communicated between the EPOS terminal and the mobile telephone automatically, via, for example, an infrared connection, a blue tooth connection or a physical cable connecting the terminal and the mobile telephone.
• a transaction fails immediately upon receipt of a card decline code from a Credit Card Issuer Server.
• the MTTC Issuer Server may be operable to determine if the user has another card which can be used to complete the transaction and if they have, then to generate another shadow transaction for the other card.
• the user when user authorisation is requested in an offline manner, the user is not able to select a specific card to use in the transaction.
• the validation code which is generated by the user's mobile telephone may include data identifying the user's selected card so that the user's selection is transmitted to the MTTC Issuer Server.
• the user connects to the MTTC Issuer Server via the Internet to create or modify his or her account details.
• an operator at the MTTC Issuer Server may speak to the user over the telephone and then enter the details into the account setup web pages in order to set up the account details on behalf of the user.
• the merchant EPOS terminal is arranged to communication with a merchant acquirer server and then with the MTTC issuer server.
• the EPOS terminal may be arranged to communicate directly with the MTTC issuer server.
• the merchant EPOS terminal may have to be programmed with new software to operate with the MTTC issuer server.
• the MTTC issuer server generated a shadow authorisation request for each authorisation request received from the MA server.
• the MTTC issuer server may be arranged to authorise some requests without generating a shadow authorisation request. For example, if the value of the transaction is below a threshold and the user's credit card has not been "black-listed", then the MTTC issuer server may decide to authorise the transaction without the delay in seeking authorisation from the credit card issuer server.
• the user was contacted on a mobile telephone to confirm authorisation for the transaction.
• a mobile telephone to confirm authorisation for the transaction.
• other mobile telecommunication devices such as personal digital assistants, laptops etc. can be used.
• the system can also be adapted to work with PCs, interactive Television systems and landline telephones, provided a separate communications path is available between the user's device and the MTTC issuer server, so that user authorisation can be provided independent of the merchant.
• Modern telecommunication networks are able to approximately identify the location of the mobile telephone.
• this location information may also be provided to the MTTC issuer server which can then compare the mobile telephone's location with the known location of the merchant EPOS terminal .
• the MTTC issuer server can therefore use this mobile telephone location information as a further check to ensure that the user is approximately at the merchant EPOS terminal.
• the MTTC issuer server transmitted a text message to the user's mobile telephone.
• This may be achieved using, for example, the short messaging service (SMS) or using the unstructured supplementary services data (USSD) defined in the GSM standard.
• SMS short messaging service
• USSD unstructured supplementary services data
• USSD is similar to SMS in that both use the GSM network signalling path, USSD messages are guaranteed to be sent and received immediately by the mobile telephone.
• the mobile network operators are only able to send USSD messages. Therefore, in such an embodiment, the MTTC issuer server would have to request the mobile network operator to send the message .
• the MTTC issuer server during an offline authorisation operation, the MTTC issuer server generates an offline authorisation code which is sent to the MA server, and the MTTC issuer server then waits for the user entered validation code to be sent back from the MA server.
• the MTTC issuer server may be arranged to wait for a predetermined time period and to determine that a transaction has failed if no validation code is received from the user in the predetermined time period.
• the merchant details which are stored in the memory of the EPOS terminal included details identifying the merchant's name.
• the merchant details may instead include merchant ID data and the MTTC issuer server may then be arranged to store merchant ID data for all of the known merchants together with the associated name of the merchant in a database.
• the MTTC issuer server can use the merchant ID data to identify the name of the merchant so that the mobile telephone message which is sent to the user's mobile telephone includes the name of the merchant.
• the user is first issued with a MTTC card having a unique card number, and the user then creates their user account on the MTTC issuer server.
• the user may first log on to the MTTC issuer server and enter their details to create a user account on the MTTC issuer server.
• the MTTC issuer server may be arranged to assign a MTTC card number to the user after the user has input their user details, and to then issue the user with their MTTC card which includes the assigned card number.
• the MTTC issuer server stored user account details for each user which included mobile telephone details, credit card details, user details etc. As the skilled person will appreciate, it is not essential to store all of this information. For example, in a simpler embodiment, the MTTC issuer server may only store the mobile telephone number and the credit card number for the user.
• the EPOS terminal stored and transmitted transaction details which included, for example, the price and quantity of the goods and a calculated total cost of the transaction. As the skilled person will appreciate, it is not essential to store all of this information. For example, in a simpler embodiment, the EPOS terminal may only store and transmit the total cost of the transaction.
• the user purchasing the goods was the same as the user who owns the credit cards and who is registered with the MTTC server.
• the user who actually purchases the goods may be different from the user who is registered with the MTTC server.
• the MTTC card may be given to a child or trusted third party for use in paying for goods or services.
• the registered owner will receive the authorisation request from the MTTC server. They can then choose to authorise or decline authorisation for the transaction.
• the MTTC issuer server when the MTTC issuer server contacted the user's mobile telephone, it transmitted a text message or used some other data message.
• the MTTC issuer server may set up a voice call to the user's mobile telephone.
• the user can provide the authorisation verbally to a human operator or a speech recognition system or can provide authorisation using standard DTMF touch tones in response to an automated dialogue system.
• the MTTC issuer server initiated communications with the user's mobile telephone in response to receiving an authorisation request for a transaction.
• the user may contact the MTTC server directly whilst the merchant is entering the transaction details into their EPOS terminal.
• the user may send a text message to the MTTC issuer server confirming the merchant details, the transaction details and their authorisation for the transaction.
• the MTTC issuer server would then use the stored mobile telephone number to identify the user who has transmitted the message (which will also include the user's mobile telephone number) .
• the MTTC issuer server When the MTTC issuer server receives the authorisation request from the MA server, it uses the user ID data in the received request, to identify the user making the purchase and then it compares the merchant details and transaction details in the communication received from the user with the corresponding details from the authorisation request received from the MA server, in order to verify the user's authorisation.
• the user verified their authorisation for the transaction by entering their PIN number and selected letters from their password.
• Authorisation may be given simply by the user responding to the message received from the MTTC issuer server.
• biometric data such as data from a voice scan, finger print scan, iris scan etc.
• the MTTC issuer server transmitted a single text message to the user requesting authorisation for the transaction. This initiated a software module in the mobile telephone which used the data in the received text message to prompt the user to authorise the transaction.
• a simpler embodiment may be provided in which multiple text messages are transmitted between the user's mobile telephone and the MTTC issuer server.
• the MTTC issuer server may transmit a message for each of the prompt screens discussed above in the first embodiment, with the user transmitting a response text message back to the MTTC issuer server.
• this is not preferred because of the latency involved in transmitting text messages and because of their transmission reliability.
• the MTTC is a "valueless" card in that it cannot be used directly to pay for the goods or services other than through the payment system described above.
• the MTTC card issuer may be able to provide credit facilities for the users or it may be able to debit a user's account with the appropriate funds for the current transaction.
• the MTTC issuer server would also perform the functions of a credit or debit card issuer server.
• the MTTC issuer server would preferably still include the details of the user's other credit and debit cards so that the user can select an alternative card to be used for a current transaction.
• the user is provided with a valueless card having card issuer data and user ID data.
• card issuer ID data and user ID data may be input to the merchant's EPOS terminal directly via the keypad.
• this data may be stored in the user's mobile telephone and then read from the user's mobile telephone by the EPOS terminal.
• the transaction system included a mobile telephone, a merchant's EPOS terminal, a MA server, a MTTC issuer server and a card issuer server.
• Each of these components may be formed from computer hardware circuits or from general purpose programmable processing devices together with processor executable instructions for configuring the programmable processing devices to operate in the above way.

Priority Applications (1)

Applications Claiming Priority (7)

Related Child Applications (1)

Publications (1)

Family

ID=32966153

Family Applications (1)

Country Status (2)

Families Citing this family (3)

Citations (1)

Family Cites Families (4)

• 2004
  • 2004-03-04 WO PCT/GB2004/000905 patent/WO2004079676A1/en active Application Filing
  • 2004-03-04 EP EP04717158A patent/EP1604339A1/de not_active Ceased

Patent Citations (1)

Also Published As

Similar Documents

Legal Events