MOBILE PAYMENT METHOD AND SYSTEM

Field of the Invention

This invention relates to a method and a system for conducting a payment using a mobile communication device (MCD). More particularly, but not exclusively, this invention relates to a method and a system for conducting a payment using a MCD in over-the-counter and automatic teller transactions.

Background to the Invention

The use of MCDs, such as cellular phones, personal digital assistants (PDAs) and palmtops, for conducting financial transactions over wireless communication networks is well known. The systems and methods for conducting such financial transactions that are known currently tend to exclude the use of fixed point of sale (POS) terminals, as the trend has been to conduct such transactions using MCDs only, as this is felt to be less hardware-dependent and hence more convenient to both vendor and customer.

There are, however, several disadvantages associated with the current art. First, the known systems and methods still require a customer to use his credit card when making payment. For example, in some scenarios, customers might be required to produce a credit card or debit card to a vendor, either to obtain the card details and/or to make an impression of that card for transaction verification purposes. Thus, despite their convenience, the known systems and methods cannot be said to be truly "cardless" or "walletless", as customers are always required to use some bank card in addition to their MCD in order to effect the payment.

The present invention is directed, in part, towards addressing certain

problems with MCD-based financial transactions that are conducted in a vendor's premises, where multiple POS terminals are to be found. A constant concern amongst such vendors is to ensure that customers are processed through the paypoints in the shortest time possible. This, in turn, requires that payments conducted at the POS terminals need to be conducted as quickly as possible. A problem with current systems and methods of conducting payments at a vendor's POS terminal using a MCD is that these transactions are effected too slowly for the vendor's needs.

Furthermore, many of the banking products available currently, which permit the making of a payment using a MCD, involve the use of a short message service (sms). The trouble with sms-based applications is that, because a sms utilises store-and-forward transaction-orientated technology, these applications are not as fast as unstructured supplementary service data (USSD) applications, which are session-orientated, and hence more efficient.

There are further disadvantages associated with the technology available currently. For instance, at least some customers are reluctant to use the keypad of a vendor's POS terminal to enter data, which is required as part of the payment process, for fear that the confidentiality of this information can be compromised, and that funds might then be pilfered from the customer's account.

Finally, at least some customers of banks have expressed reluctance to use automatic teller machines (ATMs) for two reasons, both of which are related to the keypad of the ATMs themselves. First, there is a concern that potential fraudsters spy on ATM customers to learn the PIN to customers cards, which would be used if and when the fraudsters are successful in stealing the bank card from the customer subsequently. Second, there have been reports in the media of fraudsters who attach fake card feeders and miniature cameras to ATMs, which equipment is used to misappropriate both the PIN and the

bank card of bank customers for the same purpose. There is therefore an aversion amongst banking customers to use ATMs.

Object of the Invention

It is an object of the present invention to provide a method and a system for conducting a payment using a MCD that, at least partially, overcomes the abovementioned problems and disadvantages associated with the prior art.

Disclosure of the Invention

According to a first aspect of the invention, there is provided a method for conducting a payment using a MCD, the method comprising the steps of: i. sending a payment request from a POS device, wherein the payment request is for authorisation of payment from a purchaser to a vendor; ii. receiving the payment request at a server, iii. authenticating the purchaser's identity and creditworthiness at the server; iv. if both the purchaser's identity and creditworthiness are authenticated, sending a confirmation request from the server, wherein the confirmation request is to confirm that the payment is to be made from the purchaser to the vendor; v. receiving the confirmation request at the MCD; and vi. sending a confirmation message from the MCD to the server, confirming that the payment may be made.

The method for conducting a payment may further include the step of: vii. sending a transaction receipt to the POS device, alternatively to the MCD, further alternatively to both the POS device and the MCD, to record that the payment was concluded successfully.

In an alternative embodiment, the method for conducting a payment using a

MCD may comprise the steps of: i. sending a payment request from a POS device, wherein the payment request is for authorisation of payment from a purchaser to a vendor; ii. receiving the payment request at a server; iii. authenticating the purchaser's identity and creditworthiness at the server; iv. if both the purchaser's identity and creditworthiness are authenticated, sending a confirmation request from the server, wherein the confirmation request is to confirm that the payment is to be made from the purchaser to the vendor, and includes an authorisation code; v. receiving the confirmation request at the MCD; vi. entering the confirmation code into the POS device; vii. sending a confirmation message from the POS device, which confirmation message includes the authorisation code entered into the

POS device; viii. receiving the confirmation message at the server; and ix. verifying that the authorisation code received in the confirmation message matches the authorisation code included in the confirmation request, and if so, confirming that the payment may be made.

The POS device may be a cash register terminal, alternatively the POS device may be a computer having internet or other network connectivity.

Preferably, the server is the server of the financial institution guaranteeing payment by the purchaser.

The confirmation request may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms. Most preferably, the confirmation request takes the form of a USSD message.

The confirmation request may further take the form of a USSD message or a sms sent from the server to the MCD and/or to the POS.

Most preferably, the confirmation message takes the form of a USSD message.

The confirmation request may request information selected from the group consisting of: a PIN, a password, the value of the transaction, and any combination of these.

The confirmation message may take the form of a USSD message or a sms sent from the MCD to the server.

Most preferably, the confirmation message takes the form of a USSD message.

The method for conducting a payment may further include the step of: iA: routing the payment request to a server of the purchaser's financial institution.

The payment request may be routed from the POS terminal to the server of the purchaser's financial institution via a fixed landline telecommunications network, alternatively via a mobile telecommunications network, further alternatively via a radio network.

According to a second aspect of the invention, there is provided a system for conducting a payment using a MCD, the system comprising: i. a POS terminal; ii. a MCD for communicating over a mobile communications network; and iii. a server, being adapted to receive a payment request from the POS

terminal, wherein the payment request is for authorisation of payment from a purchaser to the vendor, and wherein the server is programmed to authenticate the purchaser's identity and creditworthiness; and, if both the purchaser's identity and creditworthiness are authenticated, the server being further programmed to send a confirmation request to the MCD, wherein the confirmation request is to confirm that the payment is to be made; the server being further adapted to receive a confirmation message from the MCD and being further programmed to effect the payment on receiving the confirmation message from the MCD.

In an alternative embodiment, the system for conducting a payment using a

MCD may comprise: i. a POS terminal; ii. a MCD for communicating over a mobile communications network; and iii. a server, being adapted to receive a payment request from the POS terminal, wherein the payment request is for authorisation of payment from a purchaser to the vendor, and wherein the server is programmed to authenticate the purchaser's identity and creditworthiness; and, if both the purchaser's identity and creditworthiness are authenticated, the server being further programmed to send a confirmation request to the MCD, wherein the confirmation request is to confirm that the payment is to be made; the server being further adapted to receive a confirmation message from the POS terminal and being further programmed to validate information contained in the confirmation message in order to effect the payment on receiving the confirmation message from the POS terminal.

The confirmation request may include validation data, which validation data is required to be included in the confirmation message in order for the payment to be effected.

The validation data may be selected from the group consisting of: a PIN, a password, the value of the transaction, and any combination of these. Preferably, the validation data is a uniquely generated PIN.

The server may be further programmed to send a transaction receipt to the POS device, alternatively to the MCD, further alternatively to both the POS device and the MCD to record that the payment was concluded successfully.

Preferably, the server is the server of the financial institution guaranteeing payment by the purchaser.

The POS device may be a cash register terminal, alternatively the POS device may be a computer having internet or other network connectivity.

The confirmation request may take the form of a USSD message or a sms sent from the server to the MCD.

The confirmation request may request information selected from the group consisting of: a PIN, a password, the value of the transaction, and any combination of these.

The confirmation request may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms. Most preferably, the confirmation request takes the form of a USSD message.

According to a third aspect of the invention, there is provided a method for obtaining a cash payment from an ATM using a MCD, the method comprising the steps of:

i. sending a payment request from a MCD, wherein the payment request is for authorisation of a cash payment from the ATM to a user of the MCD; ii. receiving the payment request at a server; iii. authenticating the user's identity and creditworthiness at the server; iv. if both the user's identity and creditworthiness are authenticated, sending a confirmation request from the server, wherein the confirmation request is to confirm that the cash payment is to be made from the ATM to the user; and v. receiving the confirmation request at the MCD.

The method for obtaining a cash payment from an ATM may further include the step of: vi. sending a confirmation message from the MCD to the server, confirming that the cash payment is to be made.

The method for obtaining a cash payment from an ATM may further include the step of: vii. sending a transaction receipt to the MCD, alternatively to the ATM, further alternatively to both the MCD and the ATM, to record that the cash payment was concluded successfully.

In an alternative embodiment, the method for obtaining a cash payment from an ATM using a MCD, the method may comprise the steps of: i. sending a payment request from a MCD, wherein the payment request is for authorisation of a cash payment from the ATM to a user of the MCD; ii. receiving the payment request at a server; iii. authenticating the user's identity and creditworthiness at the server; iv. if both the user's identity and creditworthiness are authenticated, sending a confirmation message, which includes a confirmation code,

from the server; v. receiving the confirmation message at the MCD, alternatively at both the MCD and at the ATM; vi. entering the confirmation code into the ATM keypad; and vii. verifying that the confirmation code entered into the ATM keypad matches the confirmation code sent from the server and, if so, confirming that the cash payment may be made.

The alternative method for obtaining a cash payment from an ATM may further include the step of: viii. sending a transaction receipt to the MCD, alternatively to the ATM, further alternatively to both the MCD and the ATM, to record that the cash payment was concluded successfully.

The confirmation request may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms. Most preferably, the confirmation request takes the form of a USSD message.

The confirmation request may request information selected from the group consisting of: a PIN, a password, the value of the cash withdrawal, and any combination of these.

Most preferably, the confirmation request takes the form of a USSD message.

The confirmation message may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms. Most preferably, the confirmation request takes the form of a USSD message.

Most preferably, the confirmation message takes the form of a USSD message.

Preferably, the server is the server of the financial institution where the user holds an account.

According to a fourth aspect of the invention, there is provided a system for obtaining a cash payment from an ATM using a MCD, the system comprising: i. an ATM; ii. a MCD for communicating over a mobile communications network; and iii. a server, being adapted to receive a payment request from the MCD, wherein the payment request is for authorisation of a cash payment from the ATM to a user of the MCD, and wherein the server is programmed to authenticate the user's identity and creditworthiness; and, if both the user's identity and creditworthiness are authenticated, the server being further programmed to send a confirmation request to the MCD, wherein the confirmation request is to confirm that the cash payment is to be made; the server being further adapted to receive a confirmation message from the MCD and being further programmed to effect the cash payment on receiving the confirmation message from the MCD.

In an alternative embodiment of the invention, the system for obtaining a cash payment from an ATM using a MCD may comprise: i. an ATM; ii. a MCD for communicating over a mobile communications network; and iii. a server, being adapted to receive a payment request from the MCD, wherein the payment request is for authorisation of a cash payment

from the ATM to a user of the MCD, and wherein the server is programmed to authenticate the user's identity and creditworthiness; and, if both the user's identity and creditworthiness are authenticated, the server being further programmed to send a confirmation code to the MCD, alternatively to both the MCD and the ATM, wherein the confirmation code is to be entered into the ATM using the ATM keypad; the server being further programmed to verify whether the confirmation code entered into the ATM matches the confirmation code sent from the server and, if so, to confirm that the cash payment is to be made.

The server may be further programmed to send a transaction receipt to the MCD to record that the payment was concluded successfully.

Preferably, the server is the server of the financial institution where the user holds an account. In the event that the user wishes to obtain a cash payment from an ATM of a financial institution where the user does not hold an account, the method for drawing cash from an ATM may further include the step of: iA: routing the payment request to a server of the user's financial institution.

The confirmation request may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms. Most preferably, the confirmation request takes the form of a USSD message.

The confirmation request may request information selected from the group consisting of: a PIN, a password, the value of the transaction, and any combination of these.

The confirmation message may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms. Most preferably, the confirmation message takes the form of a USSD message.

According to a fifth aspect of the invention, there is provided a method for conducting a payment using a MCD, the method comprising the steps of: i. sending a preauthorisation request from a first MCD, wherein the preauthorisation request is for a preapprovai of the creditworthiness of an account holder of a financial institution; ii. receiving the preauthorisation request at the server of the financial institution; iii. authenticating the identity and the creditworthiness of the account holder; iv. if both the identity and the creditworthiness of the account holder are authenticated, sending a preauthorisation approval message from the server to the first MCD, wherein the preauthorisation approval message includes a preauthorisation code; v. receiving the preauthorisation approval message at the first MCD; vi. entering the preauthorisation code into a POS device of a vendor; vii. sending a confirmation request from the POS device to the server, wherein the confirmation request is to confirm whether the preauthorisation code entered into the POS device corresponds to the preauthorisation code included in the preauthorisation approval message; and, if so, viii. sending a confirmation message from the server to the POS device confirming that the purchase has been authorised.

The preauthorisation request may be for the preapprovai of the creditworthiness of the account holder for a transaction selected from the group consisting of: creditworthiness for a single transaction having a

predetermined maximum value, creditworthiness for multiple transactions having a predetermined, cumulative maximum value, creditworthiness for at least one transaction having a predetermined maximum value at a particular vendor, creditworthiness for at least one transaction having a predetermined maximum value at any one or more of a series of predetermined vendors.

The preauthorisation approval message may be sent from the server to the first MCD, alternatively from the server to a second MCD that may be identified by the user of the first MCD when sending the preauthorisation request.

The method for conducting a payment may further include the step of: requiring that each of the above steps be concluded successfully within a predetermined period of time, failing which the payment is automatically failed to be approved.

The method for conducting a payment may further include the step of: forwarding the preauthorisation code to the second MCD, permitting a user of the second MCD to conduct a payment using the second MCD, relying on the preauthorisation of the account holder's creditworthiness approval.

The preauthorisation code may be forwarded to the second MCD from the first MCD via a message from the list consisting of: a sms, a WAP message, a HTTPS message, and a USSD message.

Each of the preauthorisation request, preauthorisation approval message, confirmation request and confirmation message may take the form of a message selected from the group consisting of: a WAP message, a HTTPS message, a USSD message, and a sms.

According to an sixth aspect of the invention, there is provided a system for

conducting a payment using a MCD, the system comprising: i. a MCD for communicating over a mobile communications network; ii. a POS device; iii. a server of a financial institution, the server having receiving means for receiving a preauthorisation request from a MCD, wherein the preauthorisation request is for a preapproval of the creditworthiness of an account holder of a financial institution, and wherein the server is programmed to authenticate the identity and the creditworthiness of the account holder; the server further having transmitting means for transmitting a preauthorisation approval message to the MCD, if both the identity and the creditworthiness of the account holder are authenticated, which preauthorisation approval message includes a preauthorisation code; iv. entering means, associated with the POS device, for entering the preauthorisation code into the POS device; and v. transceiving means, associated with the POS device, for sending a confirmation request from the POS device to the server, wherein the confirmation request is to confirm whether the preauthorisation code entered into the POS device corresponds to the preauthorisation code included in the preauthorisation approval message, and if so, the transceiving means being further adapted to receive a confirmation message from the server, confirming that the purchase has been authorised.

The preauthorisation request may be for the preapproval of the creditworthiness of the account holder for a transaction selected from the group consisting of: creditworthiness for a single transaction having a predetermined maximum value, creditworthiness for multiple transactions having a predetermined, cumulative maximum value, creditworthiness for at least one transaction having a predetermined maximum value at a particular vendor, creditworthiness for at least one transaction having a predetermined

maximum value at any one or more of a series of predetermined vendors.

The preauthorisation approval message may be sent from the server to the first MCD, alternatively from the server to a second MCD that may be identified by the user of the first MCD when sending the preauthorisation request.

The entering means may be a keypad that is coupled to, alternatively associated with, the POS device.

Each of the preauthorisation request, preauthorisation approval message, confirmation request and confirmation message may take the form of a message selected from the group consisting of. a WAP message, a HTTPS message, a USSD message, and a sms.

Brief Description of the Drawings

In order to illustrate the invention, an embodiment thereof is described hereunder purely as an example, without limiting the scope of the invention, wherein:

Figure 1A is a schematic representation of a first embodiment of the system of the present invention;

Figure 1 B is a process flow diagram of a first embodiment of the method of the present invention, corresponding to the system depicted in figure 1A;

Figure 1C is a process flow diagram of a second embodiment of the method of the present invention, also corresponding to the system depicted in figure 1A;

Figure 2A is a schematic representation of a further embodiment of the system of the present invention;

Figure 2B is a schematic representation of a further embodiment of the method of the present invention, corresponding to the system depicted in figure 2A;

Figure 2C is a schematic representation of a further still embodiment of the method of the present invention, also corresponding to the system depicted in figure 2A;

Figure 3A is a schematic representation of a still further embodiment of the system of the present invention; and

Figure 3B is a schematic representation of a further still embodiment of the method of the present invention, corresponding to the system depicted in figure 3A.

Detailed Description of Drawings

A system and a method for conducting a payment using an MCD is indicated generally by reference numerals 5 and 10 respectively. A first embodiment of the invention, which is of a retail payment, is depicted in figures 1A, 1B and 1C. The system 5 is best depicted in figure 1A, while the method 10 is best depicted in figures 1 B and 1C.

As will be described in further detail below, the system 5 in this embodiment of the invention consists of: POS terminal 40 of a vendor 130 of goods or services, MCD 30 (in the form of a cellphone) belonging to a customer 20, and server 50 of the financial institution 110 of which the customer 20 is a

client. Both the MCD 30 and server 50 are capable of tranceiving messages over mobile communications network 100. Owing to the relationship between the system 5 and the method 10, it is convenient to discuss these two aspects of the invention together in the paragraphs that follow.

In all the embodiments of the invention that are described below, it is important to realise that the customer 20 will be required to pre-register to use the banking services described with his financial institution 110. When registering, the customer 20 will be able to select a default banking account against which payments will be made. In addition, on completing this registration, each customer's 20 default bank account will be associated uniquely by the financial institution 110 with that client's MCD 30 telephone number. The significance of this will be made clear in the descriptions below.

Typically, a customer 20 in a retail store 130 will bring his purchases to the checkout 300 to effect payment. There, a teller 60 will enter the customer's 20 MCD 30 telephone number into the POS terminal 40. This corresponds to steps i and ii of the method 10 respectively, as shown in figures 1 B and 1C. In step iii, the POS terminal 40 will then prompt the teller 60 to enter the amount of the transaction, as well as the telephone number of the MCD 30, which the teller 60 will then do in step iv. Known software will then be used to route the payment request 70 to a server 50 of the customer's 20 own financial institution 110. More specifically, the person skilled in the art will appreciate that, in each POS terminal 40, is a BIN Table, which is essentially a database in which a series of mobile phone numbers is stored and linked uniquely to a particular financial institution. [A customer 20 will be required to register with his banking institution 110 before he can use this invention. During that registration process, the client 20 will disclose his mobile telephone number to his financial institution, which will then attend to the storing of this number in the BIN table of each POS terminal 40].

In this way, each customer 20 is linked to his particular financial institution based only on his mobile phone number. Based on this information, the payment request 70 is routed to the server 50 of the relevant financial institution 110, and will not be routed to the server of any other financial institution at which the particular customer 20 does not hold a bank account.

Given the infrastructure that is most readily available in the industry today, it is envisaged, in one embodiment of the invention, that the payment request 70 is routed to the server 50 of the relevant financial institution 110 via a so- called IP hardwire, which takes the form of either a fixed landline or a radio network (referred to collectively and generally in the accompanying figures by reference numeral 400). It is also envisaged, however, that more sophisticated technology will be implemented in other embodiments of the invention, in which the payment request 70 is routed to the server 50 of the relevant financial institution 110 via cellular network 100.

At this stage, shown as step v, in a preferred embodiment of the invention, a payment request 70 is sent from the POS terminal 40 to the server 50, wherein the request is for the authorisation of payment from the customer 20 to the vendor 130. In the next step, namely step vi, the identity of the customer 20 is authenticated by the server 50 of the financial institution 110, based on the telephone number of the MCD 30 that was received in the payment request 70. This authentication is performed by comparing the data received in the payment request 70 against data that is stored in the financial institution's 110 own databases (not shown). Immediately thereafter, if the identity of the customer 20 is authenticated, in step vii the creditworthiness of the customer 20 is also assessed, to determine whether sufficient funds or credit are available in the customer's 20 account to satisfy the transaction value. Again, this assessment is made by checking the financial institution's 110 own records to check whether the customer's 20 account balance, alternatively available credit, is sufficient to cover payment for this particular transaction.

If both the customer's 20 identity and creditworthiness are authenticated, then a confirmation request 80 is sent from the server 50 to the MCD 30, wherein the confirmation request 80 is to confirm that the payment is to be made from the customer 20 to the vendor 130. This is depicted as step viii in figure 1 B. In a preferred embodiment, the confirmation request 80 will include a uniquely generated PIN that the customer 20 will be required to include in the next step (step ix), namely the sending of confirmation message 90. In this step, in order to confirm the request 80, the confirmation message 90 sent by the customer 20 from the MCD 30 to the server 50 will include not only the uniquely generated PIN, but also some other security identifier that is known only to the customer 20. In a preferred embodiment, this identifier will be a predetermined password that has been selected by the customer 20. It is also envisaged that, in other embodiments, the additional security feature will be the customer's 20 bank card PIN, ID number, or combinations

of these.

In practice, it is envisaged that the payment request 70, confirmation request 80 and the confirmation message 90 will ail be USSD messages, as USSD technology is session-oriented, and hence more efficient than, for example, sms-technology. It is also envisaged that, in other less-preferable embodiments, any one or more of the payment request 70, confirmation request 80 and/or the confirmation message 90 may be sms messages instead. Depending on the particular needs and infrastructure available to each particular banking institution, it is also specifically envisaged that HTTPS messages and/or WAP messages and/or combinations of these different forms of messages can also be used successfully in the operation of the invention. The type of message used will also vary depending on the particular type of MCD 30 used: for example, if MCD 30 is a PDA, HTTPS messages will be preferable, whereas if MCD 30 is a cellular phone, WAP messages and/or sms will be preferable.

The financial institution 110 will only authorise the payment request 70, and hence effect that payment, if each of steps iii, vii and ix had been completed (ie complied with) satisfactorily. Only once this is done will funds will be transferred from the account of the customer 20 to the account of the vendor 130. Once each of these steps has been completed, a confirmation message 120 is sent from the server 50 of the financial institution 110 to the POS terminal 40 in step x. Receipt of this confirmation message 120 on the POS terminal 40, in what is shown as step xi, informs the vendor 130 that the payment request 70 was authorised, and that the teller 60 may then print a receipt for the transaction (step xii) and release the goods to the customer 20, alternatively that the services have been paid for, as the case may be.

It will be noted that the method 10 was concluded successfully without the customer 20 having to produce a bank card or identity document at all,

making this a truly cardless transaction. Instead, according to the invention, the single piece of hardware that is required to effect the payment from the customer 20 to the vendor 130 is the customer's 20 MCD 30.

As an added security feature, many financial institutions add an additional element to the method 10 depicted in figure 1 B, namely a response time requirement. Essentially, this requirement requires that each of steps iii, vii and ix must be completed within a predetermined period of time (often in the range of 7 - 15 seconds). If each of these steps is not completed within that predetermined period, then the payment request 70 will be timed-out, and the process will have to be recommenced from start, if payment is to be authorised. As a consequence of this response time requirement, a further embodiment of the invention is illustrated in figure 1C. This embodiment is, essentially, a modification of the method 10 depicted in figure 1 B, and is described below. It will be seen that this modification is intended to reduce the time required to have a payment request 70 authorised, and hence ensure that the process is conducted from start to finish within the critical predetermined time period. This is done by performing more steps using the POS terminal 40, and fewer steps using the customer's 20 MCD 30.

More particularly, in figure 1C, each of the steps i - vii (inclusive) is conducted in identical fashion to the method 10 depicted in figure 1 B. However, at this point, the method 10 deviates. Specifically, at this point, in what is marked as step xiii, a confirmation request 80 is sent from the server 50 to the POS terminal 40 (and not to the MCD 30). This confirmation request 80 will prompt the teller 60 to input a PIN. At the same time, an authorisation message 140 is sent from the server 50 to the customer's 20 MCD 30 (this is marked as step xiv in figure 1 C). This authorisation message 140 includes a uniquely generated PIN, which is to be used for that particular once-off financial transaction. Typically, this authorisation message 140 will be in the form of a sms, and will include the uniquely generated PIN as well

as an additional security feature, and some other security identifier that is known only to the customer 20, such as a predetermined password that has been selected by the customer 20, the customer's 20 bank card PIN, ID number, or combinations of these, as described above.

Next, in step xv, the teller 60 will hand the customer 20 a PIN pad (not depicted) into which the required PIN will need to be entered in step xvi. Then, in step xvii, a validation message 150 is sent from the POS terminal 40 to the server 50, where the PIN entered by the customer 20 is compared against the PIN stored with the authorisation entry in step xiv. The validation message 140, typically, will be a USSD message, although in other embodiments it may be a sms, WAP message or HTTPS message If these PINs correspond, and if the additional security data in the validation message 150 is verified, then the payment request 70 will be authorised, and funds will be transferred from the account of the customer 20 to the account of the vendor 130.

Furthermore, once each of these steps has been completed, steps x - xii depicted in figure 1B are carried out here, namely: a confirmation message 120 is sent from the server 50 of the financial institution 110 to the POS terminal 40 in step x. Receipt of this confirmation message 120 on the POS terminal 40, in step xi, informs the vendor 130 that the payment request 70 was authorised, and that the teller 60 may then print a receipt for the transaction (step xii) and release the goods to the customer 20, alternatively that the services have been paid for, as the case may be.

It will be appreciated that, in the case of both figures 1 B and 1 C, the payment request 70 will not be authorised, and the method 10 for conducting the payment will be terminated if any of the following events occur: ^■ if any one of steps vi, vii or ix (in the case of 1 B), or steps vi, vii or xvii (in the case of 1C) are not concluded successfully; and/or

^■ if all of the steps (in either case 1 B or 1C) are not concluded within the predetermined time period.

If any of the steps mentioned above fail to be executed successfully, an error message (not shown) will be sent from the server 50 to the MCD 30 and the POS terminal 40, advising that the payment request 70 could not be completed, and was not authorised. Should any of these conditions occur and the method 10 be terminated, the process will have to be recommenced from step i.

Figures 2A - 2C depict yet further embodiments of the invention. The system 5 and method 10 depicted, respectively, in these figures demonstrates the application of the present invention to the making of a cash withdrawal from an ATM without the use of a bank card. In order to describe this embodiment of the invention, it is important to note that every ATM has a unique code assigned to it. That unique code is displayed on the face of each ATM for ease of identification.

A customer 20 wishing to make a cash withdrawal approaches an ATM 170 (indicated as step xxx in figure 2B). Instead of inserting a bank card into the

ATM 170, the customer 20 instead dials a predetermined number from his

MCD 30, which is depicted here as a cellphone (step xxxi). This call is placed through to the server 50 of the financial institution 110 where the customer

20 holds a bank account, and the customer 20 is logged on the server 50 after being identified (step xxxii). At this point, the customer 20 will select the cash withdrawal option in a baking programme menu that is presented to him

(not shown).

It will also be appreciated by a person skilled in the art that the customer 20 can log on to the banking programme through the sending of a sms from his

MCD 30 instead of via the dialing of a predetermined number from his MCD

30.

A prompt 180 is sent from the server 50 to the MCD 30 in step xxxiii, which prompt 180 requests the customer 20 to enter the unique ATM code that is assigned to that particular ATM 170. The customer 20 enters that unique code into his MCD 30, and sends a prompt response 190 to the server 50, which prompt response 190 includes that ATM code (step xxxiv). Receipt of this information in the prompt response 190 in step xliv now associates a particular customer with a particular ATM.

As a variation of this step xxxiv, it is envisaged that GPS technology might be utilised to triangulate the coordinates of the customer 20, and assign that location uniquely to a particular ATM.

At this point, in step xxxv, a verification request 200 is sent from the server 50 to the MCD 30, requesting that the customer 20 to enter his bank PIN. The customer 20 does so, in step xxxvi, by sending a verification message 210 from his MCD 30 to the server 50, which message 210 includes the requested PIN.

The PIN is then verified at the server 50. If and when it is verified (step xxxvii), a transaction request 220 is sent from the server 50 to the MCD 30, requesting the customer 20 to select a particular transaction from a given menu (step xxxviii). Transactions on that menu include an option to make a cash withdrawal, along with other banking transactions, such as transferring funds between accounts, purchasing airtime, et cetera. The customer 20 will then respond, in step xxxix, by sending a transaction message 230 from his MCD 30 to the server 50, which transaction message 230 will select, in this case, a request to withdraw cash from the ATM 170, and will specify the amount requested.

In a preferred embodiment of the invention, each of the prompt 180, prompt response 190, verification request 200, verification message 210, transaction request 220 and transaction message 230 will be a USSD message, although in other embodiments it is expressly envisaged that some or all of these may be a sms, WAP message or HTTPS message

On receipt of the transaction message 230, a verification of the customer's 20 creditworthiness will be performed through the database(s) (not shown) of the server 50 in step xl, in order to determine whether the customer 20 has sufficient funds, alternatively sufficient credit, to support the transaction. If this is the case, then in step xli, a command prompt 240 will be sent from the server 50 to the ATM 170, instructing the ATM 170 to release a cash payment in the amount requested. Simultaneously, a confirmation message 320 will be sent from the server 50 to the MCD 30, confirming that the request for a cash withdrawal was authorised (also indicated as step xli).

For security reasons, during the period in which each steps xxx - xli is conducted, the ATM keypad 420 is locked, meaning that no other person can operate the ATM (by inserting a bard card therein and conducting a financial transaction). Only when the customer 20 has completed his financial transaction will the ATM be available for use to another person.

A further embodiment of the invention, being a modification of the above method, is depicted in Figure 2C. More particularly, it will be noted that steps xxx - xl in figure 2C correspond identically to the same steps depicted in figure 2B. However, after step xl (verification of the customer's 20 creditworthiness) in the embodiment depicted in figure 2C, confirmation message 410 is sent from the server 50 to both the MCD 30 at to the ATM 170 (this is depicted as step c in figure 2C). The confirmation message 410 includes a confirmation code, which is preferably a uniquely generated mobile PIN (MOPIN). In a preferred embodiment, the confirmation message

410 sent from the server 50 to the MCD 30 of customer 20 takes the form of either a sms or a WAP message.

At this point, in step c/, the ATM keypad 420 is unlocked and the customer 20 will enter the confirmation code into ATM 170, using the ATM keypad 420.

The confirmation code that is entered will be verified against the confirmation code that was received at the ATM 170 in the confirmation message 410 in step c. This confirmation process occurs at the ATM 170 itself. If these confirmation codes correspond , then in step cii the ATM 170 will release cash in the amount that was authorised in the particular transaction.

It will be appreciated by the person skilled in the art that the response time requirement that is discussed above in the context of the invention as depicted in figures 1 A and 1 B, may be applied, equally, to the embodiments of the invention that are depicted in figures 2A - 2C. More specifically, it is envisaged that, if a customer 20 has not concluded each of steps xxx - xli (in the case of figure 2B), or each of steps xxx - cii (in the case of figure 2C), then the payment request will be timed-out, and the process will have to be recommenced from start, if payment is to be authorised.

It will be appreciated, further, that, in this fashion, a customer 20 will be able to make a cash withdrawal from an ATM without having to enter any of his bank card details into the ATM 170 terminal using the keypad of the ATM 170. In fact, this transaction is accomplished without referring to any bank card at all, making this a truly cardless transaction.

If any of the steps mentioned above fail to be executed successfully, an error message (not shown) will be sent from the server 50 to the MCD 30, advising that the payment request could not be completed, and was not authorised.

Figures 3A and 3B depict yet further embodiments of the invention. The

system 5 and method 10 depicted, respectively, in these figures demonstrates the application of a preauthorisation element to the present invention. The similarities of this embodiment of the invention to that depicted in figures 1A and 1 B will be readily apparent. According to this embodiment of the invention, in step ex the account holder 20 will use his MCD 30 to send a preauthorisation request 430 to the server 50 of his financial institution 110. It is clear that the account holder 20 need not necessarily be at the vendor's 130 checkout point 300 when sending the preauthorisation request 430.

It is envisaged that the preauthorisation request 430 will be a request for any number of financial transactions, with any number of qualifications. Examples of the most common financial transactions and qualifications include the following: i. preauthorisation for a single transaction having a predetermined maximum value; ii. preauthorisation for multiple transactions having a predetermined, cumulative maximum value; iii. preauthorisation for at least one transaction having a predetermined maximum value at a particular vendor; and iv. preauthorisation for at least one transaction having a predetermined maximum value at any one or more of a series of predetermined vendors.

On receipt of the preauthorisation request 430 at the server 50, the identity and the creditworthiness of the account holder 20 are authenticated in steps cxi and cxii respectively. In step cxiii, if both the identity and the creditworthiness of the account holder are authenticated, a preauthorisation approval message 440 is sent from the server 50 to the MCD 30 of the account holder 20, wherein the preauthorisation approval message includes a preauthorisation code (not shown). Preferably, the preauthorisation code is a unique, once-off PIN that is generated by the server 50, and is known

conventionally in the trade as a modible PIN, or MOPIN. This is generally regarded as the most secure, and hence the preferred, preauthorisation code. However, it is also envisaged that, in another embodiment of the invention, the preauthorisation code will be a PIN that has been preselected by the account holder 20.

At this point, there are two options available to the account holder 20: either he may elect to use this preauthorised credit to make a purchase himself (Option A), or he may elect to transfer the credit preauthorisation to the MCD 460 of another person 450, which would allow that other person 450 to use this preauthorised credit to make a purchase (Option B). Option A is depicted in figure 3B in steps cxiv - cxix, while Option B is depicted in figure 3B in steps cxx and cxiv- cxix.

In the event that Option A is selected: the account holder 20 will proceed to the vendor 130 of choice, and select the goods and/or services for which payment is to be made (step cxiv). When at the checkout 300 of the vendor 130, the account holder 20 elects to pay for his purchases using his MCD 30, and advises the teller 60 that he has already obtained preauthorisation. The account holder 20 will then be asked to enter the preauthorisation code into the POS device 40 of the vendor 130 (step cxv), using the keypad (not shown) of the POS device 40. At this point, in step cxvi, a confirmation request 470 is sent from the POS device 40 to the server 50, wherein the confirmation request 470 is to confirm whether the preauthorisation code entered into the POS device 40 corresponds to the preauthorisation code included in the preauthorisation approval message 440. This confirmation is performed in step cxvii.

If this is confirmed, a confirmation message 480 is sent from the server 50 to the POS device 40 (step cxviii). This informs the vendor 130 that the payment request 70 was authorised, and that the teller 60 may then print a

receipt for the transaction (step cx/x) and release the goods to the account holder 20, alternatively that the services have been paid for, as the case may be.

In the event that Option B is selected: after the successful completion of step cxiii, the account holder 20 will send a sms from his MCD 30 to the MCD 460 of a recipient 450 (depicted as step cxx). This sms will include preauthorisation code, which will enable the recipient 450 to utilise the preauthorised credit that was confirmed in the confirmation message 410. More specifically, receipt of this sms will enable the recipient to proceed to the premises of a vendor or vendors of choice, and make a payment in the identical fashion as described in steps cxiv- cxix above.

It will be appreciated by the person skilled in the art that the POS device 40 communicates with the server 50 of the financial institution 110 via, for example, a fixed landline telecommunications network, a mobile telecommunications network, or a radio network, which enables communication of the confirmation request 470 and the confirmation message 480 between the server 50 and the POS device 40.

As an alternative to step cxx, in an alternative embodiment, the account holder 20 may elect (when requesting preauthorisation in step ex) that the preauthorisation code be sent directly to the MCD 460 of the recipient 450.

As was mentioned above, many combinations of financial transactions and qualifications are possible using this method. So, for example, a parent (who is an account holder 20) may obtain preauthorised credit up to a certain amount, which the parent may transfer to their child (recipient 450). Alternatively, the parent may obtain preauthorised credit, up to a certain amount, and which is to be transferred to their child, but with the qualification that the credit may be used only at certain vendors. Countless other

combinations abound.

In the examples provided above, each of the preauthorisation request, preauthorisation approval message, confirmation request and confirmation message takes the form of a USSD message. It is envisaged, however, that in other embodiments of the invention, each of these requests and messages may also take the form of: a WAP message, a HTTPS message, and a sms.

Furthermore, as an added security feature, many financial institutions add an additional element to the method 10 depicted in figure 3B, namely a response time requirement. Essentially, this requirement requires that each of the steps in the method must be completed within a predetermined period of time. If each of these steps is not completed within that predetermined period, then the preauthorisation request 430 will be timed-out, and the preauthorised creditworthiness will be cancelled, effectively rendering the preauthorisation code useless. The process will then have to be recommenced from start by the account holder 20.

It will be appreciated, too, that numerous other embodiments of the invention may be performed without departing from the scope of the invention as defined in the consistory statements above.