WO2004049621A1

WO2004049621A1 - Authentication and identification system and transactions using such an authentication and identification system

Info

Publication number: WO2004049621A1
Application number: PCT/SG2003/000279
Authority: WO
Inventors: Mack Kalevi Palomaki; Olaf Fritz Hans Otto Lohmann
Original assignee: GOLD FUSION INTERNATIONAL Ltd
Current assignee: GOLD FUSION INTERNATIONAL Ltd
Priority date: 2002-11-28
Filing date: 2003-11-28
Publication date: 2004-06-10
Anticipated expiration: 2005-05-28
Also published as: AU2003282770A1; TW200409521A

Abstract

The present invention provides a method for authenticating and identifying a user, whereby a first terminal communicates with a facilitator over a first telecommunications channel and a second terminal communicates with an operator over a second telecommunications channel, the operator and the facilitator being able to communicate with each other, wherein no identity data of the user is required to be provided to the first terminal by the operator, the facilitator, or the second terminal; no identity data of the first terminal is required to be provided to the second terminal by the operator, the facilitator or the first terminal; and wherein any communication between the first terminal and the facilitator is not required to contain data regarding the identity details of the user or the second terminal; and any communication between the second terminal and the operator is not required to contain data regarding the identity details of the user.

Description

AUTHENTICATION AND IDENTIFICATION SYSTEM AND TRANSACTIONS USING SUCH AN AUTHENTICATION AND IDENTIFICATION SYSTEM

Field of the Invention

The present invention relates to an authentication and identification system and to transactions conducted using such an authentication and identification system, and refers particularly, though not exclusively, to such systems and transactions using a mobile telephone.

Definitions

Throughout this specification a reference to a mobile telephone is to be taken as including, but is not restricted to any mobile and telecommunications enabled terminal such as, for example, a mobile telephone, hand telephone, cell telephone, PDA, notepad computer, notebook computer, laptop computer, tablet computer, and any other portable, wireless device that is telephone enabled.

Acronyms

Throughout this specification the following acronyms have the following meanings:

3G Third Generation

ID Identify

PIN Personal Identification Number POS Point Of Sale

SAM Secure Access Module

SIM Subscriber Identify Module

SMS Short Message Service

STK SIM ToolKit TMSI Temporary Mobile Subscriber Identity

USSD Unstructured Supplementary Service Data

Background to the Invention

Many authentication and payment systems have been tried during recent years, but as yet, there is no global standard. Different systems are constantly emerging. Current platforms have not adequately addressed how to make a consistent user interface that enables authentication and different types of mobile payments that are easy to use, and fast.

The majority of today's solutions are platform-centric and each solution vendor works their platform to become the international standard. Each platform brings its own philosophy and processes. As a consequence, transaction flow and user interaction also differs significantly between platforms and, too often, within the same platform.

Today there are over one billion mobile phone users, most of whom regard it as a convenient and fashionable accessory. Mobile phones have become a part of our daily lives and they are with us most of the time. Mobile phones are personal, trusted devices that are associated with a significant line of credit.

People will start to use their mobile phone as a payment channel if it is either easy and convenient to use, or if there are other reasons to adopt it. For example, if they do not like to carry cash or a credit card.

In certain environments it is dangerous to carry sizeable amounts of cash or other valuables. A mobile phone offers superior protection to its owner because, if it is stolen, only the current market value of the device is lost and any prepaid value, associated accounts and credit card numbers remain protected.

Summary of the Invention

With the above and other objects in mind the present invention provides a method for authenticating and identifying a user, whereby

(a) a first terminal communicates with a facilitator over a first channel and

(b) a second terminal communicates with an operator over a second channel, the operator and the facilitator being able to communicate with each other, wherein (c) no identity data of the user is required to be provided to the first terminal by the operator, the facilitator, or the second terminal; (d) no identity data of the first terminal is required to be provided to the second terminal by the operator, the facilitator or the first terminal; and wherein (e) any communication between the first terminal and the facilitator is not required to contain data regarding the identity details of the user or the second terminal; and (f) any communication between the second terminal and the operator is not required to contain data regarding the identity details of the first terminal

The invention also provides a method for authenticating and identifying a user for enabling a facilitator to provide an authentication and identification message to a first terminal over a first channel, whereby

(a) a user's terminal is able to communicate with an operator over a second channel, the operator and the facilitator being able to communicate with each other, wherein (b) no identity data of the user is required to be provided to the first terminal by the operator, the facilitator, or the second terminal, (c) no identity data of the first terminal is required to be provided to the second terminal by the operator, the facilitator or the first terminal, and wherein (d) any communication between the first terminal and the facilitator is not required to contain data regarding the identity details of the user or the second terminal, and (e) any communication between the second terminal and the operator is not required to contain data regarding the identity details of the first terminal

The user is not required to provide any identity information or data to the first terminal, not to any operator of the first terminal If identity data or information regarding the user is provided by the user or the second terminal to the first terminal or an operator of the first terminal, it is preferred that such information or data cannot be entered into the first terminal, and cannot be sent to the facilitator by the first terminal

The facilitator may generate a facilitator's message containing a one-use only authentication and identification sign to be used for a single authentication process, the facilitator sending the facilitator's message containing the authentication and identification sign to the first terminal using the first telecommunications channel

Preferably, the first terminal receives from the facilitator the facilitator's message containing the authentication and identification sign in such a manner that the authentication and identification sign is passed to and entered in the second terminal, the second terminal sending the authentication and identification sign to the operator over the second telecommunications channel The operator may receive the authentication and identification sign from the second terminal, the authentication and identification sign having added to it at least one identification detail of the user, and the operator sends to the facilitator the authentication and identification sign and the at least one identification detail of the user.

Preferably, the facilitator receives from the operator the authentication and identification sign and the at least one identification detail of the user, uses the authentication and identification sign to retrieve the message, checks the authentication and identification sign in the message against the authentication and identification sign as received and, upon a successful match being made, the facilitator provides to the first terminal an authentication message containing authentication of the user, the authentication message being sent over the first telecommunications channel.

The authentication and identification may be part of a transaction system, the transaction system being one or more of: a financial transaction, a payment transaction, a queuing transaction, a signing on or off for a service supplier, making a booking or reservation, arranging for a service by a service supplier, discontinuing a service by a service supplier, and logon to an application or the Internet.

The first terminal may be a terminal of a merchant, more preferably a point-of-sale terminal, and the second terminal may be a mobile telephone of the user. The at least one identification detail of the user may contain at least one information item obtained from at least one of: an RF smart card, and a SIM card of the mobile telephone, and/or at least one item from the mobile telephone. Alternatively, or additionally, it may be added by or at the operator.

The authentication and identification sign may be passed to the second terminal by the user viewing the authentication and identification sign on the first terminal and/or any display associated therewith and entering the authentication and identification sign in the second terminal; by being printed at the first terminal and a print-out of the authentication and identification sign passed to the user for entry in the second terminal; by being sent from the first terminal to the second terminal by wireless transmission; or by the authentication and identification sign being entered in the second terminal by voice activation. A display associated with the first terminal may include such things as, for example, a cash or checkout register associated with a POS terminal, a display at a toll booth or car park exit/payment booth, and so forth. When the authentication and identification sign is sent to the operator, a PIN may also be sent. The PIN may be sent immediately prior to the authentication and identification sign, and the operator may first approve the PIN before the authentication and identification sign is entered, or sent.

The authentication and identification sign may contain a plurality of characters, and each of the plurality of characters may be selected from: a number, a letter, a graphic symbol, a mark of punctuation, a pronunciation key, and an ASCII character.

The facilitator and the operator may be the same or different entities. The facilitator may be part of a financial institution, and the operator may provide a range of financial services on behalf of the financial institution.

Upon the user sending the authentication and identification sign to the operator, the operator may provide an acknowledgement to the user.

In another form, the present invention provides a method for authenticating and identifying a user whereby (a) a first terminal communicates with a facilitator over a first channel and

(b) a second terminal of the second party communicates with an operator over a second channel, the operator and the facilitator being able to communicate with each other; wherein in response to a request from the first terminal: (c) the facilitator generates a message containing a one-use only authentication and identification sign to be used for a single authentication process;

(d) the facilitator sends the message containing the authentication and identification sign to the first terminal using the first channel;

(e) the first terminal receives from the facilitator the message containing the authentication and identification

(f) the authentication and identification sign is passed to the second terminal and entered in the second terminal;

(g) the second terminal sends the authentication and identification sign to the operator over the second channel; (h) the operator receives the authentication and identification sign from the second terminal, the authentication and identification sign having added to it at least one identification detail of the user;

(i) the operator sends to the facilitator the authentication and identification sign and the at least one identification detail of the user;

(j) the facilitator receives from the operator the authentication and identification sign and the at least one identification detail of the user and uses the authentication and identification sign to retrieve the message;

(k) the facilitator checks the authentication and identification sign in the message against the authentication and identification sign as received in step (h); and

(I) upon a successful match being made in step (i), the facilitator provides to the first terminal an authentication message containing authentication of the customer, the authentication message being sent over the first channel.

The present invention also provides a method for authenticating and identifying a user whereby a first terminal is able to communicate with a facilitator over a first channel and a second terminal is able to communicate with an operator over a second channel, the operator and the facilitator being able to communicate with each other; wherein in the first terminal sends a request to the facilitator over the first channel and receives from the facilitator a facilitator's message generated by the facilitator and containing a one-use only authentication and identification sign to be used for a single authentication process; the first terminal passes the authentication and identification sign to the second terminal to enable:

(a) the second terminal to send the authentication and identification sign to the operator over the second channel; (b) the operator to receive the authentication and identification sign from the second terminal, the authentication and identification sign having added to it at least one identification detail of the user; (c) the operator to send to the facilitator the authentication and identification sign and the at least one identification detail of the user; (d) the facilitator to receive from the operator the authentication and identification sign and the at least one identification detail of the user and to use the authentication and identification sign to retrieve the message; (e) the facilitator to check the authentication and identification sign in the message against the authentication and identification sign as received in step (d); and (f) upon a successful match being made in step (e), the facilitator to send to the first terminal an authentication message containing authentication of the customer, the authentication message being sent over the first channel.

The second terminal may be a mobile telephone of the user, and the first terminal may be a terminal of a merchant, preferably a point-of-sale terminal. Preferably, any transmission over the second channel is by use of a telecommunications system having signalling such as, for example, GSM.

The first channel and the second channel may be separated by.at least one of: physically and logically. The first channel may be a first telecommunications channel, and the second channel may be a second telecommunications channel. At least one of the first channel and the second channel may be secure. An RF smart card may be used in place of the operator; and may be used in place of the financial institution.

In a final form the present invention provides a method of sending and utilising a PIN wherein the PIN is sent to an operator before a user ID, the operator first searching by reference to the PIN to provide a limited number of possibilities, the operator then searching through the limited number of possibilities by reference to the user ID.

The present invention provides a payment solution that supports different payment modes that may be face-to-face, remote, mail order, and telephone order.

It may enable a variety of payment applications using different combinations of payment devices for retail purchase, remote payment, and money transfer between accounts. Preferably, it leverages existing back-end infrastructure, avoids re-investment in technical equipment, provides flexibility to cope with different requirements of the involved parties and leverages existing network features and other standard GSM functionality. It preferably works with all existing handsets and SIM cards without requiring modification or upgrade.

Payment scenarios may include remote payments, bus fare, parking fee, mail order, telephone order payments, and person-to-person payments.

The parties involved in the system may include a mobile phone user, a mobile operator, a merchant, a financial institution or several financial institutions, and a payment facilitator. The standardised course of payment preferably hides the business logic, payment process and security from the user and therefore makes the technology transparent. The back-end may execute the necessary transactions according to the desired type of payment and account pre-defined by the user.

Description of the Drawings

In order that the invention may be readily understood and put into practical effect, there shall now be described by way of non-limitative example only preferred embodiments of the present invention, the description being with reference to the accompanying illustrative drawings, in which:

Figure 1 is a conceptual diagram of a trust relationship in a normal mobile payment system;

Figure 2 is an illustration of the overall architecture with relevant interfaces of the system;

Figure 3 is a conceptual diagram of the trust relationship in a mobile payment scenario according to a first form of the present invention;

Figure 4 is a conceptual diagram of the trust relationship in a mobile payment scenario according to a second form of the present invention;

Figure 5 is a perspective view of various forms of terminal able to be used with the present invention; Figures 6 and 6a are an illustration of the process steps of one form of the present invention;

Figure 7 is an illustration of the process steps of a first embodiment of the present invention;

Figure 8 is an illustration of the process steps of a second embodiment of the present invention;

Figure 9 is an illustration of the process steps of a third embodiment of the present invention; Figure 10 is an illustration of the process steps of a fourth embodiment of the present invention;

Figure 11 is an illustration of the process steps of a payment process of the present invention;

Figure 12 is an illustration of the process steps of a payment flow of the present invention. Figure 13 is an illustration of the process steps of a second form of the present invention;

Figure 14 is an illustration of levels of encryption;

Figure 15 is an illustration of call paths;

Figure 16 is an illustration of some of the mobile networks with which the present invention may be used; and Figure 17 is an illustration of a further embodiment of the present invention. Description of the Preferred Embodiments

The present invention is an authentication and identification system. It may be used for a number of purposes including, but not being limited to, authentication and identification of a user; and for a variety of transactions such as, for example, a queuing system, a financial transaction system, a payment system, and logon systems including for the Internet and applications. The operation of the authentication and identification system is essentially the same for each. A number of such transaction systems are described below as examples of the authentication system. The present invention is not limited to the examples given.

In all drawings, like reference numerals are used for like components. In all instances a prefix number is used to represent the drawing figure concerned. .

To first refer to Figure 1 , there are currently more than one billion mobile phone subscribers 122 world-wide. Already the total number of issued SIM cards has reached several billions. The different user constituencies already have established trust relationships with each other. For the purposes of mobile payments a number of relationships are relevant, such as, for example: mobile phone operators 124 with their subscribers 122; acquiring financial institutions with their merchants; financial institutions 126, 128 with their financial institution account holders 122, 124,

132; and credit card companies 130 with their financial institutions 126, 128.

Similarly, for authentication only services, the relevant relationships may include mobile phone operators 124 with their subscribers 122, and a service provider requiring authentication with their customers.

In delegated trust, some trust-related functions are distributed to other entities to provide the overall service. Delegation of authentication of customers 122 who already have a mobile phone subscription to mobile operator 124 by a service provider forms the basis for enabling the communications to be over two separate and distinct telecommunications channels. For transactions using the authentication and identification of the present invention, the delegation of trust includes the authentication and identification match, and the separation of the data into two separate channels. These separate channels may be physically separate, or logically separate. Figure 1 is a conceptual diagram of a mobile payment scenario. The irregular shapes represent the current situation - interfaces are not neat and tidy - there are many variations and special circumstances.

Although these relationships have different levels of security, users currently accept all of them except one for payment transactions - the relationship between the operator and its users - which is not used for making payments. This is despite modern mobile telephony systems such as GSM having a security level that is quite superior. This high level of GSM security can be mainly attributed to the use of smart cards, in this case the SIM card.

The trusted relationships shown in Figure 1 are firmly established - to impose changes in these would be unrealistic and prohibitively expensive.

To now refer to Figure 2, there is illustrated a preferred embodiment of a system according to the present invention. The dashed line around the payment facilitator 234 indicates that this is a function that could be stand alone or be incorporated within the operator 224, or the financial institution 226, 228, 230.

Varying levels of security can be implemented, taking into consideration the prevailing threat environment and regulatory requirements, giving the option of authentication and identification signs only or authentication and identification signs with a PIN.

The present invention provides a collaborative relationship model that will allow the respective parties to "pass on" trust - i.e. to delegate the trust - to other parties. This is termed "Delegated Trust". Delegated trust is simple.

As is shown in Figure 3, the operator 324 has a trusted relationship with the financial institution 326, 328, 330. The user 322 has another trusted relationship with the operator 324. The user 322 gives the mobile operator 324 an authority to act on their behalf to execute transactions with the financial institution 326, 328, 330.

The account used for mobile payments may be one of the following account types: prepaid account, either with the mobile operator 324 or a financial institution 326; post-paid account with the mobile operator 324; financial institution account 326; or credit card account 330. Monetary transactions are subject to regulation by national monetary authorities and it depends on the respective regulation if entities must have a license to be allowed to maintain a prepaid account.

As is shown in Figure 4, a collaborative relationship may be used between the operator 424 and a financial institution 426 that has the necessary licences. This may be called delegated financial institutioning. With delegated financial institutioning a mobile operator 424 can offer a limited range of financial institutioning services using a financial institution 426 as the trusted partner.

In particular there is an opportunity to provide prepaid financial institutioning facilities to mobile operators 424. The operator 424 may be the primary party for maintaining customer information 440. The financial institution may maintain only monetary aspects of the accounts 442, and preferably does not require detailed information of users 442.

In this way the operator 424 can offer its customers 422 mobile payments simply by establishing a prepaid account that requires no credentials except for pre-payments of the amounts intended for mobile purchases. The maintenance and billing of financial institution accounts is preferably handled by the financial institution 426, supported by subscriber data 440 provided by the operator 424.

To now refer to Figure 5, there may be used different front-end equipment at the merchant 532. For example, there may be a fixed line POS terminal 510. With such a terminal a magnetic stripe cards 12 is issued to the merchant 532 and is associated with a special account with one of the supported credit/debit card companies 530 such that the terminal 510 can dial an existing number of one of the supported card companies 530; a fixed line POS terminal 514 with software modification; wireless POS terminal 516 - with GSM phone 518 connected. The magnetic stripe card 512 is issued to the merchant 532 and is associated with a new account that is set up especially for the service. The terminal 516 dials a new number to the payment facilitator 534. Depending on the POS terminal, it may be possible to replace the merchant's magnetic stripe card 512 with a hot button (not shown) on the keyboard of the terminal. The merchant 532 may be issued a new, mobile POS terminal 516 with customised software, allowing for a direct dial-up to the payment facilitator; or a GSM phone 520 - with merchant STK SIM card, a GSM phone may be used as the sole POS terminal equipment. The merchant 532 may be issued a specially programmed STK SIM card. Both the merchant and the user may be offered a consistent mobile payment experience, irrespective of the type of payment executed. A standard mobile phone may be used as the payment device. For face-to-face payments, the mobile phone may be used in conjunction with one or more of: a POS terminal, ATM, vending machine, RF smart card, or another interface. From the user's perspective each transaction involves a standard procedure that is similar to making a telephone call or sending a message but includes entering the authentication and identification sign and, if applicable, entering a PIN. In sending the authentication and identification sign from the user's mobile phone to the operator the process is by making a call or sending a message. When the operator receives the call or USSD (the signaling systems within the telecommunications system will take care of this) the number dialed is extracted and used by the operator to initiate the authentication and identification process. The process with SMS is different. First the operator receives the SMS in the same way as a voice call or USSD in the switch (at this point the operator already knows who is sending the SMS and that it is an SMS that has been requested by the user). The operator then extracts the designated SMSC number (pre-set and stored in the SIM or mobile phone of the user and embedded into every sent SMS) and forwards the SMS (message) to the appropriate SMSC. The SMSC sends the SMS to the designated destination number. SMS is not a preferred form of transmittal of data from the user to the operator as an SMS inherently contains data regarding the source and destination of the message, and involves an SMS router in the message path.

Figures 6 and 6a illustrate the process steps for authentication and identification during a financial transaction process. These are relatively simple and are as set out in Table 1.

For other forms of transactions, the initialisation of the process may be different. For example, when the user is logging on to an application or the Internet, the act of starting the logon process by the user does not require the swiping of a magnetic card or pressing a specific button nor the entry of an amount. The start of the logon process may be standard, but the user will receive at their machine/terminal the authentication and identification sign as is described all above. Such a logon process is equivalent to steps 1 and 2 above. When the user's terminal receives the authentication and identification sign, the user would view the authentication and identification sign on their terminal before undertaking steps 4 and 5 using their mobile phone.

The operator may add at least one identification detail of the user then send the authentication to the facilitator (652). The at least one identification detail may contain information obtained from a SIM card of the mobile telephone and/or from the mobile phone itself.

The authentication and identification sign is passed to the mobile phone by any one or more of suitable means such as, for example, being printed by the POS terminal and handed to the user/customer, displayed on the POS terminal, audibly generated on the POS, or sent from the POS terminal to the mobile phone by wireless transmission. More than one may be used as the user may be visually or hearing impaired. If required, the authentication and identification sign may be entered on the mobile phone by any suitable means such as, for example, voice activation, keypad entry, stylus entry, and voice recognition.

The PIN code may be sent immediately prior to or immediately after the authentication and identification sign. The PIN may only be required to be entered as a result of a prompt from the operator. In case the system is for a restricted range of users, the operator may first approve the PIN before the authentication and identification sign is entered or, alternatively, sent. In this way the operator knows the user (as distinct from the mobile phone) is from that restricted range of users. The operator may also approve the authentication and identification sign before the PIN is sent.

By sending the PIN before the authentication and identification sign, the operator can search by reference to the PIN. The result of that search should be a limited number of possibilities - anything from one up. As such, when the authentication and identification sign is received, or the user ID from the mobile phone's SIM card, the search to be conducted by the operator is quite limited. This may quicken the process. This is because there may be many users with the same user ID, but very few with the same PIN.

The authentication and identification sign preferably contains a plurality of characters. Each of the characters may be one or more of a number, a letter, a graphic symbol, a mark of punctuation, a pronunciation key, and an ASCII character.

The authentication and identification sign is randomly generated by the facilitator or other trusted party. The randomness of the generation may be in the characters used and/or the number of characters used. For example, in one instance it may be have only numbers. It may be alphanumeric, or may be constituted of non-alpha and non-numeric characters. It may contain any character that is available on a mobile phone keypad. The only limitation is that all characters used must be able to be transmitted by the mobile phone. Given that voice recognition may be used, this may not be limited to characters on the keypad of the mobile phone.

The authentication and identification sign achieves two levels of security - it identifies the specific authentication process taking place and acts as a tracking device so that the facilitator and the operator can reliably track the authentication and identification taking place through all steps in the process, and identifies the user/customer as being the person involved in the authentication and identification process. The second aspect is of greater significance during a transaction as only that user is involved with the transaction. When combined with a personal security item obtained from the user or the user's terminal/mobile phone three levels of security are involved.

As is clear from Figure 16, when dealing with a mobile phone an ID of the mobile phone is provided to the operator as a normal part of making a call so that the operator knows who to bill for the call. That information comes from the mobile phone SIM card. That provides a first level of authentication and identification. When the authentication and identification sign is sent to the operator, that provides a second level of authentication and identification as it establishes a one-time authentication of the terminal/mobile phone. As the mobile phone may being used by another person (legally or illegally), the sending of the PIN provides a third level of authentication and identification.

Therefore, the mobile phone provides the identity of the mobile phone and thus the identity of the owner of that mobile phone, the authentication and identification sign places that mobile phone in the authentication and identification process, and the PIN or other personal identifier finally authenticates and identifies that the owner of the mobile phone is using the mobile phone and is the person being authenticated and identified.

The authentication and identification sign may be tagged by the facilitator prior to being sent to the merchant's terminal. There may be one or more tags. The tags may be for a number of functions including, but not being limited to, the origin of the authentication and identification sign, the destination terminal, the transaction being the subject of the authentication and identification, the nature of the authentication and identification, and so forth.

The authentication and identification sign may have an in-built time limit so that the facilitator must perform the match within a predetermined time. This time may be pre-set according to a number of factors such as, for example, location, nature of the transaction, value of transaction, and so forth. Suitable times may be, for example, 15 seconds for a low-value transaction requiring speed (e.g. toll booth, car park exit), 30 seconds for a "normal" transaction (e.g. supermarket or department store) or 60 seconds for a transaction at a remote location or for a major purchase. The remaining time may be displayed in the same manner as the authentication and identification sign. This may be by a clock display, digital time display, bar graph display, or the like.

The operator and/or facilitator (the facilitator will need to use information on mobile phone location obtained from the operator) may also perform a location match by checking that the cell being used by the customer is relevant for the merchant. This may also be done using GPS. A similar match may be performed using time - the various communications are happening within a prescribed time period.

The length of the authentication and identification sign may vary according to a number of factors including, but not limited to, the nature of the transaction, the location of the transaction, and the value of the transaction. For example, a small number of characters such as three or four for a low-value transaction and/or a transaction requiring speed and/or a transaction with low security (e.g. toll booth, car park exit); a larger number of characters such as six or eight for a "normal" transaction for normal value ranges for everyday purchases and/or having a medium level of speed required and/or having a medium level of security (e.g. supermarket or department store transactions); or a longer character string such as ten to sixteen characters for a major transaction, and/or when there is a high level of security and/or secrecy, and/or when time is not of significant importance, and/or for a major purchase.

The customer/user may use the POS for entering the PIN, if required or desired. However, the POS terminal should not be used by the user to enter the authentication and identification sign as that should be sent to the operator over a different channel. That different channel may be a physically different channel such as, for example, a different telecommunications channel; or may be a different logical channel. The two channels may be separate physically or logically. For example, the different channels may be over the one telecommunications link and techniques such as multiplexing and/or different encryption schemes used. More than two channels may be used. Similarly, the user ID as obtained from the user's mobile phone SIM card should not be sent from the POS so that it is also sent over the second telecommunications channel.

The initiation of a face-to-face purchase requires the participation of both the merchant and the mobile phone user. The enabler of all transactions is the facilitator, a logical entity that may be a free standing legal entity, or a function within one of the other participating parties such as the operator or financial institution.

The process of Figures 6 and 6a may also be used for initiating or terminating a service. For example, a user can use the system to sign-on to the system at, for example, a POS terminal. If the authentication and identification process is followed as described above, the user can be given the terms and conditions of the service. This may be by being given a hard copy kept by the merchant, by being printed on the POS (at the same time as the authentication and identification sign is printed, or subsequent to authentication and identification), by soft copy sent to a given email or other messaging account, or otherwise as available at the time. The limitations of the user's terminal/mobile phone may impact on how this is done. For example, if the user has a telephone enabled PDA, it may have sufficient memory for the terms and conditions document to be sent to and saved on the user's terminal.

The user's acceptance of the terms and conditions may also be given in a number of suitable methods such as, for example, indication acceptance using their mobile phone in response to a query message from the operator; using a stylus to sign on a display screen of the POS, the user being given a print-out of the acceptance signature; entry of a PIN or other personal identifier in either the mobile phone or the POS; or by signing a hard copy and the merchant providing to the facilitator an on-line confirmation of the user having signed, the merchant then sending the hard copy to the facilitator by normal means.

As the user may not have the details of the operator to which the authentication and identification sign is to be sent, these may be provided by the merchant in hard copy, or otherwise as for the terms and conditions. Alternatively, they may be provided at the same time and in the same manner as the authentication and identification sign.

This could also be used for other services such as, for example, booking tickets for theatre, concert, show, sports event, travel, or the like; making a restaurant, hotel or other reservation; booking a car or other apparatus/equipment for a service; arranging for a repairman or other service supplier to call at a home, office or other location of the user; and so forth. In a similar manner it can be used for discontinuing a service such as any of those described above. Four examples of a wireless payment transaction will now be described:

1. replacement of prepaid vouchers (operator only);

2. micro payment (operator only);

3. replacement of prepaid vouchers (financial institution involvement); and 4. retail payments (financial institution involvement).

In each of the four examples described below with reference to Figures 7 to 10, the steps 1 and 2 of Table 1 above are included, but are not described as they are common to all four examples.

Figure 7 shows the payment process for payment of prepaid airtime where the operator 724 has the relationship with the merchant 732, and also acts as the payment facilitator 734.

1 Customer 722 pays cash to the merchant 732 to be credited to account of the customer 722; 2 Merchant 732 gives slip with authentication and identification sign and amount to customer 722 or shows to the customer 722 the authentication and identification sign and amount as displayed on the POS handset, POS terminal display, computer display, cash register display or other display device; 3 Customer 722 sends authentication and identification sign to operator 724; 4 Merchant 732 sends payment request to operator 724, the operator 724 also acting as the facilitator 734;

5 Operator/facilitator 724 conducts match check and, if correct, confirms top-up to merchant 732;

6 Operator/facilitator 724 sends confirmation SMS to customer 722; 7 Merchant 732 prints receipt and gives it to customer 722.

Figure 8 shows the payment process when the operator 824 bills the customer 822 on their phone bill. In this case, the operator 824 acts as the payment facilitator 834. However, if more than one operator 824 is involved, it may be advantageous to appoint a third party payment provider/facilitator.

1 Merchant 832 gives authentication and identification sign with amount to customer 822;

2 Customer 822 sends authentication and identification sign to operator 824;

3 If required, customer enters PIN on POS; 4 Operator 824 sends customer ID, authentication and identification sign, time, and optionally the location, to facilitator 834; 5 Merchant 832 sends PIN (if entered), amount, POS ID, merchant ID, authentication and identification sign, and time, to facilitator 834;

6 Operator 824 sends payment validation result - approval /denial - to facilitator 834 who forwards this to merchant 832; 7 Operator 824 sends confirmation SMS to customer 822;

8 Merchant 832 prints receipt and gives it to customer 822; and

9 (not shown) customer 822 is billed by mobile operator 824.

Figure 9 depicts the payment process for payment of prepaid airtime where the operator 924 does not have a direct relationship with the merchant 932. When co-operating with a financial institution 926, the operator 924 has an option of requiring prepayment by the merchant 932 for sold airtime (not shown). As illustrated, the operator 924 acts as the facilitator 934, although it is feasible to appoint a third party for this role.

1 Customer 922 pays cash to the merchant 932 for crediting to an account of the customer 922;

2 Merchant 932 gives slip with authentication and identification sign and amount to customer 922;

3 Customer 922 dials and sends authentication and identification sign;

4 Merchant 932 sends payment request to financial institution 926; 5 Financial institution 926 sends payment advice to operator 924;

6 Operator 924 confirms top-up to financial institution 926 and the financial institution 926 forwards this to the merchant 932;

7 Operator 924 sends confirmation SMS to customer 924;

8 Merchant 932 prints receipt and gives it to customer 922.

Figure 10 shows the payment process for face-to-face payments with the involvement of a financial institution 1026 and third-party payment facilitator 1034. Typically, this scenario would apply to a multi-operator environment.

1 merchant 1032 gives slip with authentication and identification sign and amount to customer 1022;

2 customer 1022 dials and sends authentication and identification sign;

3 if required, customer 1022 enters PIN on POS;

4 mobile operator 1024 sends customer ID, authentication and identification sign, time, and if required or desired location, to payment facilitator 1034; 5 merchant 1032 sends PIN (if entered), amount, POS ID, merchant ID, authentication and identification sign, time;

6 facilitator 1034 checks its database and authenticates and identifies customer 1022;

7 facilitator 1034 sends customer ID, authentication and identification sign, POS ID, merchant ID, time, amount and PIN (if entered) to financial institution 1026;

8 financial institution 1026 sends payment validation result - approval /denial to facilitator 1034 and merchant 1032- this is forwarded to the merchant 1032;

9 facilitator 1034 sends confirmation SMS to customer 1022;

10 merchant 1032 prints receipt and gives it to customer 1022.

Figure 11 shows the payment process and Figure 12 illustrates the payment flow:

1. payment initiation by user 1122 and merchant 1132;

2. extraction of transaction data by mobile operator 1124;

3. matching of data by payment facilitator 1134; and

4. routing of payment instruction to financial institution 1126.

The user 1122 should have: a. a valid telephony subscription with a mobile operator 1124 and a handset capable of being used with a telecommunications system having signalling, such as, for example, GSM; b. enrol with the service according to the present invention; c. must have an account that can be associated with the services. The user's range of choice of payment methods depends on the implementation of the solution and agreements made between the involved parties. Possible account types include: • Prepaid account (provided by either the operator or a financial institution);

Mobile telephony post paid account (provided by the operator);

Credit card account;

Debit card account;

Other financial institution account.

d. needs to abide by the terms and conditions of the service; e. must pay for the services used; f. is responsible for safeguarding the mobile phone and any PIN codes associated to the service; and g. must promptly notify the service facilitator in case of loss or theft of his mobile phone in order to prevent personal financial loss. If used for the payment of parking fees, it might become necessary to register the user's vehicle registration number.

The mobile operator 1124 should: implement the required service elements; provide provisioning of user to the service; provide its mobile and back-end network infrastructure to enable the service; provide delegated trust services; provide accounts for the service; extract and transmit trusted data for transactions and account top-ups; issue bills and collect payments; generate and maintain logs of all transactions; sell and promote the service; and support the user through its customer care.

The operator 1124 needs to provide the following information in connection with each transaction to the payment facilitator: a. User identity (e.g. MSISDN); b. Merchant and POS terminal identity; c. Time stamp; d. Location information (optional).

If the communication over this link is over a computer network or the Internet it may not require an operator or an ISP.

The operator 1124 may transmit a PIN that may be encrypted.

If the operator 1124 decides to offer the payment service via the user's prepaid account or the subscriber's phone bill, the other parties may not be required as the service is then fully under the control of the operator 1124.

Optionally the operator 1124 can divide their service area into zones with the help of location recognition of the subscriber to enhance security.

There are two options for the financial institution depending if delegated trust is implemented. If delegated trust is implemented, the financial institution can execute transactions without modification to existing processes. If delegated trust is not implemented, the financial institution may need to provide a new interface between its systems and the payment facilitator, and possibly the operator. A new logic for executing the transaction with user data received from the payment facilitator is required.

The payment facilitator 1134 should

• implement the required service elements and interfaces;

• set up user profiles; • receive payment instructions to match the data to create a transaction;

• determine the payment method and submit the transaction to the pre-selected payment provider;

• generate acknowledgements for the transactions;

• generate and maintain logs of all transactions; and • provide back-end support to the customer care of the other parties.

The solution requires a database solution that will effectuate the matching of data and generate the payment instructions. The solution must be scalable in order to cope with a large volume of transactions. The system can run on any of today's widely used operating systems.

The database typically contains the user ID with a related payment profile, and the merchant ID or service ID with optionally a related profile. The payment facilitator must establish the interfaces between this system and the other parties involved in the payment chain, e.g. the operator, financial institution and merchants.

The payment facilitator (or a special third party) needs to generate the authentication and identification signs and send these to the merchants and could forward an encrypted PIN code for payments over larger amounts

For the end user, the present invention works with an existing SIM card and/or handset.

In case of a mobile phone as the POS terminal, it is preferred that the SIM vendor delivers a specifically programmed STK SIM card to the operator, and the network supplier implements the service elements for extracting and transmitting trusted payment data. The following services are possible:

• top-up payments for prepaid accounts at retail outlets;

• payments for goods and/or services at retail outlets with the operator, e.g. prepaid or post paid accounts; • payments for goods and/or services at retail outlets with a financial institution, e.g. financial institution, debit or credit card accounts, or a special prepaid financial institution account;

• Internet payment;

• reservations and payments for facilities, e.g. tennis courts; • payments for an entry fee;

• payments for public transportation tickets;

• parking fee payments; and

• transfer of money between accounts.

Figure 14 shows how data may be encrypted at the respective entities.

It is possible to provide security using blocks from security inherent in the various mobile telephony systems, location and positioning services, Internet security, and others such as, for example, SSL, PKI, and proprietary modules. GSM security standards are among the best in any industry and exceed today's standards for fraud protection of credit card payments. Ten years of operation and over 1 billion users have demonstrated the inherent security in the existing 2G and 2.5-G systems.

By integrating the mobile operator in the payment process, the operator's internal network information and mobile network security systems can be used. This provides security on par with or better than already deployed payment systems that don't use an operator.

PINs are preferably encrypted end-to-end. This means that all issues relating to the handling of PINs such as, for example, how many digits, management, method of issuing, and so forth, is at the discretion of the respective end entities (e.g. financial institutions). The encrypted PINs may be transferred transparently by the payment facilitator.

For small value purchases and/or payments, PINs may not be required. The payment system may allow customers to make purchases or payment of a designated number (e.g. two) per day without PIN authentication. Each transaction type could be tagged specifying whether or not a PIN would be required. Payments not requiring a PIN may be limited by value and or number of transactions over a specified period.

It is possible to implement a PIN system using one or more methods: • submission of a PIN as a part of the authentication and identification sign string that is dialled by the customer; or

• submission of the PIN through the keypad of the POS terminal or computer.

In the first case, if USSD is used, GSM security is implied. The existing GSM infrastructure does not provide end-to-end encryption of PINs (entered as a part of e.g. a USSD string) between the mobile phone user (customer) and the financial institution. However, by encrypting the PIN at the base station (BTS/BSC) level, a high degree of security should be achieved because the real user identity is not used. Instead an alias, the Temporary Mobile Subscriber Identity (TMSI) is used. TMSI is a GSM security feature providing user identity protection and is managed by the VLR or MSC/VLR. Although a modification to the base station infrastructure would be necessary, this approach would enable "near end-to-end" encryption of PINs using existing SIM cards and handsets.

When the POS terminal is used for PIN entry, the PIN can be encrypted using a Secure Access Module (SAM) in the POS. The financial institution could own the SAMs. Mobile phones used as POS terminals could use a special "merchant SIM card" with embedded SAM and POS application. By encrypting data in the respective channels a high level of security should be achieved.

As a result of this:

• the customer does not need to divulge their identity to the merchant or a merchant's terminal or computer; and

• in the authentication process, the data required is derived from two separate channels. The information in a single channel is not useful for fraudulent purposes.

The two channels may not be directly linked or connected. They may be physically different channels such as, for example, different telecommunications channels; or may be different logical channels. The two channels may be separate physically or logically. For example, the different channels may be over the one telecommunications link and techniques such as multiplexing and/or different encryption schemes used. More than two channels may be used. They may be separate telecommunications channels. The customer communicates directly with the operator, and the merchant communicates directly with the facilitator. The operator communicates with the facilitator. Thus, there may be no direct data link between the customer and the merchant. As such, the merchant cannot obtain data relating to the customer identity, PIN, or account details.

The two main vulnerabilities of the system are:

• insider crime using technically unsophisticated methods; and

• loss or theft of mobile phones

Technically, the system is immune from attacks by eavesdroppers on the mobile network, as well as from data intercepted at the POS. An attacker would need to simultaneously attack both channels.

It is not possible to launch traditional username/password attacks because the details of the user are never revealed to the merchant, the merchant's terminal, or computer. Even if the password were captured (using e.g. a key logger), it would be of no value as the attacker would not have access to the user's mobile phone for authentication.

Because two channels are used, the system may be vulnerable to service outages if one channel in not operating or if a denial of service attack is launched on any of the channels.

As is shown in Figure 15, the service is dependent on two separate channels that must be simultaneously available and functioning with the necessary back-end processes and connections. The four main critical connection paths for payment transactions are shown in Figure 15.

User experience, performance and reliability are all significant contributors to the overall success of a mobile payment service. Also, for troubleshooting it is important to be able to quickly locate in which part a failure has occurred. The following description briefly outlines the various connection paths and the associated acknowledgements.

Path 1-3 is the main path a customer will experience in the course of a transaction. Currently, many services using the mobile phone do not offer users an acknowledgement that their request is being processed. Instead, the delivery of the service has also constituted the acknowledgement. It is preferred that an acknowledgement be generated for every transaction attempt.

The method used for delivering acknowledgements and the content of the message delivered will depend on the network. Acknowledgements of normal successful transaction initiations could typically contain the message "Your transaction is being processed - please wait."

Failures in a mobile phone path are not uncommon and are typically caused by congestion. However, even under relatively light loads, it is "normal" for a small number of call set-up requests to fail because the Aloha protocol employed for initial network access requests uses a random access burst. Most handsets respond to such failures by returning to idle mode without displaying any error messages.

In the case of call set-up failure an acknowledgement should not be generated. The phone will return to idle mode. The user will be required to re-dial the code within a pre-determined time period if an acknowledgement is not received.

If users do not get connected they may attempt to dial the same number several times in succession. This does not constitute a problem as a transaction can be matched once only.

If error codes are used it will be possible for the operator to detect an incorrectly entered authentication and identification sign and to generate an error acknowledgement requesting the user to re-dial.

In some areas coverage is marginal. However, the signalling mechanisms in most networks are more robust than, for example, voice calls. If the signal is so poor that the user information cannot be extracted, an acknowledgement cannot be generated. In rare cases, the request might get through, but the acknowledgement might not. This does not constitute a problem if the transaction is properly concluded with a receipt being printed at or displayed at the POS terminal.

If there is a general failure of the mobile network, the mobile subscriber will become aware of this and will not be able to make telephone calls or payments.

Path 2-4 is the wire line path between the merchant's POS and the facilitator. Typically, if a POS does not receive a valid response, it will time out and issue a receipt stating that the transaction was unsuccessful. The time-out delay of the POS should be longer than the timeout delay of the facilitator.

Path 3-4 is the connection between the mobile operator and the facilitator. This is usually a leased line or an Internet connection using SSL. A break in this connection is not visible to the mobile subscriber or the merchant. If this connection is broken a match cannot be completed and the authentication/payment process will time-out at the facilitator. If an error message is not sent to the POS, the POS will also time out.

Path 4-5 is between the facilitator and the financial institution. Upon a successful match, the facilitator will forward the payment request (or if applicable generate and forward a payment request) to the financial institution. Once the request has been processed, the financial institution will send back the result of the payment request. A failure in this path will result in a time-out at the facilitator. Thereafter the facilitator can generate an error message to the POS and mobile subscriber.

The mechanism used by the network to accept and propagate the dialled codes through various network nodes will vary depending on the format of the codes and the type of network. In the GSM system, the available options are either USSD or to make a voice call that is terminated at the switch.

The facilitator is preferably an on-line database that needs to communicate with a small number of mobile operators (large volumes of transactions), many merchants (single transactions), and a small number of financial institutions (large volumes of transactions). Addition of routing information (i.e. where to send a matched transaction) can be done by the mobile operator or by the facilitator. If routing information is maintained by the facilitator, a database containing all users should be available.

New customers may be required to register. A formal contract may be required between the customer and the mobile operator that gives the permission to supply the user authentication information to other parties, and between the customer and each service provider. One or more hot buttons on the POS may be assigned for issuing of contracts. The customer signs by dialling the number printed on the slip. The mobile operator provides the user's details to the facilitator. Over the last decade mobile operators have developed their own procedures to assure the correct identity of their subscribers and Figure 16 is an illustration of several mobile networks in use at present, and the information obtained and retained by the operator for each call made. The information includes the caller ID, the dialled code (number), the time of the call, and the location of the call. The location will normally be of the base station first receiving the call.

In the case of a lost mobile phone, it is of no value for a thief to register the found handset as he does not know the name, or have any account details, of the original owner. A stolen handset should be reported to the operator to reduce the risk that the thief may try to register the phone for his own use. To eliminate this risk, it may be required that the subscriber has to register with his name or another credential that is only known to the original phone owner and the operator, e.g. the birth date. Once loss or theft of the handset is reported to the mobile operator or the facilitator, the account is blocked. Service should be resumed only after the operator has re-enabled the customer.

Authentication for other forms of transactions is similar to that for a payment system as described above. However, a financial institution may not be involved and the commencement of the transaction may be different, as is described with reference to Figure 6. Examples of cases where authentication at logon may be used are: logging on to a web site, confirming a web-based transaction, and logging on to an ISP. Figure 13 shows an authentication process according to the present invention when used for a logon to an application or the Internet. Here, again, the operator is also acting as the facilitator:

1 Log-in request sent from the computer being used by a user. This may or may not be the user's own or normally-used computer;

2 Facilitator generates and transmits authentication and identification sign to user's computer;

3 Computer displays log-on screen with authentication and identification sign and password entry field; 4 User enters authentication and identification sign on their mobile phone and sends the authentication and identification sign to the operator;

5 Operator receives authentication and identification sign from the user's mobile phone, and authenticates and identifies user; and

6 If required, user enters PIN. This may be before step 4. The advantage of using this authentication and identification process is that the user can log on to web sites at various locations such as, for example, Internet cafes, without risking the capture of their usernames and passwords.

To refer to Figure 17, there is shown the situation wherein an RF smart card is used in the system. Here, the smart card 1770 has two channels, at least one of which is secure, and that are separated logically. The smart card 1770 may be a stored value smart card, if desired or required.

The first step is after the commencement of the transaction where, as before, the facilitator 1734 sends the authentication and identification sign to the POS 1710. The POS 1710 then sends the authentication and identification sign to the smart card 1770, preferably by RF transmission. Therefore, the POS 1710 should be RF-enabled.

In the third step the smart card 1770 sends the authentication and identification sign, the user ID and the time, to the facilitator 1734. They may be encrypted with a first encryption key. This sending may be by use of the user's mobile telephone, the POS, or otherwise as required or desired. The smart card 1770 may communicate with the user's telephone in any known manner. The final step has the user entering their PIN code on the POS 1710 and the POS 1710 sending the authentication and identification sign plus the amount of the transaction and the PIN code (preferably encrypted with a second key) to the facilitator 1734. The facilitator 1734 can then approve a reject the transaction, and notifies the POS 1710 accordingly.

In this way the smart card 1770 is acting as the financial institution and/or operator.

As is clear, no matter the transaction concerned or whether or not a transaction is involved, for each preferred embodiment the principal steps in the authentication and identification process are the receiving of the authentication and identification sign over one telecommunications channel, and the sending of the authentication and identification sign together with user ID to the operator over a second telecommunications channel. The separation of the data over two separate channels, the inherent security of the GSM system, when combined with the use of a one-off authentication and identification sign, provides a level of security and ease of use not previously obtainable. Whilst there has been described in the foregoing description preferred embodiments of the present invention, it will be understood by those skilled in the technology that many variations or modifications in details of design, construction or operation may be made without departing from the present invention.

The present invention extends to all features disclosed both individually and in all possible permutations and combinations.

Claims

THE CLAIMS

1. A method for authenticating and identifying a user, whereby

(a) a first terminal communicates with a facilitator over a first channel and (b) a second terminal communicates with an operator over a second channel, the operator and the facilitator being able to communicate with each other, wherein

(c) no identity data of the user is required to be provided to the first terminal by the operator, the facilitator, or the second terminal;

(d) no identity data of the first terminal is required to be provided to the second terminal by the operator, the facilitator or the first terminal; and wherein

(e) any communication between the first terminal and the facilitator is not required to contain data regarding the identity details of the user or the second terminal; and

(f) any communication between the second terminal and the operator is not required to contain data regarding the identity details of the user.

2. A method as claimed in claim 1 wherein the facilitator generates a facilitator's message containing a one-use only authentication and identification sign to be used for a single authentication process; the facilitator sending the facilitator's message containing the authentication and identification sign to the first terminal using the first telecommunications channel.

3. A method as claimed in claim 2, wherein the first terminal receives from the facilitator the facilitator's message containing the authentication and identification sign in such a manner that the authentication and identification sign is passed to and entered in the second terminal, the second terminal sending the authentication and identification sign to the operator over the second telecommunications channel.

4. A method as claimed in claim 2 or claim 3, wherein the operator receives the authentication and identification sign from the second terminal, the authentication and identification sign having added to it at least one identification detail of the second terminal, and the operator sends to the facilitator the authentication and identification sign and the at least one identification detail of the.second terminal.

5. A method as claimed in claim 4, wherein the facilitator receives from the operator the authentication and identification sign and the at least one identification detail of the second terminal, uses the authentication and identification sign to retrieve the message, checks the authentication and identification sign in the message against the authentication and identification sign as received and, upon a successful match being made, the facilitator provides to the first terminal an authentication message containing authentication of the user, the authentication message being sent over the first telecommunications channel

A method as claimed in any one of claims 1 to 5, wherein the authentication and identification is part of a transaction system, the transaction system being one or more selected from the group consisting of a financial transaction, a payment transaction, a queuing transaction, a signing on or off for a service supplier, making a booking or reservation, arranging for a service by a service supplier, discontinuing a service by a service supplier, and logon to an application or the Internet

A method as claimed in any one of claims 1 to 6, wherein the first terminal is a terminal of a merchant

A method as claimed in claim 7, wherein the merchant's terminal is a point-of-sale terminal

A method as claimed in any one of claims 1 to 8, wherein the second terminal is a mobile telephone of the user

A method as claimed in claim 9 , wherein the at least one identification detail of the second terminal contains at least one information item obtained from a device selected from the group consisting of an RF smart card and a card of the mobile telephone, the card being at least one of a SIM card, URIM card or and an UICC card

A method as claimed in any one of claims 1 to 10, wherein the at least one identification detail of the second terminal includes at least one item obtained from the second terminal

A method as claimed in claim 2, or any one of claims 3 to 11 when appended to claim 2, wherein the authentication and identification sign is passed to the second terminal by the user viewing the authentication and identification sign on the first terminal or a display associated with the first terminal and entering the authentication and identification sign in the second terminal.

13. A method as claimed in claim 2, or any one of claims 3 to 11 when appended to claim 2, wherein the authentication and identification sign is printed at the first terminal and a print-out of the authentication and identification sign passed to the user for entry in the second terminal.

14. A method as claimed in claim 2 or any one of claims 3 to 11 when appended to claim 2, wherein the authentication and identification sign is sent from the first terminal to the second terminal by wireless transmission.

15. A method as claimed in claim 12 or claim 13, wherein the authentication and identification sign is entered in the second terminal by voice activation.

16. A method as claimed in any one of claims 1 to 15, wherein when the authentication and identification sign is sent to the operator, user data identifying the user is also sent.

17. A method as claimed in claim 16, wherein the user data is sent immediately prior to the authentication and identification sign.

18. A method as claimed in claim 17, wherein the operator first approves the user data before the authentication and identification sign is entered.

19. A method as claimed in claim 17, wherein the operator first approves the user data before the authentication and identification sign is sent.

20. A method as claimed in any one of claims 16 to 19, wherein the user data is a PIN.

21. A method as claimed in claim 2 or any one of claims 3 to 20 when appended to claim

2, wherein the authentication and identification sign contains a plurality of characters, each of the plurality of characters being selected form the group consisting of: a number, a letter, a graphic symbol, a mark of punctuation, a pronunciation key, and an ASCII character.

22. A method as claimed in any one of claims 1 to 21, wherein the facilitator and the operator are the same entity.

23. A method as claimed in any one of claims 1 to 21 , wherein the facilitator and the operator are separate entities.

24. A method as claimed in any one of claims 1 to 23, wherein the facilitator is part of a financial institution.

25. A method as claimed in any one of claims 1 to 23, wherein the operator provides a range of financial services on behalf of a financial institution.

26. A method as claimed in claim 2 or any one of claims 3 to 25 when appended to claim 2, wherein upon the user sending the authentication and identification sign to the operator, the operator provides an acknowledgement to the user.

27. A method as claimed in claim2 or any one of claims 3 to 26 when appended to claim 2, wherein the authentication and identification sign is randomly generated by the facilitator.

28. A method as claimed in claim 27, wherein the authentication and identification sign identifies the authentication process taking place, acts as a tracking device so that the facilitator and the operator can reliably track the authentication and identification process taking place through all steps in the process, and identifies the second terminal as being involved in the authentication and identification process.

29. A method as claimed in claim 16 or any one of claims 17 to 28 when appended to claim 16, wherein the user data identifies the user as being the person using the second terminal.

30. A method as claimed in any one of claims 1 to 29, wherein the user is not required to provide any identity information or data relating to the user or the second terminal to the first terminal nor to an operator of the first terminal and, if identity data or information regarding the user or the second terminal is provided by the user or the second terminal to the first terminal or the operator of the first terminal, such information or data cannot be entered into the first terminal, and cannot be sent to the facilitator by the first terminal.

31. A method for authenticating and identifying a user whereby (a) a first terminal communicates with a facilitator over a first channel and

(d) the facilitator sends the message containing the authentication and identification sign to the first terminal using the first telecommunications channel;

(e) the first terminal receives from the facilitator the message containing the authentication and identification;

(g) the second terminal sends the authentication and identification sign to the operator over the second telecommunications channel; (h) the operator receives the authentication and identification sign from the second terminal, the authentication and identification sign having added to it at least one identification detail of the user; (i) the operator sends to the facilitator the authentication and identification sign and the at least one identification detail of the user; (j) the facilitator receives from the operator the authentication and identification sign and the at least one identification detail of the user and uses the authentication and identification sign to retrieve the message; (k) the facilitator checks the authentication and identification sign in the message against the authentication and identification sign as received in step (h); and (I) upon a successful match being made in step (i), the facilitator provides to the first terminal an authentication message containing authentication of the customer, the authentication message being sent over the first telecommunications channel.

32. A method as claimed in claim 31 , wherein the second terminal is a mobile telephone of the user.

33. A method as claimed in claim 31 or claim 32, wherein the first terminal is a terminal of a merchant, and the first terminal is a point-of-sale terminal.

34. A method as claimed n any one of claims 1 to 33, wherein the first channel and the second channel are separated by at least one of: physically and logically.

35. A method as claimed in claim 34, wherein the first channel is a first telecommunications channel, and the second channel is a second telecommunications channel.

36. A method as claimed in claim 35, wherein any transmission over the second telecommunications channel is by use of a telecommunications system having signalling.

37. A method as claimed in claim 36, wherein the telecommunications system is GSM.

38. A method as claimed in claim 2 or any one of claims 3 to 37 when appended to claim 2, wherein the authentication and identification sign is tagged with at least one tag.

39. A method as claimed in claim 38, wherein the at least one tag contains data regarding one or more selected from the group consisting of: origin, destination, transaction, and authentication.

40. A method as claimed in claim 5 or any one of claims 6 to 39 when appended to claim 5, wherein the authentication and identification sign has a predetermined time limit within which the facilitator must perform the matching or the authentication and identification sign expires.

41. A method as claimed in claim 40, wherein the first terminal or any display device associated with the first terminal displays time remaining of the predetermined time limit.

42. A method as claimed in claim 5 or any one of claims 6 to 41 when appended to claim 5, wherein the operator performs a location match check based on a location of the second terminal and a location of the first terminal.

43. A method as claimed in claim 42, wherein the location match check is performed on the basis of the location of the second terminal according to a cell in which it is located or by GPS.

44. A method as claimed in claim 5 or any one of claims 6 to 43 when appended to claim 5, wherein the facilitator also performs a time match check.

45. A method as claimed in claim 2 or any one of claims 3 to 44 when appended to claim 2, wherein the authentication and identification sign is of varying length according to pre-set factors.

46. A method as claimed in claim 45, wherein the pre-set factors include one or more selected from the group consisting of: a nature of the transaction, a value of the transaction, and the location of the user.

47. A method as claimed in any one of claims 1 to 35, wherein at least one of the first channel and the second channel is secure.

48. A method as claimed in any one of claims 1 to 47, wherein an RF smart card is used in place of the operator.

49. A method as claimed in claim 24 or any one of claims 25 to 47 when appended to claim 24, wherein a stored-value RF smart card is used in place of the financial institution.

50. A method for authenticating and identifying a user whereby a first terminal is able to communicate with a facilitator over a first channel and a second terminal is able to communicate with an operator over a second channel, the operator and the facilitator being able to communicate with each other; wherein in the first terminal sends a request to the facilitator over the first channel and receives from the facilitator a facilitator's message generated by the facilitator and containing a one-use only authentication and identification sign to be used for a single authentication process; the first terminal passes the authentication and identification sign to the second terminal to enable: (a) the second terminal to send the authentication and identification sign to the operator over the second channel;

(b) the operator to receive the authentication and identification sign from the second terminal, the authentication and identification sign having added to it at least one identification detail of the user;

(c) the operator to send to the facilitator the authentication and identification sign and the at least one identification detail of the user;

(d) the facilitator to receive from the operator the authentication and identification sign and the at least one identification detail of the user and to use the authentication and identification sign to retrieve the message;

(e) the facilitator to check the authentication and identification sign in the message against the authentication and identification sign as received in step (d); and

(f) upon a successful match being made in step (e), the facilitator to send to the first terminal an authentication message containing authentication of the customer, the authentication message being sent over the first channel.

51. A method of sending and utilising a PIN wherein the PIN is sent to an operator before a user ID, the operator first searching by reference to the PIN to provide a limited number of possibilities, the operator then searching through the limited number of possibilities by reference to the user ID.