GB2389693A

GB2389693A - Payment systems

Info

Publication number: GB2389693A
Application number: GB0213265A
Authority: GB
Inventors: James Ballantyne; Virginia Kate Pitts
Original assignee: Consignia PLC
Current assignee: Royal Mail Group Ltd
Priority date: 2002-06-10
Filing date: 2002-06-10
Publication date: 2003-12-17
Also published as: GB0213265D0

Abstract

A payment system comprising: means (30, 100, 190) for generating a unique identifier representative of a cash amount in response to customer payment; means (70; 230) for transmitting said generated identifier to a customer mobile terminal (1); means (60; 220) for storing said generated identifier in a central data repository; means (80; 230) for receiving a said identifier transmitted from a customer mobile terminal (1), said identifier being tendered by the customer as at least part payment for goods or services; means (50; 210) for comparing at least a portion of a tendered identifier with at least a portion of generated identifiers previously stored in said central data repository; and means (50; 210) for indicating said tendered identifier to be valid if at least a portion of said tendered identifier matches at least a portion of a generated identifier previously stored in said central data repository. Preferably, the system uses a vendor terminal and merchant terminal, both with messaging facilities, a central validation terminal and a mobile phone with the identifiers passed by SMS messaging. Preferably, the identifier is in code which can be random numbers or characters, can include the cash amount, be time related and preferably uses a one-time pad for generating the code.

Description

( PAYMENT SYSTEM

FIELD OF TI[E INVENTION

This invention relates to payment systems. Particularly preferred 5 embodiments of the invention relate to payment systems utilising a mobile terminal, such as a mobile phone.

BACKGROUND TO THE INVENTION

Many payment systems are available at present, including credit and debit card based systems. These systems are convenient and easy for 10 customers to use and allow them to pay for goods and services either at a merchant terminal or cash desk in a shop, or equally over the telephone or intemet. In addition to well established payment systems, a number of new systems are emerging, some of which relate to internet and digital payment 15 services and others that are for more general use. One example is "Digicash", which is a system for paying for goods and services on the internet that employs an encrypted token. In this system, the buyer and seller are linked directly for a Digicash transaction. Settlement is a complex arrangement where the Digicash service owner, who is paid by the customer using a credit 20 or debit card or any other conventional payment transaction, reimburses the seller. An anticipated problem with Digicash, however, is that only a small number of consumers will use the service. This is due to the widely held public perception that Internet based transactions are inherently insecure.

25 This perception is based, in the main, on the assumption that it is generally possible to crack any practical cipher code given adequate time and resources.

Un-crackable codes are of course possible, but suffer from disadvantages that make them unusable for practical applications. A further disadvantage is that the Digicash system is dependent on the customer having some fonn of bank 30 or credit card account. Many people, however, do not have access to this type

of facility and so are excluded from using this system. A further disadvantage of the Digicash system is that it requires a user to identify themselves to both the seller and the Digicash service owner. As a consequence, the anonymity characteristic of traditional cash transactions is not available to a Digicash 5 user. An alternative system that is at a relatively early stage of development is known as Mondex, in which a smart card is loaded with encrypted information from an owner's bank account and represents a cash amount. The owner can then use the Mondex smart card bearing the information as if it 10 were cash, at retail outlets that have card readers capable of reading the Mondex card.

Early indications suggested that the Mondex system could be moderately successful. However, a significant disadvantage is that the Mondex system is dependent on the customer having some form of bank or 15 credit card account uptake of the sytem has been very slow. However, as noted above, many people do not have access to these. A further problem with this Mondex system is that a user must register with the system, and thus the anonymity provided by traditional cash transactions is not available.

Further there is a requirement to modify or to replace all point of sale 20 terminals to make the system useable.

United Kingdom Patent Application No. 2252270 discloses another payment system that employs a card that is provided with two interrelated numbers. A central terminal is arranged to validate the numbers and hence the card, and to maintain a record of the amount of credit purchased with the 25 card. Whilst this system does not require a user to register with the central terminal, the opportunity is there for the central terminal to acquire other information, such as telephone numbers dialled by a user of the card, and thus the anonymity provided by a traditional cash transaction could be compromised. A further problem associated with this system is that a 30 practical implementation will require the providers of the system to manufacture and distribute large numbers of cards.

An aim of the present invention is to provide a system which avoids' or at least mitigates, the above mentioned problems. A particularly preferred aim of the invention is to provide a payment system which affords the anonymity of traditional cash transactions without requiring a user to 5 physically present cash to a merchant.

STATEMENT OF THE INVENTION

In pursuit of this aim, one embodiment of the invention provides a payment system comprising: means for generating a unique identifier representative of a cash amount in response to customer payment; means for 10 transmitting said generated identifier to a customer mobile terminal; means for storing said generated identifier in a central data repository; means for receiving an identifier transmitted from a customer mobile terminal, said identifier being tendered by the customer as at least part payment for goods or services; means for comparing a tendered identifier with generated identifiers 15 previously stored in said central data repository; and means for indicating said tendered identifier to be valid if said tendered identifier matches a generated identifier previously stored in said central data repository.

A principal advantage of this system is that it is open for use by all customers who have access to a mobile terminal, such as a mobile telephone 20 or personal digital assistant with telephonic capabilities. With the advent of so-called "pay as you go" mobile telephones it is no longer necessary for a purchaser of a telephone, for example, to have a bank account or other charge card to which subscription and call charges can be posted, and thus the payment system of the invention is open for use by those persons who cannot, 25 or do not want to, have a bank account or charge card. The system can be employed in face-to-face transactions or in transactions accomplished over the telephone or over the Internet.

Preferred features of this embodiment, and other embodiments of the invention, are set out in the accompanying claims. Advantages of those 30 features and embodiments wild be apparent from the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of the invention will now be described, by way of illustrative example only, with reference to the following drawings, in which: Fig. I is a schematic representation of a customer mobile terminal; Fig. 2 is a schematic representation of the key components of the 5 terminal of Fig. 1; Fig. 3 is a schematic representation of a payment system; Fig. 4 is a schematic representation of the key components of a merchant or vendor terminal; Fig. 5 is a schematic representation of another payment system; and 10 Fig. 6 is a flow diagram illustrating a process of validating a unique identifier. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Various embodiments of the invention will now be described in detail with reference to a customer mobile terminal which comprises a mobile 15 telephone of the kind shown in Fig. 1 of the accompanying drawings.

However, it will be appreciated - and should be noted - that the teachings of the present invention are equally applicable to any mobile communications terminal (such as a mobile telephone, or a portable digital assistant (PDA) or portable computing device (such as a laptop computer) with telephonic 20 capabilities). As a consequence, the following description should not be read

as limiting the scope of the present invention in any way.

CUSTOMER MOBILE TERMINAL

As shown in Fig, 1, the customer terminal 1 comprises a display 3, an aerial 5 and a plurality of keys 9 arranged in a keypad. The keys, as is known 25 in the art, can be arranged as so-called hard keys with one predetermined function or alternatively they can be arranged as soft-keys which have a plurality of functions depending on the particular operating mode of the terminal. The terminal I is provided with a microphone 11 and a loudspeaker 13 for input of user speech and generation of audio signals for relaying to a 30 user. An infra-red input/output port 12 is also provided to permit infrared optical data signals to be received from and/or transmitted to other mobile or

fixed terminals which are also equipped with an appropriate port.

Figure 2 is a schematic representation of key components of the terminal shown in Figure 1. As shown the terminal I includes a central control unit or processor 15 that is, at least in general terms, operable to 5 control operation of the terminal. Coupled to the processor 15 is a radio unit 17 and timing control circuitry 19 that together are operable to control the transmission and reception of telecommunications signals to and from other telecommunications terminals or from telecommunications networks to which the terminal can connect via the aerial 5.

10 A removable data storage device or subscriber identity module (SIM) 29 is provided for data and program storage. The data will usually comprise the IMSI (which uniquely identifies the telephone), and other information such as a set of telephone numbers stored on the phone by the user. Sofhvare programs may also be stored on the SIM as part of the so-called SIM toolkit I 5 (or SIM application toolkit as it is otherwise known).

Coupled to the processor 15 is the display 3, and signals can be sent from the processor 15 to the display in order to convey messages, instructions, and other information to a user of the terminal. The processor is also coupled to the keypad 9 for data input by a user to the terminal.

20 Sound (for example user speech) picked up by the microphone 11 is processed by a speech processor 21 (for example to remove nontransmittable frequencies), and a coder/decoder (CODEC) 23 that is operable to convert analogue signals generated by the microphone 11 into digital data for subsequent processing. The speech processor 21 and CODEC 23 are also 25 operable to process received digital data and convert it into appropriate audio signals for relaying to a user by means of the loudspeaker 13.

Also coupled to the processor 15 is a ring generator 25 which is operable to generate one of a variety of different alerts which are used to alert a user of the terminal as to when a call, a message or other information is 30 received at the terminal 1. In this particular case the ring generator is operable to generate appropriate signals to drive a vibrating buzzer 27, to

illuminate an LED 28 (or bank of illumination devices) or to generate a ring signal for relay to the user via the loudspeaker 13. Typically, a user of the terminal is able to select which of these alert options are most preferable for their current ambient environment. For example, a user who is at work and 5 does not want to disturb his or her colleagues with an audible ring tone might choose the vibrating buzzer as an alternative means to alert them to an arriving call at the terminal.

In addition to normal voice communications, it is known to enable terminals - such as that shown in Figs. I and 2 - to communicate by means of 10 short messages known in the art as short messaging service (SMS) messages.

To send messages by means of this service, a customer enters text into the terminal by means of the keypad 9. Typically, any one key of the keypad 9 is assigned to a number of alphanumeric characters that a customer can step through by repeatedly pressing the key until the character they wish to include 15 in the message is displayed. Once the message has been completed, the customer types in the telephone number of the destination terminal for the message and then instructs the terminal to send the message to that destination terminal. Once the terminal has been instructed to send the message, the processor communicates with stations of the mobile telephone network and 20 transmits the message. In a similar fashion, messages can be received at a mobile terminal, and subsequently displayed to a customer on the display 5.

Received messages, and messages saved before or after transmission, can be stored in the memory of the process or in the removable data storage device or SIM. 25 PAYMENT SYSTEM-FIRST EMBODIMENT

Fig. 3 is a schematic illustration of a first embodiment of the system of the invention. The system of this embodiment comprises a vendor terminal 30, a merchant tenninal 40, a validation terminal 50 and a central data repository 60. Each of the vendor terminal 30 and the merchant terminal 40 30 are associated with a messaging facility 70, 80 respectively.

As a minimum, the vendor terminal messaging facility 70 is capable of

( transmitting messages to a customer mobile terminal and the merchant terminal messaging facility 80 is capable of receiving messages from a customer mobile terminal. As an option, the messaging facilities 70, 80 could be configured to transmit and receive messages to and from a customer 5 mobile terminal.

In this and other preferred embodiments, the messaging facilities 70, 80 each comprise an SMS messaging facility which is adapted to transmit and/or receive (as required) SMS messages to andlor from a customer mobile terminal 1. As an alternative, the messaging facility could instead (or 10 additionally) be configured to transmit and/or receive other types of message, such as for example so-called MMS (multimedia messaging service) or E SMS (enhanced short messaging service) messages.

As will later be described, the vendor and merchant terminals 30, 40 are similar to one another and are, in effect, modified cash registers. The 15 validation terminal comprises a computing resource with a processor that is operable to search through identifiers stored in the central data repository.

Similarly, the central data repository comprises a computing resource which is programmed to establish and maintain a database of stored identifiers.

Fig. 4 is a schematic illustrative representation of the key components 20 of just such a terminal. As shown, the terminal 30, 40, comprises a display 90, a processor 100 and associated memory 160,, a cash till 110, an accounting unit 120 and input means 130 (such as a keyboard and/or bar code reader). These components are connected to one another, and to an inpuVoutput interface 140, by means of a databus 150. As will be appreciated 25 by those skilled in the art, the features of the terminal 30, 40 are entirely conventional, and thus will not be further described herein.

To use the payment system, a customer carrying a mobile terminal 1 in this example a mobile phone - must first purchase credit at a vendor terminal 30. When the customer advises a vendor that he wants to make a 30 purchase of credit, the vendor enters the purchase price of the credit into the vendor terminal 30 by means of the input means 130, and the inputted

! purchase price is displayed on the display 90. Once the customer confirms that they wish to proceed with the purchase, and tenders an appropriate payment the processor 100 takes steps to receive that payment (which may be to open the cash till if cash is tendered by the customer), and the accounting 5 unit 120 is indexed to indicate that a sale has taken place for which payment has been received.

The processor then prompts the vendor to ask the customer for their mobile terminal number and once the number has been inputted, the processor 100 generates - in a manner to be later described - a unique identifier and 10 sends it by way of the data bus 150 and input/output interface 140 to the messaging facility 70 associated with the vendor terminal 30. On receipt of the identifier from the processor 100, the messaging facility 70 configures the identifier as an SMS message and transmits it to the mobile terminal number inputted earlier. In this example, the messaging facility 70 could comprise a 15 mobile telephone which is programmed, for example by means of software resident on the SIM, to receive data from the vendor terminal 30, reconfigure the data as an SMS message, and transmit the message to a specified telephone number. The processor also sends the generated unique identifier via a data link 170 (which may be a wireless link, or a wired link such as the 20 Public Ordinary Telephone System (POTS)) to the central data repository 60 where it is stored along with other unique identifiers generated by other vendor terminals.

On receipt of the SMS message from the messaging facility 70, the customer mobile terminal I stores the message (for example in the memory 25 associated with the terminal processor, or in the SIM) for later recall. As will be later described, a component of the unique identifier indicates the amount of credit purchased by the customer, and this credit is available to the customer for use in the purchase of goods or services provided by a merchant.

In effect, the SMS message stored in the customer terminal represents a cash 30 amount equivalent to the amount of credit purchased by the customer.

When the customer wishes to make a purchase of goods or services

( from a merchant, they advise the merchant that they wish to make a purchase, and that they wish to effect payment, at least in part, by means of the SMS message stored on their terminal.

The merchant enters the sale price of the goods or services into the 5 merchant terminal 40 by means of the input means 130, and the sale price is displayed on the merchant terminal display 90. The merchant then advises the customer of the telephone number allocated to the messaging facility 80 associated with the merchant terminal 40, and the customer transmits the previously stored SMS message to the number provided by the merchant.

10 On receipt of the message from the terminal, the merchant terminal messaging facility extracts the unique identifier from the message and transmits it by way of the input/output interface 140 and databus 150 to the processor 90 for temporary storage in the memory 160 associated with the processor 90. The processor then transmits the unique identifier via a data 15 link 180 (which again can be a wired or wireless link) to the validation terminal 50.

On receipt of the unique identifier, the validation terminal 50 looks through the list of identifiers held in the central data repository 60 to determine whether the identifier forwarded by the processor 90 matches one 20 of the identifiers previously stored in the data repository 60. If a match is found, then the validation terminal determines the identifier to be valid, generates a "valid" signal, transmits the signal to the merchant terminal 40 by way of the data link 180, and instructs the data repository to delete that identifier from its records. If no match is found the validation terminal 25 generates an "invalid" signal, and transmits it to the merchant terminal 40.

On receipt of a 'valid" signal from the validation terminal 50, the merchant terminal processor 100 indicates this to the merchant by means of the display 90, and extracts the amount of credit purchased by the customer from the identifier. The processor then calculates, from the amount of credit, 30 any excess or shortfall in the amount of credit as compared with the purchase price of the goods or services. In the event that the credit purchased by the

( customer is less than the purchase price, the processor prompts the merchant to ask for further payment from the customer. Giving the customer change in cash from the merchant terminal cash till l 10 can rectify an excess of credit as compared with the purchase price. Once payment has been effected, the details of the transaction are stored in the merchant terminal accounting unit 120. In the event that an invalid signal is returned from the validation terminal, the merchant terminal processor 100 indicates this to the merchant by means of the display 90, and the merchant is prompted not to accept the 10 SMS message from the customer as payment for the goods or services in question. PAYMENT SYSTEM- SECOND EMBODIMENT

Fig. 5 illustrates a modification of the embodiment described above with reference to Fig. 3. As shown in Fig 5, the system of this embodiment 15 composes a vendor terminal 190, a merchant terminal 200, a validation terminal 210 and a central data repository 220. The central data repository is similar to that described above in relation to the embodiment shown in Fig. 3.

The vendor and merchant terminals 190, 200, are similar to those described above with reference to Fig. 3 and Fig. 4 apart from the fact that 20 they no longer communicate with a separate messaging facility, but instead communicate with a validation terminal 210 that has a messaging facility 230 as a component thereof.

This embodiment of the invention operates in a similar way to that described in relation to Fig. 3. The only significant difference is that unique 25 identifiers are sent out to customer terminals by messaging facility 230 of the validation terminal 210 rather than by dedicated vendor terminal messaging facilities. Similarly, in this embodiment messages are sent from customer mobile terminals direct to the messaging facility 230 of the validation terminal 210, rather than to messaging facilities associated with the merchant 30 terminals. Other than in this respect, the system of this embodiment operates in the same way as the embodiment of Fig. 3, and hence will not be further

described herein.

A chief advantage of the embodiment shown in Fig. 5, as compared to the embodiment shown in Fig. 3, is that the amount of hardware required to implement the system is significantly reduced. Specifically, in the second 5 embodiment it is not necessary to provide each merchant and vendor terminal with a messaging facility. Typically all that will be required to implement the system is for the merchant and vendor terminals to be reprogrammed to accept payment by means of messages transmitted from a customer mobile terminal. This reduction in hardware makes the system more attractive to the 10 vendor and merchant, as well as reducing the amount of time required (and hence the cost) for installation.

The system shown in Fig. 5 could further be modified so that the generation of unique numbers is undertaken by the validation terminal, rather than by the vendor terminal. The unique numbers can be generated at the time 15 of purchase for exact amounts of money or can be pregenerated in specific denominations of credit amounts associated with specific unique numbers.

Such a modification would be advantageous since it would cut-down yet further on the modifications required to enable the vendor terminal to be employed in the system.

20 GENERATION OF THE UNIQUE IDENTIFIER

It will be appreciated by those persons skilled in the art that a variety of different mechanisms may be employed to generate a unique identifier for implementing the teachings of the invention. Several different mechanisms will now be described by way of example only, but the scope of the invention 25 should not be read as being limited to any one or more of them.

It is generally anticipated that embodiments of the invention will tend to be employed for relatively low value transactions, and the first mechanism to be described is provided on the basis that any one identifier will probably not be of any great value, and thus not worthwhile protecting to any greater 30 extent than one would protect cash held in a personal purse or wallet.

In this first mechanism, therefore, the vendor terminals are simply

( arranged to generate an identifier comprised of a random number, or a random string of alphanumeric characters. Each random number or random string of alphanumeric characters is appended to a code that identifies the credit purchased by the customer (i.e. the cash value of the identifier), and a code 5 that uniquely identifies the vendor terminal from which the identifier is purchased so that the same identifier cannot be generated by two or more different terminals.

As an SMS message can contain a maximum of 160 characters, the risk of any one terminal generating identical random numbers or identical 10 strings of alphanumeric characters which are both valid at the same time is considered to be so small as to be practically insignificant, and as a consequence it is considered that there is no need to take steps to reduce the chance of this happening. Nevertheless, if it is desired to provide an even more robust system, then the identifier could also include a further code 15 indicating, for example, the time at which the purchase of the identifier is concluded. As an illustrative example, the identifier could comprise a string of 160 characters, where the first five characters indicate the cash value of the identifier, the next twenty characters are uniquely assigned to a specific 20 vendor tenninal, the next one hundred and twenty-nine characters comprise a randomly generated number or string of alphanumeric characters, and the last six characters comprise the time at which the purchase of the identifier was concluded. Given that purchased identifiers will tend to be used relatively quickly, 25 it is considered that this mechanism would provide a workable means of implementing the teachings of the invention.

Such a mechanism would, of course, be open to abuse by third parties who were prepared to invest sufficient time and resources to try every combination and permutation of each of the above mentioned characters for a 30 given tenninal vendor identifier. However, as it is anticipated that embodiments of the invention will tend to be employed for relatively low

value transactions, it is unlikely that the benefits to be accrued would make such attack attractive.

To reduce the attractiveness of such an attack yet further, an alternative more secure mechanism could instead be employed to generate the 5 unique identifier. In this second mechanism, each unique identifier comprises a number that is generated at random, and is appended to a code that is indicative of the cash value of the identifier and a code that uniquely identifies the vendor terminal from which the identifier is purchased.

The unique identifier also includes a validation number which can be 10 used to validate the randomly generated number. The validation number is typically generated using the randomly generated number as a cipher seed.

For example, the validation number can be generated using a one-time pad.

In this method, the coding is only ever used once so that even if an attack were made and the code cracked it is of no use as it is not used again. This 15 method is well known and described in an article titled "Cipher Printing Telegraph Systems for Secret Wire and Radio Telegraphic Communications" by J. Amer, Inst. Elec. Eng., vol. 45. Pages 109-115, 1926.

In order to use a one time pad for encoding a message the key code must be at least as long as, and preferably longer than the message. For 20 example, if a one time pad of 1 3 5 2 17 5 9 10 8 20 1 6 were used to code a message "TORATORATORA", the alphabet would be stepped through as follows: To T add I to get the next letter in the alphabet to become U. To O step forward 3 letters in the alphabet to get R and so on.

25 The resulting coded message is "URWCKTAKBISG", with the original and the coded message being related only through the one time pad.

Provided that a copy of the pad is available, uncovering the original message is simply a matter of subtracting the pad numbers to find the original letters.

However, in the absence of the pad, it is not possible to decode the message.

30 In order to construct a series of one time pads, there are certain mathematical rules that should be followed:

1. Each pad must have more bits that that of a character, e.g. at least 8 bits for ASCII.

2. Each pad must be completely different from the ones before it.

3. Each pad should be a function of a single changing variable that 5 authorised parties can keep track of.

Using module arithmetic these characteristics can be satisfied. For example, using the "mod" allows a one time pad to operate as follows: If p and q are constants, prime and of size larger than 8 bits, the following equation can be used: pad=pmodq, where n is nth character of the message. 10 To avoid pads of 0's, p must be larger than q, otherwise pad=pmodq-0.

Similarly, n should not be set to 0. If these rules are met, a pseudo random number is generated having bits that can be either added or subtracted, (or any other function performed) on each character of the message. If exclusive OR (XOR- 63) is used, the number of bits remains the same and the repetition of 15 the XOR give the original message, i.e A 0 B=C, C ffl BE A. Thus, msg Pad = cyphsmg and cyphrnsg 63 pad = msg. This particular method of encryption is called a hash algorithm, where two elements are combined to form a third unique element.

In the present example, the "message" to be coded using a one time 20 pad is the randomly generated number, and the resultant coded message is then used as the unique validation number.

As an illustrative example, the identifier could comprise a string of 160 characters, where the first five characters indicate the cash value of the identifier, the next twenty characters identify the terminal from which the 25 identifier was purchased, and the last six digits comprise the time at which the purchase of the identifier was concluded. The remaining one hundred and twenty-nine characters, nestled between the terminal identifier code and the time of purchase code, are split into a ninety digit randomly generated number and a thirty-nine digit validation code. As described above, the validation 30 code is calculated by applying a one-time pad to the randomly generated number.

( To implement this mechanism it is necessary to modify the system slightly. Fig. 6 illustrates the steps of the identifier storage and validation process, and in the first step 300, the vendor terminal transmits the one-time pad used to generate the validation number along with the unique identifier to 5 the central data repository 60, 220 for storage (step 310).

In the preferred arrangement, the validation terminal 50, 210, on receipt of a unique identifier from the merchant terminal, extracts (step 320) the value code, identifier code, time code and randomly generated number and searches (step 330) for a unique identifier stored in the data repository that 10 includes a matching value code, identifier code, time code and randomly generated number.

If a match is found, the validation terminal retrieves (step 340) the onetime pad stored in association with the matched unique identifier, and applies (step 350) the retrieved one-time pad to the randomly generated 15 number extracted from the unique identifier forwarded by the merchant terminal. Application of the one-time pad to the randomly generated number allows the validation terminal to calculate a validation number which is then compared (step 360) with a validation number extracted from the unique identifier forwarded by the merchant terminal.

20 If the calculated validation number is found to match the validation number included in the unique identifier forwarded by the merchant terminal, the validation terminal determines that the unique identifier forwarded by the merchant terminal is valid (step 370), deletes the unique identifier and pad from the repository (step 380), and transmits (step 390) a "valid" signal to the 25 merchant terminal.

If the validation terminal is unable to match the identifier from the merchant terminal with one of the identifiers stored in the repository or if the calculated validation number does not match the extracted validation number, the validation terminal determines that the unique identifier forwarded by the 30 merchant terminal is invalid (step 400), and transmits (step 410) an "invalid" signal to the merchant terminal

It will be appreciated from the above that this second mechanism is very much more secure than the aforementioned first mechanism. However, there is still a danger that unscrupulous third parties could try every combination and permutation of each of the above mentioned numbers for a 5 given terminal vendor identifier. The chances of randomly hitting on a correct value code, a correct time code, a correct randomly generated number and a correct validation code by trial and error are very small, but there is still a chance that this could happen, and this might be of concern particularly if the identifier is to be used for larger sums of cash.

10 As a means to make a trial and error attack even less attractive, it would be possible to adapt the second mechanism described above so that the validation number and randomly generated number are transmitted in two separate messages. In this modification, the unique identifier would comprise a string of 160 characters, where the first five characters indicate the cash 15 value of the identifier, the next twenty characters identify the terminal from which the identifier was purchased, the last six digits comprise the time at which the purchase of the identifier was concluded, and the remaining one hundred and twenty-nine characters comprise a randomly generated number.

However, in addition to the unique identifier being sent to the customer 20 mobile terminal, a second message comprising a validation code of up to 160 digits (calculated by applying a one-time pad to the randomly generated number) would also be sent for storage in the customer terminal. As with the mechanism described immediately above, the vendor terminal would forward the one-time pad and the unique identifier to the central data repository for 25 storage. The only significant difference between this mechanism and the mechanism depicted in Fig. 6 is that the matching of the unique identifier and the comparison of the calculated validation number with the extracted validation number is a distinct two-stage process. Specifically, the validation 30 terminal would first search for a matching unique identifier stored in the repository, and in the event of a match would send a signal to the merchant

terminal to prompt the customer to send the aforementioned second message.

Once the validation terminal has received the second message, it extracts the validation number from the second message and compares it with the validation number calculated by applying the one-time pad stored in the 5 repository (in association with the matched unique identifier) to the randomly generated number forming part of the unique identifier forwarded by the merchant terminal.

If the validation terminal should determine that the calculated validation number matches the validation number encoded within the second 10 message, then a "valid" signal can be returned to the merchant terminal to indicate that the unique identifier is valid. In the absence of a match, an "invalid" signal is sent to notify the merchant that the unique identifier i presented by the customer is not valid.

As mentioned above, preferred embodiments of the invention have 15 been described by way of illustrative example, and it will be appreciated by persons skilled in the art that modifications may be made to the embodiments disclosed without departing from the scope of the invention.

For example, whilst the unique identifier has been described above in terms of numbers, it will be apparent to those persons skilled in the art that 20 utilising additional characters, such as alphanumeric characters, can further enhance the security of the system for example.

Claims

( CLAIMS

1. A payment system comprising: means for generating a unique identifier representative of a cash amount in response to customer payment; 5 means for transmitting said generated identifier to a customer mobile terminal; means for storing said generated identifier in a central data repository; means for receiving an identifier transmitted from a customer mobile terminal, said identifier being tendered by the customer as at least part 10 payment for goods or services; means for comparing at least a portion of a tendered identifier with at least a portion of generated identifiers previously stored in said central data repository; and means for indicating said tendered identifier to be valid if at least a portion of said tendered identifier matches at least a portion of a IS generated identifier previously stored in said central data repository.; 2. A system according to Claim 1, comprising a vendor terminal

including said identifier generating means and said identifier transmitting means. 4. A system according to Claim 1 or 2, comprising a merchant terminal including said identifier receiving means.

5. A system according to any preceding claim, comprising a validation 25 terminal including said comparing means.

6. A system according to Claim 1, comprising a vendor terminal operable to receive customer payment.

30 7. A system according to Claim 6, comprising a merchant terminal

( configured to accept payment, at least in part, for goods or services by way of a unique identifier transmitted from a said customer mobile terminal.

8. A system according to Claim 6 or 7, comprising a validation terminal 5 operably connected to said vendor terminal, said validation terminal comprising said identifier generating means and said identifier transmitting means, and being operable in response to payment received by said vendor terminal to generate a said identifier and to transmit said generated identifier to a said customer mobile terminal.

9. A system according to Claim 8 when dependent on Claim 7, wherein said validation terminal is operably connected to said merchant terminal, and comprises said identifier receiving means and said identifier comparing means. 15 t lO. A system according to any preceding claim, wherein said central data repository comprises a computing resource, said computing resource including said means for storing identifiers and being programmed to establish and maintain an electronic database configured for the storage of 20 unique identifiers.

11. A system according to any preceding claim, wherein said customer mobile terminal comprises a mobile telephone, or a personal digital assistant with telephonic capabilities.

12. A system according to any preceding claim, wherein said identifier transmitting means is configured to transmit said identifier to said customer mobile terminal as an SMS, MMS or E-SMS message.

30 13. A system according to any preceding claim, wherein said identifier receiving means is configured to receive said identifier as an SMS, MMS or

( E-SMS message.

14. A system according to any preceding claim, wherein said identifier comprises a randomly generated number or a randomly generated string of 5 alphanumeric characters.

15. A system according to Claim 14, wherein identifier additionally comprises a code which is representative of said cash amount.

10 16. A system according to Claim 14 or IS, wherein said identifier further comprises a string of numerals or alphanumeric characters which uniquely identify a vendor teTTninal at which said customer payment is received.

17. A system according to any of Claims 14 to 16, wherein said identifier 15 further comprises a time code indicating the time at which said customer t payment is effected.

18. A system according to any of Claims 14 to 17, wherein said identifier additionally comprises a validation code.

19. A system according to any of Claims 14 to 17, wherein said identifier is associated with a validation message transmitted separately from said identifier to said customer mobile terminal, said validation message comprising a validation code which may be used to validate said identifier.

20. A system according to Claim 18 or 19 when dependent on any of Claims 14 to 17, wherein said validation code comprises a hash of said randomly generated number with a one-time pad.

30 21. A system according to Claim 20, wherein said identifier storing means is configured to store said one-time pad along with said identifier in said

( central data repository.

22. A system according to Claim 20 and 21 when dependent on Claim 18, wherein said comparing means is configured to obtain a stored one-time pad 5 associated with a said matching identifier and to calculate a hash of a portion of said identifier with said one-time pad, said comparing means being further operable to compare said calculated hash with another portion of said identifier to determine the validity of said identifier.

10 23. A system according to Claim 20 and 21 when dependent on Claim 19, wherein said comparing means is configured to obtain a stored one-time pad associated with a said matching identifier and to calculate a hash of a portion of said identifier with said one-time pad, said comparing means being further operable to compare said calculated hash with validation number derived 15 from said validation message to determine the validity of said identifier.

24. A payment system comprising: at a vendor tend inal, means for generating in response to customer payment a unique identifier that is representative of a cash amount' means for 20 configuring said identifier as an SMS message, means for transmitting said SMS message to a customer mobile terminal; and means for transmitting said identifier to a central data repository for storage; at a merchant terminal, means for receiving an SMS message i transmitted from a customer mobile terminal and including said identifier; 25 means for extracting the identifier from said SMS message, and means for transmitting said identifier to a validation facility; at the validation facility, means for comparing the identifier received from said merchant terminal with identifiers stored in said central data repository, and means for transmitting a validation code to said merchant 30 terminal in the event of a match between a said received identification number I and a said stored identification number;

wherein the merchant terminal is operable on receipt of a said validation code from the validation terminal to indicate that the identifier received from said customer mobile terminal is valid and that said identifier number is appropriate for use as payment for goods or services to the value of 5 said cash amount.

25. A vendor terminal for use with the system of any preceding claim.

26. A merchant terminal for use with the system of any preceding claim.

27. A validation tenninal for use with the system of any preceding claim.

28. A customer mobile terminal for use with the system of any preceding claim. 29. A method of generating a unique identifier representative of a cash amount, the method comprising: generating a random number, generating one or more other codes, configuring said random number and said one or more other codes as a message, and transmitting said message to a customer mobile 20 terminal. 30. A method of effecting at least part payment for goods or services by means of a payment system according to any of Claims I to 24, the method comprising: presenting a said identifier as at least part payment for goods or 25 services; validating said presented identifier; and, on validation, accepting said presented identifier as at least part payment for said goods or services.

31. A system substantially as hereinbefore described with reference to the appended drawings.

32. A method substantially as hereinbefore described.

( 33. A vendor terminal, merchant terminal, validation terminal or customer mobile terminal substantially as hereinbefore described, the vendor terminal, merchant terminal, validation terminal or customer mobile terminal being suitable for use with the system claimed in any of claims 1 to 24.