GB2479366A

GB2479366A - Payment using mobile telephone

Info

Publication number: GB2479366A
Application number: GB1005759A
Authority: GB
Inventors: Richard Steggall
Original assignee: AVIENUS Ltd
Current assignee: AVIENUS Ltd
Priority date: 2010-04-07
Filing date: 2010-04-07
Publication date: 2011-10-12
Also published as: GB201005759D0

Abstract

A system, server and method are provided for the transfer of funds. The system comprises a mobile device 10 which can send and receive messages and a payment server 24 for establishing and making a payment to a merchant 28. Payment from a user to a merchant 28 is achieved using a mobile handset 10 in conjunction with text messages passed between the mobile handset 10 and a payment server 24 coupled to the internet 22. The payment server 24 can choose at random one of a plurality of personal user questions which is sent as a flash text message to the mobile handset 10 as a transaction confirmation question. The payment server 24 can receive an answer to the transaction confirmation question from the mobile handset 10. If the answer is correct, the transaction is completed. If the answer has been given incorrectly less than a predetermined number of times, the transaction confirmation question is re sent to the mobile handset. If the answer has been given incorrectly more than a predetermined number of times, the user account is suspended and the transaction is shut down. Fixed and variable amounts can be transferred between a user and a merchant, the transaction being initiated by either party.

Description

Mobile Telephone Payment The present invention relates to mobile telephones and particularly relates to payments made using and though mobile telephones.

Mobile telephones are evolving to more sophisticated forms, and now can include increasingly complex capabilities. WAP (Wireless Access Protocol) enabled mobile telephones and Personal Digital Assistants (PDAs) Laptop Computers and Palm lop computers all provide portable communications. All of these devices have the problem that they can be lost or stolen. Personal financial details can be placed in jeopardy by their loss or theft. Use of a mobile telephone can bring lack of security. The present invention seeks to allow financial transactions to take place involving a mobile telephone in a manner which allows a good degree of security.

All of the above mentioned devices have varying degrees of computational capability.

While there are more mobile telephones than people in developed countries, the majority of mobile telephones are basic models and are only guaranteed to have the capability to place and receive calls and to send and receive text messages, which are common to all mobile telephones. A payment system using mobile telephones requires to be accessible to all manner of mobile telephones. The present invention seeks to provide a system for making payments using a mobile telephone even of the most basic kind, thereby allowing universal access for the maximum number of people to use the system.

Those systems that already exist for making payments using a mobile telephone are tied to a single type of transaction. Setup is complex. The systems tend to involve a mobile telephone user who can only make payments to merchants or local authorities. This arrangement is severely limiting. More flexibility is desirable. The present invention seeks to provide a system wherein a variety of different transactions between different individuals and organizations can take place.

In the systems that already exist, the amounts that can be paid can be fixed. No intermediate amount can be paid. In the real world of trading, all sorts of different amounts are involved. The present invention seeks to make the mobile telephone a real part of trading by providing a system aUowing variable and selectable amounts to be paid.

According to a first aspect, the present invention consists in a system employable to transfer funds in a transaction, the system comprising: a mobile telephone handset, comprising means operable to send and receive messages; and a payment server, comprising means operable to send and receive messages; a merchant, comprising means capable of receiving payment; where the payment server comprises means operable automatically to establish a payment to be made by a user of the mobile telephone handset; and where the payment server comprises means operable automatically to make payment to the merchant.

According to a second aspect, the present invention consists in a payment server, employab'e to transfer funds in a transaction, the payment server comprising: means operable to send messages to and receive messages from a mobile telephone handset; and means operable to make payment to a merchant; where the payment server comprises means operable automatically to establish a payment to be made by a user of the mobile telephone handset; and where the payment server comprises means operable automatically to make the payment to the merchant.

According to a thirds aspect, the present invention consists in a method for transferring funds in a transaction, the method comprising the steps: a step of a mobile telephone handset sending and receiving messages to and from a payment server; a step of the payment server automatically establishing a payment to be made by a user of the mobile telephone handset; and a step of the payment server automatical'y making payment to a merchant.

Each of the aspects of the invention, further provides that the payment server can automatically send a message containing a transaction confirmation question to the mobile telephone handset; the mobile telephone handset can send a message answering the transaction confirmation question to the payment server; the payment server can automatically check that the answer to the transaction confirmation question is correct; and the payment server can automatically make payment to the merchant only if the answer is correct.

Each of the aspects of the invention, further provides that, in the event of the answer to the confirmation question being incorrect, the payment server can automatically require anew an answer to a confirmation question; and if the answer is incorrect a predetermined number of times in the same transaction, the payment server can automatically suspend the account of the user of the mobile telephone handset.

Each of the aspects of the invention, further provides that the payment server can select, at random, as the confirmation question, one of a plurality of questions personal to the user of the mobile telephone handset.

Each aspect of the invention further provides that the payment server can further comprise means random'y to select one or more characters from the answer to the question selected at random, the identity of the selected characters being provided as the confirmation question.

Each of the aspects of the invention further provides that the messages can be text messages and that the message containing a transaction confirmation question to be sent to the mobile telephone handset can be a flash text message.

Each of the aspects of the invention, further provides that the transaction can comprise at least one of: transfer of a fixed sum from the user of the telephone handset to a merchant, the transaction being initiated from the mobile telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the user of the telephone handset; transfer of a variable sum from the user of the te'ephone handset to a merchant, the transaction being initiated by the merchant; and transfer of a variable sum from the user of a first mobile telephone handset to a recipient user of second mobile telephone handset, the transaction being initiated by the user of the first mobile te'ephone handset.

The invention is further explained, by way of example, by the following description, read in conjunction with the appended drawings, in which: Figure 1 is a schematic diagram of an exemplary environment in which the present invention can be applied.

Figure 2, is a flowchart showing how a fixed sum of money can be transferred using the present invention.

Figure 3 a flow chart showing how a variable or selectable sum of money can also be transferred using the invention.

Figure 4 is a flow chart showing an exemplary manner in which a merchant initiated transaction can proceed using the present invention.

Figure 5 is a flow chart showing a peer to peer fund transfer operation according to the invention. and

Figure 6 is a flow chart illustrating how the invention deals with correct and incorrect answers to transaction conformation questions.

Attention is first drawn to Figure 1, showing is a schematic diagram of an exemplary environment in which the present invention can be applied.

A mobile handset 10 is capable of two way radio communication with the nearest one of a plurality of cell phone base stations 12, which in turn are each connected by a link 14 comprising landline, microwave link or fibre optic cable to one or more switches 16 which couple links 16 with each other, with the terrestrial telephone system 18, and with an Internet gateway 20 operable to couple cell phone signals to addresses within the internet 22. The gateway 20 may also comprise a radio communication facility allowing it to receive signals directly as if it was a mobile telephone handset.

The Internet 22 is coupled to a payment server 24, one or more bank sites 26 and one or more merchant sites.

The payment server receives and responds to payment transactions initiated by a merchant or by a user of a mobile telephone handset 10.

The invention is described, hereinafter, in terms of use of a mobile telephone system 10 12 14 16 and for use in conjunction with the Internet 22. It is to be appreciated that the invention can also be used with other communication systems than a mobile telephone system 10 12 14 16 and in conjunction with other forms of network that the nternet 22.

Attention is next drawn to Figure 2, a flowchart showing how a fixed sum of money can be transferred using the present invention. In figure 2, there are three columns. The left hand co'umn 30 portrays actions taken by the user of a mobile telephone handset 10.

The central column 32 portrays actions taken by the payment server 24. The left hand column 34 portrays actions taken by a merchant site 28. Broken lines between the columns 30 32 34 indicate sending of a message and the arrows on the broken lines indicate the direction of sending of the message. The payment server 24 also interacts with one or more bank sites 26.

The fund transfer commences from a start 36 where, in a first operation 38, a mobile handset 10 user dia's the ceU phone number, preferably a short code, of the payment server 24 and sends a text message to the payment server 24 indicating the identity of the merchant to whom a fixed payment is to be made. The identity of the user of the mobile handset 10 is automatically known from the telephone number of the mobile handset 10 from which the initiating call was placed to the text server 24. This identification of the merchant could be by means of an acronym, code, or any other short form which can be used to identify a particular merchant, or any other form capable of uniquely identifying the merchant. As already stated, the payment server knows the identity of the user of the mobile handset 10 by the telephone number of the mobile handset 10 which is automatically sent with the text message. The payment server 24 thus will have the user's bank details.

The term merchant is used loosely in this context, and can indicate any business or body to which fixed payment is made. The payment may, for example, to pay for parking or even a library or other fine. The merchant can be selling goods, to be provided later, or be a local authority or any organization or business offering a service. One example could be a provider of entry into a cost per entry or per day zone, such as a footba match, a congestion zone, or a museum. The examples given are not restrictive to the

invention's field of application.

In a second operation 40 the payment server 24 receives the text message sent in the first operation 38 and, in a third operation 42, the payment server 24 searches its records to identify the particular merchant specified by the mobile handset 10 user and to find what is the fixed cost, charged by that merchant. The payment server also finds the merchant's bank account. The payment server 24 also cafls up the identity of the user and the user's bank account.

In a fourth operation 44, the payment server 24 generates a randomly or pseudo random personal question, explained hereafter, unique to the proposed transaction the answer to which is known only to the user and the order of which is very hard to predict in advance, and sends a text message to the mobile handset 10 indicating the amount of the fixed charge and the selected question.

The security aspect of the random selection of a particular personal question is further enhanced by the payment server 24 making a random or pseudo random selection of one or more letters of the answer to the randomly selected question, the user of the mobile handset 10 being asked to give, for example, selected letters, preferably three, of the answer to the randomly selected question as the confirmation answer. In this manner, since the user sends only isolated characters from the answers, anyone else who finds, steals or otherwise has possession of the mobile telephone handset will be unable to examine stored text messages sent from the mobile handset 10 to learn the answers to the questions (also because the message received from the server is in flash).

In a fifth operation 46 the mobile handset 10 receives the text message, from the payment server 24, indicating the selected question and the amount. If the user of the mobile handset 10 approves the transaction, in a sixth operation 48 the user causes the mobile handset 10 to send the answer to the personal question back to the payment server 24, which the payment server 24 receives in a seventh operation 50.

This operation also involves testing the answer to see if it is correct. As explained hereafter, if the answer is wrong, the same or another question is sent by the payment server 24 to the mobe handset 10 and, if an incorrect answer is given more that a predetermined number of times, preferably two times, the account of the user is shut down until re-authorized.

The message, sent by the fourth operation and received by the fifth operation, can be a simple text message, but, for preference, is a so-cafled "flash" text message. A flash text message, when received, can be viewed but is not automaticaUy stored for future reading and reference in the way that regular text messages are stored in the mobile handset 10. The user of the mobile handset 10 has to memorize the random personal question before sending the answer to the payment server 24. The use of a flash text message has the advantage that, should the mobile handset be lost or stolen, a thief or finder cannot interrogate the mobile handset 10 to learn the personal questions that may be asked.

An eighth operation 52 of the payment server 24 is then to debit the account of the user of the mobile handset 10 and to credit the account of the merchant. This may involve merely moving amounts between records in the payment server 24, to be settled later by the payment server 24, or can mean actually making a debit from the bank and account listed for the user of the mobile handset 10 and actually making a credit to the bank and account listed for the merchant. Communications between a bank and the payment server 24 are preferably achieved through the internet, but can be achieved by any secure information transfer means available.

In a ninth operation 54 the payment server 24 sends a confirmation message to the merchant which is received by the merchant in a tenth operation 56. The message can be sent in the ninth operation 54 by any means. For preference the confirmation message of the ninth operation is sent via the Internet 22, but could be in any form, including, but not limited to, a text message or email.

The web server 24 then, in an eleventh operation 58, sends a text message bearing a receipt to the mobile handset 10 which the mobile handset 10 receives in a twelfth operation 50. Exit 62 indicates the end of the process.

Attention is next drawn to Figure 3, a flow chart showing how a variable or selectable sum can be transferred using the invention. In figure 3 the columns designate activities as they do in Figure 2 and the broken lines between columns designate the same message sending and receiving actions as explained with reference too Figure 2.

From a start 64 a thirteenth operation 66 has the user employ the mobile handset 10 to dial the ceU phone number of the payment server 24 and text the merchant's identity and the amount to be paid, to the payment server 24. A fourteenth operation 68 has the payment server 24 receive the text message from the mobile handset 10 and a fifteenth operation 70 has the payment server 24 match its records to determine the identity of the user, the user's account, the identity of the merchant, the account of the merchant, and whether or not the merchant's account avows payment of so cafled "dynamic' amounts, that is to say, amounts that can be externaUy specified and which are not fixed.

If a first test 72 in the payment server 24 detects that dynamic payments are not accepted by the merchant's account, a sixteenth operation 74 has the payment server 24 send a text message to the cell phone number of the mobile handset 10 indicating that the transaction cannot proceed and giving the reason "the merchant cannot accept payment in this amount". The sixteenth operation 74 returns control to the fourteenth operation 68 where the payment server 24 waits for receipt of a text message from a mobile handset 10.

If the mobile handset 10 user has inadvertently sent an amount to the payment server 24 when identifying a fixed payment merchant, as specified in the description of Figure 2, and the amount sent tallies with the fixed payment amount accepted by the merchant's account, the first test 72 recognized that the payment attempt was valid and continues as if the merchant's account accepted dynamic sums.

The message, sent in the sixteenth operation 74 from the payment server 24 to the mobile handset 10, is waited for, in the mobile handset 10, by a second test 76. If the second test 76 detects that the mobile handset 10 has received the text message sent in the sixteenth operation 74, the received text message is displayed and activity in the mobile handset 10 is terminated at exit 78.

If the first test 72 in the payment server 24 finds that dynamic payment is acceptable to the merchant's account, the first test passes control to a seventeenth operation 80 which has the payment server 24 randomly or pseudo randomly select a personal question, and send a text message to the mobUe handset 10 containing the question and indication of the amount to be paid.

The security aspect of the random selection of a particular personal question is further enhanced by the payment server 24 making a random or pseudo random selection of one or more letters of the answer to the randomly selected question, the user of the mobile handset 10 being asked to give, for example, selected letters, preferably two, of the answer to the randomly selected question as the confirmation answer. In this manner, since the user sends only isolated characters from the answers, anyone else who finds, steals or otherwise has possession of the mobile telephone handset will be unable to examine stored text messages sent from the mobile handset 10 to learn the answers to the questions.

In the event of the second test 76 in the mobile handset 10 not receiving a refusal message sent by the sixteenth operation 74 in the payment server 24, control passes to an eighteenth operation 82 in the mobile handset 10 which receives and displays the question and the amount sent by the seventeenth operation 80 in the payment server 24.

The selected personal question and amount are preferably sent, as described for Figure 2, as a "flash" text message, which, for the reasons given in the description of Figure 2, provides security by not automatically being stored in the mobile handset 10 after viewing.

If, on viewing, the mobile handset 10 user agrees the transaction, the user employs the mobile handset 10, in a nineteenth operation 84, to send a text message back to the payment server 24 containing the answer to the question. A twentieth operation 86 in the payment server 24 receives the answer text message from the mobile handset 10.

This operation also involves testing the answer to see if it is correct. As expaned hereafter, if the answer is wrong, the same or another question is sent by the payment server 24 to the mobe handset 10 and, if an incorrect answer is given more that a predetermined number of times, preferably two times, the account of the user is shut down until re-authorized.

A twenty first operation 88 of the payment server 24 then debits the account of the user of the mobile handset 10 and credits the account of the merchant. As described of Figure 2, this may involve merely moving amounts between records in the payment server 24, or can mean actuay making a debit from the bank listed for the user of the mobile handset 10 and actuay making a credit to the bank listed for merchant.

Communications between a bank and the payment server 24 are preferably achieved through the internet, but can be achieved by any secure means available.

In a twenty second operation 90 the payment server 24 sends a confirmation text message to the merchant which is received by the merchant in a twenty third operation 92. The message can be sent in the twenty second operation 90 by any means. For preference, the confirmation message of the twenty second operation 90 is sent via the Internet 22, but could be in any form, including, but not limited to, a text message or email.

The web server 24 then, in a twenty fourth operation 94, sends a text message bearing a receipt to the mobile handset 10 which the mobile handset 10 receives and displays in a twenty fifth operation 96. Exit 78 indicates the end of the transaction process.

Attention is next drawn to Figure 4, a flow chart showing an exemplary manner in which a merchant initiated transaction can be processed by the present invention. In figure 4 the columns 30 32 34 designate activities as they do in Figures 2 and 3 and the broken lines between columns 30 32 34 designate the same message sending and receiving actions as explained with reference too Figures 2 and 3.

The merchant initiated transaction commences from a start 98 where a twenty sixth operation 100 at the merchant site 28 has the merchant raise a payment request and send a message to the payment server 24 indicating the nature of the transaction, the amount and the identity of the user.

The identity of the user can be indicated by various means, known to the skilled man, but, for preference, is here indicated by the merchant sending the user's mobile telephone number, thereby allowing the payment website 24 to take and directly to use the user's mobile telephone number, cutting down the otherwise required activity of the payment website to identifying the user and finding his mobile telephone number from other data given by the merchant. Payment server 24 increased efficiency is thereby made possible.

The message sent in the twenty sixth operation 100 can be by any means. For preference, the twenty sixth operation 100 confirmation message is sent via the Internet 22, but could be sent in any form, including, but not imited to, a text message or email.

The payment server 24 receives the detais from the merchant in a twenty seventh operation 102 and, in a twenty eighth operation 104, searches its records to establish the identity and the account of the user in the merchant payment request, the identity and account of the merchant, and generates a user payment request and a randomly or pseudo randomly selected personal question which a twenty ninth operation 106 sends as a text message to the mobile handset 10.

The security aspect of the random selection of a particular persona question is further enhanced by the payment server 24 making a random or pseudo random selection of one or more letters of the answer to the randomy selected question, the user of the mobile handset 10 being asked to give, for example, selected letters, preferably two, of the answer to the randomly selected question as the confirmation answer. In this manner, since the user sends only isolated characters from the answers, anyone else who finds, steals or otherwise has possession of the mobile telephone handset will be unable to examine stored text messages sent from the mobile handset 10 to learn the answers to the questions.

The question and amount are preferably sent, as described for Figures 2 and 3, as a "flash" text message, which, for the reasons given in the description of Figure 2, provides security by not automaticay being stored in the mobile handset 10 after viewing.

A thirtieth operation 108 in the mobile handset 10 receives and displays the message sent by the payment server 24 in the twenty ninth operation 106.

If, on viewing the received message, the mobile handset 10 user agrees the transaction, the user employs the mobile handset 10, in a thirty first operation 110, to send a text message back to the payment server 24 containing the answer to the question. A thirty second operation 112 in the payment server 24 receives the answer to the question text message from the mobile handset 10.

This operation also involves testing the answer to see if it is correct. As explained hereafter, if the answer is wrong, the same or another question is sent by the payment server 24 to the mobile handset 10 and, if an incorrect answer is given more that a predetermined number of times, preferably two times, the account of the user is shut down until re-authorized.

A thirty third operation 114 of the payment server 24 is then debits the account of the user of the mobile handset 10 and credits the account of the merchant. As described for Figure 2 and Figure 3, this may involve merely moving amounts between records in the payment server 24, or can mean actually making a debit from the bank and account listed for the user of the mobile handset 10 and actually making a credit to the bank and account listed for merchant. Communications between a bank and the payment server 24 are preferably achieved through the internet, but can be achieved by any secure means available.

In a thirty fourth operation 116, the payment server 24 sends a confirmation text message to the merchant which is received by the merchant in a thirty fifth operation 118. The message can be sent in the thirty fourth operation 116 by any means. For preference the confirmation message of the thirty fourth operation 116 is sent via the Internet 22, but could be in any form, including, but not limited to, a text message or email.

The web server 24 then, in a thirty sixth operation 120, sends a text message bearing a receipt to the mobile handset 10 which the mobile handset 10 receives and displays in a thirty seventh operation 122. End 124 indicates the end of the transaction process.

Attention is next drawn to Figure 5, a flow chart showing a peer to peer fund transfer operation according to the invention, where one mobile handset 10 user can pay to another mobi'e handset 10 user. In the description that follows, the mobile handset 10 user who makes the payment is called the user, and the mobile handset 10 user who receives payment is called the recipient.

By peer to peer fund transfers, it is possib'e to use a mobile telephone handset 10 to lend or pay back funds to a friend or acquaintance, pay for small items not necessarily provided by a recognized merchant, to receive funds from another, and a host of other transactions that occur naturally in everyday life for which cash in a wallet may not be readily avai'able. The use of a mobile handset to make payment avoids carrying credit and debit cards which can be ost, stolen and avoids the necessity to have a specially dedicated machine to accept cards.

In figure 5 the columns designate activities as they do in Figures 2, 3 and 4, with the exception that the right hand co'umn 126 of figure 5, instead of indicating the activities of the merchant, indicates the activities of the second mobile handset 10 user, namely the recipient of fund transfer. The broken lines between columns designate the same type of message sending and receiving actions as explained with reference too Figures 2, 3 and 4.

From a start 128 the user employs their mobife handset 10 to send, in a thirty eighth operation 130, a text message, to the payment server 24, detailing the recipient and the amount to be transferred to the recipient. The identity of the peer to peer recipient is designated by the recipient's mobile telephone number, which adds payment server 24 improved efficiency as described for the merchant initiated fund transfer depicted in Figure 4.

In the payment server 24, a thirty ninth operation 132 receives the text message sent from the mobile handset 10 in the thirty eighth operation 130, and a fortieth operation 134 has the payment server 24 check ts records to establish the identity of the recipient, the identity of the user, and their respective account details.

The payment server 24, in a forty first operation 136, randomly or pseudo randomly selects one of a pluraUty of personal user questions which a forty second operation 138 sends as a text message to the user's mobile handset 10 together with details of the amount and the recipient.

The security aspect of the random selection of a particular persona' question is further enhanced by the payment server 24 making a random or pseudo random selection of one or more letters of the answer to the random'y selected question, the user of the mobile handset 10 being asked to give, for example, selected letters, preferably two, of the answer to the randomly selected question as the confirmation answer. In this manner, since the user sends only isolated characters from the answers, anyone else who finds, steals or otherwise has possession of the mobile telephone handset will be unable to examine stored text messages sent from the mobile handset 10 to learn the answers to the questions.

The selected question and amount are preferably sent, as described in the descriptions for Figures 2, 3 and 4, as a "flash" text message, which, for the reasons given in the description of Figure 2, provides security by not automatically being stored in the mobile handset 10 after viewing.

A forty third operation 140 in the mobile handset 10 receives and displays the message sent by the payment server 24 in the forty second operation 138.

If, on viewing, the mobile handset 10 user agrees the transaction, the user employs the mobile handset 10, in a forth fourth operation 142, to send a text message back to the payment server 24 containing the answer to the personal question. A forty fifth operation 144 in the payment server 24 receives the answer text message from the mobi'e handset 10.

A forty sixth operation 146 of the payment server 24 is then debits the account of the user of the mobile handset 10 and credits the account of the recipient. In so doing, the payment server may communicate with one or more banks. As described for Figures 2, 3 and 4, account debiting and crediting may involve merely moving amounts between records in the payment server 24, or can mean actuay making a debit from the bank and account listed for the user of the mobile handset 10 and actually making a credit to the account and bank listed for the recipient. Communications between a bank and the payment server 24 are preferably achieved through the internet, but can be achieved by any secure means available.

In a forty seventh operation 148, the payment server 24 sends a confirmation text message to the recipient which is received by the recipient in a forty eighth operation 150.

The payment server 24 then, in a forty ninth operation 152, sends a text message bearing a receipt to the user's mobile handset 10 which the mobile handset 10 receives and displays in a fiftieth operation 154. End 156 indicates the end of the peer to peer transaction process.

Attention is next drawn to Figure 6, a flow chart illustrating how the invention deals with correct and incorrect answers to transaction conformation questions.

Figure 6 is exemplary of how the seventh operation 50 of Figure 2, the twentieth operation 86 of Figure 3, the thirty second operation 112 of Figure 4 and the forty fifth operation 144 of Figure 5 can perform their functions.

Each operation 50 86 112 144 is commenced from an entry 158. A fifty first operation receives the text message from the mobile handset 10 and a third test 162 checks to see if the answer given was correct.

If the third test 162 finds that the answer given was correct, control passes to a regular exit 164 from which the operation passes to the next operation for that transaction.

If the third test 162 finds that the answer given is incorrect, control is passed to a fourth test 166 which checks to see if the number of answer attempts for this transaction has exceeded a predetermined number, in this case two attempts. The predetermined number of attempts can be more or less than two, depending upon the preferences of the designer.

If the number of answer attempts has not exceeded the predetermined number, the fourth test 166 passes control to a fifty second operation 168 which has the payment server 24 re send the confirmation question to the mobile handset 10 and the passes control back to the fifty first operation 160 where the payment server waits to receive an answer to the confirmation question.

The resent confirmation question can be the same question, or can be another question, chosen at random from a plurality of personal questions concerning the user of the mobile handset 10 and held in the payment server together with their answers. The particular characters of the selected answer to be sent back by the mobile handset 10 to confirm the transaction are also randomly selected.

If, however, the fourth test 166 detects that more than the predetermined number of attempts to answer the confirmation question have been made in this transaction, control is passed to a fifty third operation 170 which suspends the user account until re-activated by, for example, re-verification using a sign up website.

A fifty fourth operation 172 then terminates the current transaction and an irregular exit 174 has the payment server 24 return to general duties without executing the next operation which would have been required had the current transaction not been terminated.

The mobe handset 10 users and the merchants 28 require to be signed up to participate in fund transfer activities. The sign up process cab be achieved online by accessing the payment server 24 website, or some linked or affiliated website on the Internet 22, or by fiUing in a form and mailing it to the organizers of the payment server.

In order to sign up, it is preferred that a mobile handset 10 user provides the foUowing information: name and tit'e; email address; mobile phone number; date of birth; and chosen password.

The mobile handset 10 user wi also be invited to provide and/or respond to plurality of persona' questions, the answers to which are used by the payment server 24 to determine the validity of user. During confirmation of a transaction, the message sent as a flash text message from the payment server 24 to the user handset 10 indudes a selected one of the plurality of the personal questions as a confirmation question. The text message sent by the mobile handset 10 user back to the payment server 24 wiI confirm (or not) the identity of the user. For preference, one, some or aU of the user's email address, user's signup website password, users email address and user's date of birth are automaticaUy included as personal questions to be answered, together with questions posed by the signup website and any questions placed by the user their self.

If the mobile handset 10 is lost or stolen, a subsequent unauthorised operator will not know the questions, since they were delivered as flash text message. If the authorized user has not deleted the text messages the authorized user has sent from the mobile handset 10, an unauthorized operator may read the text messages to recover some or all of the answers. Random selection of the characters from the answers to the personal questions held in the payment server 24 to be sent as the confirming text message to the payment server 24 from the mobile handset 10, means that the text messages sent as answers to confirmation messages are unlikely to be of use to the unauthorized user.

Further, the unauthorized operator will not know to which random personal question each answer applies. If there are N different questions, the unauthorized operator has a much less than 1/N chance of randomly guessing what the answer should be, even if all of the answers are available to the unauthorized operator. If two wrong answers are given consecutively during an attempted transaction, the account of the authorized mobile handset 10 user is disabled until he authorized user successful'y authenticates using the signup website.

By this means, although there is a possibi'ity that the unauthorized operator may correctly guess the answer to a personal question, the present invention greatly reduces the likelihood of account misuse while keeping customer usability high.

The mobile handset 10 user can also be required to provide credit or debit card details comprising: cardholder name; billing address; start and expiry dates; and issue number (if applicable).

The mobile handset 10 user may also elect to provide bank account details including: sort code; account number; bank name; bank branch; and account holder's name.

The mobile handset 10 user can also elect security levels for their mobile phone fund transfer account, the security levels comprising: daily maximum spend; maximum transaction size; and frequency of transaction statement.

The selectable maximum spend per day preferably starts at a low leve' and has a top level which makes it impossible for a lost or stolen mobile telephone handset 10 to be abused to cause a user great expense. The lower limit is suggested as £10.00 per day and the upper limit is suggested as £50.00 per day.

The maximum transaction size is that size of transaction beyond which any transaction will be refused.

The frequency of transaction statement is preferably made weekly or monthly, but if delivered by text message of email, could be daily and if delivered to a user accessible web site, cou'd be instantaneous.

To complete the mobile handset 10 user signup, the user is required to enter into the signup website a randomly generated code, sent as a text message to the mobile telephone handset 10 of the user, in order to confirm the user's telephone number.

Signup of a merchant follows along very similar lines, the merchant being required to provide the following merchant details: business name; registered address; VAT and/or sales tax number; and administrative, business and technical contact details. A description of the business activity is required for review.

The merchant is also be required to provide credit or debit card details for charge-backs comprising: cardholder name; billing address; start and expiry dates; and issue number (if applicable) and bank account details for out-payments including: sort code; account number; bank name; bank branch; and account holder's name.

The merchant is a'so asked the types of sale they offer and the technical expertise the merchant has availab'e.

The invention is defined in the appended claims.

Claims

Claims 1. A system employable to transfer funds in a transaction, the system comprising: a mobile telephone handset, comprising means operable to send and receive messages; a payment server, comprising means operable to send and receive messages; and a merchant, comprising means capable of receiving payment; where the payment server comprises means operable automatically to establish a payment to be made by a user of the mobile te'ephone handset; and where the payment server comprises means operable automatically to make payment to the merchant.
2. The system according to Claim 1, wherein: the payment server comprises means operable automatically to send a message containing a transaction confirmation question to the mobile telephone handset; the mobile telephone handset comprises means operable to send a message answering the transaction confirmation question to the payment server; the payment server comprises means operable automatically to check that the answer to the transaction confirmation question is correct; and the payment server comprises means operable automatically to make payment to the merchant only if the answer is correct.
3. The system, according to C'aim 2, wherein; in the event of the answer to the confirmation question being incorrect, the payment server comprises means operab'e automatica'ly to require anew an answer to a confirmation question; and if the answer is incorrect a predetermined number of times in the same transaction, the payment server comprises means operable automatically, to suspend the account of the user of the mobile telephone handset.
4. The system, according to any of C'aims 2 or 3, wherein the payment server comprises means operable to select, at random, as the confirmation question, one of a plurality of questions personal to the user of the mobile telephone handset.
5. The system, according to claim 4, wherein the payment server further comprises means randomly to select one or more characters from the answer to the question selected at random, the identity of the selected characters being provided as the confirmation question.
6. The system, according to any of C'aims 2 to 5, wherein the messages are text messages.
7. The system, according to C'aim 7, wherein the message containing a transaction confirmation question to be sent to the mobile telephone handset is a flash text message.
8. The system, according to any of the preceding Claims, wherein the transaction comprises at least one of: transfer of a fixed sum from the user of the telephone handset to a merchant, the transaction being initiated from the mobile telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the user of the telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the merchant; and transfer of a variable sum from the user of a first mobile telephone handset to a recipient user of second mobile telephone handset, the transaction being initiated by the user of the first mobile telephone handset.
9. A payment server, employable to transfer funds in a transaction, the payment server comprising: means operable to send messages to and receive messages from a mobile telephone handset; and means operable to make payment to a merchant; where the payment server comprises means operable automatically to estabsh a payment to be made by a user of the mobe telephone handset; and where the payment server comprises means operable automatically to make the payment to the merchant.
10. The payment server, according to Claim 9, wher&n: the payment server comprises means operable automatically to send a message containing a transaction confirmation question to the mobile telephone handset; the payment server comprises means operable to receive from the mobile telephone handset a message answering the transaction confirmation question; the payment server comprises means operable automatically to check that the answer to the transaction confirmation question is correct; and the payment server comprises means operable automaticaHy to make payment to the merchant only if the answer is correct.
11. The payment server, according to Claim 10, wherein; in the event of the answer to the confirmation question being incorrect, the payment server comprises means operable automaticaUy to require anew an answer to a confirmation question; and if the answer is incorrect a predetermined number of times in the same transaction, the payment server comprises means operable automaticay, to suspend the account of the user of the mobile telephone handset.
12. The payment server, according to any of Claims 9 or 10, wherein the payment server comprises means operable to select, at random, as the confirmation question, one of a plurality of questions personal to the user of the mobile telephone handset.
13. The payment server, according to claim 12, the payment server further comprises means randomly to select one or more characters from the answer to the question selected at random, the identity of the selected characters being provided as the confirmation question.
14. The payment server, according to any of Claims 10 to 13, wherein the messages are text messages.
15. The payment server, according to Claim 14, wherein the message containing a transaction confirmation question to be sent to the mobile telephone handset is a flash text message.
16. The payment server, according to any of Claims 9 to 15, wherein the transaction comprises at least one of: transfer of a fixed sum from the user of the telephone handset to a merchant, the transaction being initiated from the mobile telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the user of the telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the merchant; and transfer of a variable sum from the user of a first mobile telephone handset to a recipient user of second mobile telephone handset, the transaction being initiated by the user of the first mobile telephone handset.
17. A method for transferring funds in a transaction, the method comprising the steps: a step of a mobile telephone handset sending and receiving messages to and from a payment server; a step of the payment server automatically establishing a payment to be made by a user of the mobile telephone handset; and a step of the payment server automatically making payment to a merchant.
18. The method, according to Claim 17, including the steps: a step of the payment server automatically sending a message containing a transaction confirmation question to the mobile telephone handset; a step of the mobile telephone handset sending a message answering the transaction confirmation question to the payment server; a step of the payment server automatically checking that the answer to the transaction confirmation question is correct; and a step of the payment server automatically making payment to the merchant only if the answer is correct.
19. The method, according to Claim 18, induding the steps: in the event of the answer to the confirmation question being incorrect, the payment server automatically requiring anew an answer to a confirmation question; and if the answer is incorrect a predetermined number of times in the same transaction, the payment server automatically suspending the account of the user of the mobile telephone handset.
20. The method, according to any of Claims 18 or 19, including a step of the payment server selecting, at random, as the confirmation question, one of a plurallty of questions persona' to the user of the mobile telephone handset.
21. The method, according to claim 20 including the steps of: a step of randomly selecting one or more characters from the answer to the question selected at random; and a step of providing the identity of the selected characters as the confirmation question.
22. The method, according to any of Claims 17 to 21, wherein the messages are text messages.
23. The method, according to Claim 22, wherein the message containing a transaction confirmation question to be sent to the mobile telephone handset is a flash text message.
24. The method, according to any of Claims 17 to 23, for use where the transaction comprises at least one of: transfer of a fixed sum from the user of the telephone handset to a merchant, the transaction being initiated from the mobile telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the user of the telephone handset; transfer of a variable sum from the user of the telephone handset to a merchant, the transaction being initiated by the merchant; and transfer of a variable sum from the user of a first mobile telephone handset to a recipient user of second mobile telephone handset the transaction being initiated by the user of the first mobile telephone handset