GB2372867A

GB2372867A - Transaction management system

Info

Publication number: GB2372867A
Application number: GB0105245A
Authority: GB
Inventors: Bradley A Howard; Alan Dursham; Dipen Patel; Gavin Mcardell; Daryl Hall; Geert Hilbrandie
Original assignee: Sonera Smarttrust Oy
Current assignee: Sonera Smarttrust Oy
Priority date: 2001-03-02
Filing date: 2001-03-02
Publication date: 2002-09-04
Also published as: GB0105245D0

Abstract

A transaction management system 100 for use with a mobile communication network 106, 108, 110, to enable a user of a mobile communication device coupled to the network to carry out a transaction, the mobile communication network having a network communication interface for sending and receiving messages to and from the user, and an accounting system 146 for storing and accessing account data relating to the user, the system 100 comprises a transaction authorisation system 136 coupled to the network communication interface for communicating with the user to obtain authorisation for the transaction, an instruction store 130 storing processor implementable instructions, a processor 128 coupled to the accounting system, to the transaction authorisation system, and to the instruction store for implementing the stored instructions, wherein the instructions stored in the instruction memory comprise instructions for controlling the processor to: receive a transaction request, communicate with the transaction authorisation system to seek user authorisation of the requested transaction, and communicate with the accounting system to update the account data relating to the user to perform the requested transaction if said user authorisation is obtained. Preferably the system includes a registration data store to store registration data relating to the user and the processor uses the registration data to enable the transaction. The system is suitable for facilitating transactions such as topping-up prepay mobile phone accounts and transferring credit and/or debit between such accounts. In an alternative embodiment the invention consists of transaction facilitation apparatus for a mobile communication network which includes providing cryptographically validatable communications with a subscriber terminal.

Description

TRANSACTION MANAGEMENT SYSTEMS AND METHODS This invention is generally concerned with transaction management systems and methods for use with mobile communications networks such as GSM, CDMA, IMT-2000 and other networks. More particularly it relates to apparatus and methods to facilitate transactions such as topping-up prepay mobile phone accounts and transferring credit or debit between mobile phone accounts.

Mobile communications networks, and in particular mobile phone networks, which operate on a prepaid basis are known. In such systems a user of a mobile phone connected to the network must pay in advance for calls made over the network. This is typically done by purchasing a voucher on which is printed a number to be entered on the user's mobile phone keypad in order to replenish the user's prepay credit account. In the UK at least one network operator, BT Cellnet (Registered Trade Mark) also provides a facility for topping-up a prepay account by dialling a phone number and then entering credit card and other details into the user handset. However, at present all such transactions are user initiated and are limited to replenishing an account associated with the phone number of the handset (or, more precisely, of a SIM card within the handset) used for the topping-up procedure. For a network customer to use their credit card to top-up someone else's mobile phone the customer would first have to register their credit card using the other phone before the other phone's account could be topped-up.

Present prepay systems also suffer from a number of other drawbacks. In particular, their implementation restricts the use of other features of the phone networks such as roaming and call forwarding. Furthermore, existing prepay systems are complex, expensive and difficult for mobile phone operators to install and offer only a very limited range of features. For example, real time balance information is often not available via the handset. Although the BT Cellnet system is able to provide balance information, because this system is handset-based the system can only be used with certain"prepay enabled"mobile phone handsets.

It is therefore desirable to be able to provide a system for managing transactions made using mobile phones, such as the topping-up of mobile phone accounts, which alleviates the above disadvantages, which has a relatively low operating cost overhead, and which is relatively straightforward to integrate with a mobile communications network operator's existing infrastructure. Preferably such a system would also provide a facility for a customer of the network to transfer credit from their own prepay phone account to another prepay phone account as either a one-off transfer, a regular, automated transfer, or, for example for corporate use, regular multiple transfers. Preferably such a system should also be able to initiate transfers or other transactions automatically.

The basis of the BT Cellnet prepay system, also operated by Philips and Brite, is an invention made by the US company Telemac, described in patent US 5,577, 100. This describes a system in which prepaid credit is stored in the handset together with tariff tables which determine the cost of a call per unit time. Accounting is carried out within the handset using the tariff tables and a real time clock and the handset deactivates when the credit is exhausted. Records of calls and call charges stored within the handset are communicated to the network operator. A handset user can securely top-up the credit stored in the phone, and the tariff tables can be securely updated by the network operator. Other patents assigned to Telemac include US 5,625, 669 which addresses problems of billing associated with rented phones, for example in rented cars, and describes means to retrieve call related information stored within the handset by means of an electrical connector. In Switzerland a prepay system known as SICAP is operated by Swisscom. Swisscom's patent applications include EP 0 827 119A, WO99/41919 and WO99/31868.

EP 0 827 119A describes a method for charging or recharging a data carrying card with a monetary value and describes the top-up of credit on a SIM card, by means of the GSM short message service (SMS), using a voucher. However, no mention is made of security or encryption. WO99/41919 describes a SIM card including a real time clock which can be synchronized with either the handset or the network, and describes tariff tables stored on the SIM, updatable over the air. However, this application does not refer to replenishing prepay accounts. WO99/31868 describes an identification card and a billing method using an identification card. The system uses a tariff server and tariff tables stored on the SIM card. The tariff tables are digitally signed and encrypted and can be updated using SMS or unstructured supplementary services data (USSD). Billing is determined by the SIM card and therefore no additional billing system is required in the infrastructure. A further Swisscom application, WO99/14933, describes a billing arrangement for a prepay system in which the use charge to be billed for a connection is determined before the connection is established, from statistical properties of earlier connections established by the user.

WO99/49647 relates to mobile phones with a prepaid card carrying tariff tables, in which encrypted messages are exchanged between the phone and the card and in which

the phone authenticates the prepaid card. WO97/40616 describes prepayment for wireless telephone services by means of smartcards, using both a SIM card and a prepaid card, secure communication between the two cards allowing the transfer of credit from the prepaid card to the SIM card. WO95/28062 describes a removable SIM for a mobile radio terminal and a call control method. The SIM card includes a tariff table and a credit record and means is provided for decreasing the credit on the SIM and blocking calls if the credit is below a minimum threshold. The call control method involves the network sending a message to the phone, which replies only if there is sufficient remaining credit on the SIM card, the network blocking calls from the phone if no reply is received.

US 5,301, 234 describes a radio telephone installation for prepayment operation with security protection. A first means of authentication generates a keyword dependent on the call charge for the current service and transmits it to the phone where a second means of authentication, on the SIM card, calculates an encrypted transform of the keyword using the subscriber's secret key. The encrypted transform is transmitted to the first means of authentication which checks the authenticity of the transform and blocks communication between the phone and its base station if its authenticity is not confirmed.

WO99/46926 describes an intelligent prepaid service card for a mobile phone which performs call charge calculations instead of the mobile phone network, so that the network does not need to transmit call charging information to the phone, thus enabling the network to handle calls for a roaming prepaid subscriber whose phone includes the intelligent service card. EP 0 656 733A relates to phone rental and describes call logging in cellular subscriber stations wherein calls are logged in a mobile station and transmitted to a system which generates a bill.

US 6,000, 608 Dorf describes a multi-function card system in which a single card serves as a prepaid phone card, a debit card, a loyalty card and a medical information card.

US 5,909, 486 Walker et al describes a method and apparatus for awarding and redeeming prepaid telephone time in which free calling time is credited to a membership card account in response to playing a slot machine. US 5,903, 633 Lorsch describes method and apparatus for prepaid phone card activation and billing in which an improved phone card has a magnetic strip for encoding prepaid phone card information adapted for reading by a point of sale terminal.

W098/25237 describes methods and apparatus for regenerating a prepaid transaction account in which an integrated transaction card has one side functioning as a prepaid telephone card and another other side functioning as an integrated transaction card such

as a credit card. WO99/03258 describes a prepaid card type cellular phone set in which a smartcard read unit for a prepaid card is provided on a cellular phone. WO96/4 1 462 describes a system and method for dispensing of a receipt reflecting prepaid phone services in which a central terminal receives inputs from an initiating terminal, obtains authorization for a request to purchase a specified amount of prepaid telephone services, and transmits data to the initiating terminal to print a receipt for the customer.

US 3,718, 764 Deschenes et al describes a terminal unit for a credit account maintenance system in which a central station responds to an enquiry message from a terminal unit at a remote station, accesses data from an account record, and replies to the enquiring terminal unit with the account's status. None of the above described prior art arrangements provides a transaction management system which can be relatively simply and inexpensively retro-fitted to an existing mobile phone network in order to facilitate a range of transaction services including credit transfers, top-ups of a user's own account and/or of others'accounts, top-ups of single and multiple accounts, user and system initiated top-ups and/or transfers, transaction monitoring and audit trail data gathering and the flexibility to handle other types of transactions such as payments for goods or services offered by other than the network operator. The present invention aims to address these outstanding needs.

According to the present invention, there is therefore provided a transaction management system for use with a mobile communications network, to enable a user of a mobile communications device coupled to the network to carry out a transaction; the mobile communications network having: a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the system comprising: a transaction authorization system, coupled to the network communications interface, for communicating with the user to obtain authorization for the transaction; an instruction store storing processor implementable instructions; a processor coupled to the accounting system, to the transaction authorization system, and to the instruction store for implementing the stored instructions; wherein the instructions stored in the instruction memory comprise instructions for controlling the processor to: receive a transaction request; communicate with the transaction authorization system to seek user authorization of the requested transaction; and communicate with the accounting system to update the account data relating to the user to perform the requested transaction if said user authorization is obtained.

The structure of the transaction management system enables a simple interface for the system with the existing network infrastructure, at a network communications interface for communicating with the user and at a network accounting system interface, such as a prepay accounting system interface, for performing the transactions. Where the system is used for top-up payments as well as for transferring credit between accounts, a third interface may be provided, to a payment system.

The transaction authorization system can be configured to provide confidentiality, authentication of the user and non-repudiation of the requested transaction. The transaction authorization system also reduces the risk of an unauthorized transaction should the phone or other mobile communications device be lost or stolen. Preferably the transaction authorization system requests the user to digitally sign a message sent by the system.

The transaction management system may be used with mobile communications networks including, but not limited to, networks based on TDMA (Time Division Multiple Access), FDMA (Frequency Division Multiple Access), CDMA (Code Division Multiple Access, such as cdmaOne), GSM (Global System for Mobile communications, and related networks such as DCS-1800 and PCS-1900), iDEN (integrated Digital Enhanced Network), GPRS (General Packet Radio Service), IMT2000 (International Mobile Telecommunications-2000, with direct spread or multicarrier Frequency Division Duplex), UMTS (Universal Mobile Telecommunication System), as well as other 2G, 2.5G, and 3G communication systems and private mobile radio systems such as TETRA. The transaction authorization system may comprise a transaction authorization server implemented as code stored in the instruction store and running on the processor or implemented as code running on a dedicated machine, as the skilled person will recognize. Preferably the transaction authorization system provides an authorization signal output comprising a physical signal, such as an electrical signal on a wire, or a software signal, such as a software flag bit indicating a true or false authorization condition, and the processor communicates with the accounting system in response to the authorization signal indicating that user authorization has been obtained.

The mobile communications network has an accounting system for storing and accessing account data relating to the user. In a preferred embodiment this is a mobile communications network accounting system storing network account data for the user, such as credit or debit account data relating to services provided by the network operator. However, the accounting system may instead be external to the mobile communications network, albeit associated with the network, to allow a user of the network to settle an account with a third party provider of goods or services. Such a third party would normally have a contractual arrangement with the network operator to enable payments to be made via the mobile communications network. Thus, for example, a gas supplier might enter into a form of partnership with a mobile communications network operator to allow a user or customer of the network to pay his or her gas bill using a mobile phone or other communications device. Such an arrangement is particularly advantageous for making so-called micropayments, that is, payments which are small so that, for example, the overheads of a credit card transaction are a sufficient proportion of the total payment to make this method of payment undesirable. However, when made using the transaction management system the overheads are reduced and the payment of smaller sums is still cost effective. The stored account data is preferably data indicating the balance of an account held by the user, such as a monetary balance, a balance of available call time or some other balance such as a balance indicating a quantity of data which the user is able to download or otherwise access.

The transaction request may come from the user via the network communications interface or may be initiated by the system, for example, to automatically initiate a topup payment when the user's account balance is below a threshold, or to make regular payments to an account, such as monthly subscription payments. The transaction request preferably includes transaction data specifying details of the transaction to be performed but, in some embodiments, the transaction details may be assumed if the transaction is of a preset type.

Once a transaction request has been received the transaction authorization system seeks user authorization of the requested transaction. If user authorization is obtained the transaction authorization system may automatically trigger performance of the requested transaction. Alternatively code running on the processor may determine the outcome of the user authorization request from the authorization signal output, again to perform the transaction if authorization is obtained.

In a preferred embodiment the processor is further coupled to the network communications interface and the transaction request is received by the processor from the user via the network communications interface. In this embodiment both the processor and the transaction authorization system use the same gateway or interface to the communications network, for example a wireless Internet gateway for the network, although the processor and transaction authorization system will, in many embodiments, have separate physical or logical connections to the interface or gateway. Connecting the processor to the network communications interface allows the processor to communicate with the network user performing the transaction to collect transactionrelated data from the user, such as data specifying which account or accounts to top-up, and by how much. This simplifies the user interface to the system and allows, for example, a menu driven arrangement in which the user is presented with transaction options to lead the user through the transaction.

In a preferred embodiment the processor is coupled to the network communications interface over the Internet, which simplifies interfacing between the communications network and the transaction management system. Other interfaces such as, for example, an interactive voice response (IVR) interface can however be used in addition to or as an alternative to an Internet interface. In a preferred embodiment a user interface server, such as a web server, is coupled between the processor and the network communications interface, to format data received from the processor as pages of Internet data. The Internet data may comprise HTML (Hypertext Markup Language) web data, WML (Wireless Markup Language) data or other Internet data. Preferably the transaction management system also includes a registration data store to store registration data relating to the user. This registration data may then be used to enable the requested transaction.

The registration data store may store permission data relating to permitted transactions, or payment data for making a payment associated with a transaction, or both. Thus the registration data may be used to enable a transaction either by checking the requested transaction against permitted transaction types and options, or by presenting the user with a series of options so that the user can only select transactions which are permitted, or by providing payment data to a payment authority to enable a transaction to take place. The transaction may be for the user's own account or for another account and may relate to a payment or to a transfer between two accounts. It can therefore be seen that there are a number of ways in which the registration data may be used to enable a transaction,

and that the transaction may be enabled with either an"internal"authority, such as the network operator itself, or an"external"authority, such as a payment clearing authority.

Where the transaction is enabled with an external authority registration data relating to the user must be registered with the transaction management system before the system can be used. In most embodiments a user will register his or her own data but where, for example, the registration data store holds permission data specifying to which other users'accounts the user may transfer credit, those other users may instead register their permission to receive credit transfers with the system.

The registration data store may also hold a transaction history and other user-related data, to provide marketing information such as data relating to a user's spending habits and/or collective data for a plurality of users.

Where the transactions include transfers between network accounts, the permission data may specify between which accounts, and in which direction, such transfers are allowed.

Global business rules may also govern such transfers, for example, to prevent a transfer of credit between call and subscription charges. In one embodiment the permission data comprises data identifying at least one other user to which at least part of an account balance may be transferred by the user making the transaction. More generally, however, transfers between different accounts held by a single user may also be permitted, such as transfers between accounts relating to different types of services (for example, voice calls, SMS and data calls) and transfers between charges against different phone numbers assigned or belonging to the single user. In many embodiments transfers of credit from a first account to a second account will be the usual or only form of transfer, but other forms of transfer may also be implemented.

These may include the transfer of customer loyalty or reward points, the transfer of debit, the transfer of unused or"free"time, and the transfer of other tokens exchangeable for goods or services. In a preferred embodiment the user initiating the transaction transfers part of his or her account balance to the account balance of a second user, such as a parent transferring credit to a dependant child. Preferably multiple such transfers are permitted to, for example, top-up the accounts of multiple dependants or, in a corporate structure, to allow an Account Manager to control expenditure on mobile communications services by his or her staff. In this way the system operates as a payment controller.

In a particularly preferred embodiment the transaction request comprises transaction data specifying what part of the balance of a prepay mobile phone account to transfer to a second user, and the processor operates to send this data to a prepay network accounting system to perform an account top-up transaction.

It will be understood from the above that the transaction management system preferably includes an interface to a payment system. In a preferred arrangement, a gateway or interface to this system is established by means of a connection to a gateway or interface of the mobile communications network. Such an interface is normally present for use by the network operator, and interfacing to the payment system via the mobile communications network infrastructure simplifies installation of the transaction management system.

With such an arrangement the transaction management system needs only three. interfaces, all connecting with existing interfaces present in the mobile communications network. More specifically, these are an interface to the operator's existing network accounting (prepay) system, an interface to the operator's existing payment gateway, and a front end interface for communicating with the user, which can be straightforwardly implemented by means of a connection to the Internet. In practice, the transaction authorization system may have a separate, secure physical or logical link to a network interface for communicating with the user requesting the transaction, as described in more detail below. However, since the transaction management system is normally physically located near the network communications interface even use of a separate physical link does not normally present any installation problems. As outlined above, the registration data preferably includes payment data for making a payment using the payment system. Such payment may comprise data selected from a credit, debit or Switch (registered trade mark) card number and expiry date, user identification data, and data indicating to whom payment should be made. Some or all of this data is sent to the payment system to make a payment and an authorization code is received back from the payment system to confirm that payment has been or will be made. Thus, to make a payment, the processor reads payment data from the registration data store and writes payment data, including charging data for the transaction, to the payment system.

Preferably a payment is only made after the transaction authorization system has confirmed the user's authorization of the transaction or, equivalently, verified the user's identity. This reduces the risk of fraud should the user's mobile phone be lost or stolen.

Payments made by the user may be for topping-up his or her own account or accounts, or for topping-up dependants'accounts, or for making other payments, such as paying bills or making micropayments.

Where payments are being made on behalf of other users the permission data in the registration data store may be used to determine to or on behalf of which accounts the user may make payments such as top-up payments. In a preferred embodiment the user is presented with menu options, determined using the permission data, corresponding to the allowed transactions, for selection by the user. In other embodiments the user's requested transaction is merely checked against the permission data.

In a preferred embodiment of the transaction management system program code and an associated database is provided storing one or more business rules which govern types or classes of transaction common to groups of users. Such business rules may include a rule to send an advertising message to a mobile phone at the beginning or end of a topup procedure and/or a rule to warn the user of impending expiry of a payment method, such as a credit card.

Transactions may be initiated by the user or by the transaction management system.

Thus in one embodiment the transaction management system includes code to receive an account status signal comprising account status data, such as a low credit balance warning, from the network accounting system, and to send notification of the account status to a network user. The system may also initiate a relevant transaction using the account status data, for example, to top-up an account. Where a low balance notification is received on a dependant's account, a message may be sent to the account payer instead of, or in addition to, a notification to the account holder, as in this situation it is the person registered to make payments on behalf of the account who will normally make the top-up transaction. The system may also be configured to prompt a user and/or initiate a transaction at regular time intervals, for example, to make a monthly top-up payment or settle a monthly bill.

In order for a user to carry out transactions involving other users'accounts, such as topping-up another user's account, it is preferable that the other users'authorizations are obtained in advance. Thus the system preferably includes code to receive a first user's request to register permission for a specified type of transaction with another user's account, and code to then seek the other user's permission for that type of transaction before corresponding permission data is entered in the registration data store.

Permission may be granted by means of, for example, a digital signature.

In a preferred embodiment of the transaction management system the transaction authorization system is coupled to the network communications interface by a secure link. Thus the transaction management system may be coupled to the network communications interface for communicating with the user by a combination of a secure link for authorizing transactions and a less secure link, such as an unencrypted Internet connection. The less secure link may be used for general communications with the user relating to the transaction, such as presenting the user with menu options and confirming to a user that a transaction has been effected. The transaction request may be transmitted over the less secure link, but in a preferred embodiment verification and authorization of the request is carried out using the secure link to the mobile communications network.

The secure link may comprise a logically secure link such as the Netscape (registered trade mark) secure sockets layer (SSL) protocol, or a physically secure link such as a dedicated connection from the transaction authorization system to the network communications interface, or a private local area network (LAN) or wide area network (WAN). When the secure link is made over the Internet HTTPS (HTTP, secure) may be used. Since the transaction management system will often be physically co-located in the same building as the network communications interface, providing a dedicated line or a private LAN/WAN connection is generally not difficult. The aim is that data relating to the authorization or verification of a user should be sufficiently well protected to reduce the likelihood of an unauthorized third party passing themselves off as an authorized user to an acceptable level. The transaction authorization system preferably stores at least one cryptographic key for each user, and comprises code for sending a message over the secure link to the user, receiving an encrypted version of the message back and determining, using the stored key, whether the encrypted message has been encrypted by the user. This code may be stored in the same instruction store as the code for the transaction management system processor, or may run on a separate, dedicated system.

The encrypted message may comprise or include a digital signature such as the US National Institute of Standards and Technology (NIST) digital signature standard.

Alternatively the encrypted message may be generated using other symmetric or asymmetric crypto systems, such as the US Data Encryption Standard (DES) (equivalent to ANSI X3. 92-1981), or RSA-based public key cryptosystems. Further cryptographic algorithms which may be employed include Diffie-Hellman, IDEA (International Data Encryption Algorithm) and the planned NIST Advanced Encryption Standard (AES).

The message sent to the user from the transaction authorization system may be generated by the transaction authorization or may be generated elsewhere and forwarded to the user by the transaction authorization system. A message originating from the transaction authorization system may be a random message, but preferably the message sent to the user is one which has meaning to the user. Thus, preferably, the transaction management system includes code to generate a meaningful message for encryption or signature by the user, such as a message specifying the type of transaction (e. g."topup"), the amount of the transaction, and the recipient. Such a message may be presented to the user on the phone's display or presented as a voice message. Where the mobile communications network is a GSM-based mobile communications

network the GSM PIN 1 (or CHV1) value may be advantageously employed for message encryption by a user. Use of the PIN1 value is secure and straightforward to implement as this value is never sent over the air and because no additional key management is needed on the part of the network operator as the PIN 1 function is part of the GSM standard and thus should already be supported by the operator's network. Similar advantages may be obtained by using corresponding user encryption keys in other mobile communications networks.

Advantageously communications between the network communications interface and the user employ the GSM short message service (SMS) to encode conventional hypertext transfer protocol (HTTP) over TCP/IP, which will then also support the transport of WML (Wireless Mark-up Language) and WTLS (Wireless Transport Layer Security). A range of different wireless bearers may be used in other implementations of the system, including, but not limited to, general CSD (Circuit Switched Data) systems, CDMA, such as cdmaOne and CDMA2000, and TDMA, such as Motorola's (registered trade mark) iDEN technology. In another aspect the invention provides a data carrier carrying processor implementable instructions for the transaction management system. The data carrier may comprise any conventional data carrier or storage device such as a disk, for example, a hard or floppy disk or CD-ROM, a ROM, or an electrical signal carrier.

According to another aspect of the invention, there is provided a method of using a mobile communications network to enable a user of a mobile communications device coupled to the network to perform a transaction; the mobile communications network having: a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the method comprising: receiving a transaction request; communicating with a transaction authorization system coupled to the network communications interface to communicate with the user to seek user authorization of the requested transaction; receiving an authorization signal from the transaction authorization system; and communicating with the network accounting system to update the account data relating to the user to perform the requested transaction in response to the authorization signal indicating that said user authorization has been obtained. The invention also provides program code for controlling one or more processors to implement the method. This method broadly compliments the above-described transaction management system and provides similar advantages.

According to a further aspect of the invention, there is provided a method of using a mobile communications device coupled to a mobile communications network to perform a transaction, the method comprising sending a URL request over the mobile communications network to a transaction management system, to request the transaction; and receiving an Internet data page from the transaction management system indicating whether the requested transaction was performed. The mobile communications device may, for example, comprise a mobile phone.

In a preferred embodiment of this aspect of the invention, the URL address specifies a transaction to be performed. Thus, preferably, the URL address comprises data indicating one or more of an MSISDN number of an account to top-up or transfer from, in the case of a transfer, an MSISDN number of an account to transfer to, and an account balance or monetary amount to top-up the account by or transfer between the accounts.

Preferably the method further comprises receiving a message from the transaction management system over the mobile communications network; inputting a code number into the mobile communications device; using the code number to process the message to generate encrypted data; and sending the encrypted data to the transaction management system over the mobile communications network to confirm the requested transaction. This allows the identity of a user of the mobile communications device requesting the transaction to be verified with enough confidence to be able to perform the requested transaction.

In a still further aspect, the invention provides transaction facilitation apparatus for a mobile communications network, to facilitate performance of a transaction by a user of the network; the mobile communications network having a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the apparatus comprising: a registration data store to store registration data relating to the user; an instruction store storing processor implementable instructions; a processor coupled to the network communications interface, to the accounting system, to the registration data store, and to the instruction store for implementing the stored instructions; wherein the stored instructions comprise instructions for controlling the processor to: receive a transaction request from the user over the network communications interface; retrieve registration data relating to the user from the registration data store; use the registration data to determine an allowed transaction for the user; and communicate with the accounting system to perform the requested transaction if the transaction is allowed for the user. Receiving the transaction request and retrieving the registration data may be performed in either order. The invention also provides a corresponding method of facilitating a transaction using a mobile communications network; the mobile communications network having a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the method comprising: receiving a transaction request from a user of the mobile communications network over the network communications interface; retrieving registration data for the user from a registration data store; using the registration data to determine an allowed transaction for the user; performing the requested transaction using the accounting system if the transaction is allowed for the user.

The registration data store facilitates implementation of transfers between accounts and provides a means whereby a user can make payments to other users'accounts, broadly as outlined above with reference to the transaction management system.

In a preferred embodiment the transaction facilitation apparatus includes a transaction authorization system, as described above, coupled to the network communications interface for seeking user authorization of a requested transaction. Preferably the network communications interface comprises an interface to the Internet and preferably the processor is coupled to the network communications interface via a web server. The transaction authorization system may be provided with a secure link to the network communications interface and, in preferred embodiments, this link is separate from the connection via the Internet.

According to a still further aspect of the invention, there is provided a transaction management system for use with a mobile communications network, the mobile communications network having an accounting system for storing and accessing account data relating to the subscriber, the system enabling a subscriber to the network to carry out a transaction modifying a balance of an account held by the subscriber, the system comprising: a transaction authorization system having an interface to a computer network, and for providing cryptographically validatable communications with a subscriber terminal couplable to the computer network, for obtaining authorization for the transaction; an instruction store storing processor implementable instructions; and a processor coupled to the accounting system, to the transaction authorization system, and to the instruction store for implementing the stored instructions; wherein the instructions stored in the instruction memory comprise instructions for controlling the processor to: receive a transaction request; control the transaction authorization system to communicate with the subscriber terminal to seek cryptographically confirmable user authorization of the requested transaction; and communicate with the accounting system to update the account data relating to the user to perform the requested transaction if said user authorization is obtained.

This transaction management system allows a user to top-up and/or transfer account balances using a terminal connected to the Internet instead of or in addition to a mobile phone. These and other aspects of the invention will now be further described, by way of example only, with reference to the accompanying figures, in which: Figures la to c show, respectively, elements of a schematic diagram of a mobile communications network including a transaction management system according to an embodiment of the present invention; Figure 2 shows an illustration of dataflows between a mobile phone and a topup/transfer machine of a transaction management system; Figure 3 shows a mobile phone menu structure for a transaction management system in which a user is able to top-up the accounts of dependant users; Figure 4 shows a flow diagram for a registration process implemented on a customer terminal, for a credit top-up/transfer system; Figures 5a and b show a flow diagram of a top-up process on a mobile phone; Figures 6a and b show a flow diagram of a top-up process on a top-up/transfer machine; Figure 7 shows a flow diagram of a portion of a top-up process implemented on a web server; Figure 8 shows a flow diagram of a process implemented on a top-up/transfer machine for initiating a top-up of a network user's account; Figures 9a and b show a flow diagram of a transfer process on a mobile phone;

Figures l Oa and b show a flow diagram of a tr Figures lOa and b show a flow diagram of a transfer process on a top-up/transfer machine; and Figure 11 shows a flow diagram of a portion of a transfer process implemented on a web server. Referring first to Figures la to c, these figures show a mobile communications network incorporating a transaction management system 100. Figures la to c form a single drawing in which the same elements appearing on different sheets are indicated by the same reference numerals.

In Figure la a Base Transceiver Station (BTS) 106 of a GSM (Global System for Mobile Communications) network is in rf communication with a Mobile Station (MS) 102 across an air interface (in a GSM network, known as the Um interface). BTS 106 forms part of the GSM operator's network 108, details of which are not shown in Figure la for clarity. In general, however, a plurality of BTSs are served by a Base Station Controller and a plurality of such base station controllers are digitally linked to a mobile switching centre (MSC). The MSC is, in turn, connected to the public switched telephone network (PSTN), to a plurality of databases to provide call routing and roaming functions, and to other mobile switching centres over a high bandwidth digital network. Such an arrangement will be well-known to those skilled in the art. However, for further details of the GSM specification reference may be made to the GSM standards published by the European Technical Standards Institute (ETSI), such as standards GSM 01-12, which are hereby incorporated by reference. The invention described herein is not limited in its applicability to GSM networks but, for the sake of convenience, operation of an embodiment of the invention will be described in the context of a GSM-based network. In particular, the invention is also suitable for use with the US cdmaOne (registered trade mark)-type networks.

GSM and cdmaOne networks are so-called"2G"or"second generation networks". The invention is also suitable for use with later systems such as so-called 2.5G and 3G networks. An example of a 2.5G network is the general packet radio service (GPRS), which is based upon packet switched rather than circuit switched data. An example of a 3G network is the US-based CDMA2000 system. More generally, 3G networks are defined by the International Mobile Telecommunications (IMT) 2000 standard, available from the International Telecommunications Union at www. itu. int, a copy of which standard is hereby incorporated by reference. IMT-2000 is basically a wide band CDMA system with Frequency Division Duplex operation, although implementations of the system in Europe, the USA and Japan differ from one another in details of the technical implementation of the standard. In a 3G network a so-called Node B performs the function of BTS 106. Third generation networks also incorporate some additional systems such as Media Gateways, Serving GPRS Support Nodes, and Gateway GPRS Support Nodes.

As shown in Figure 1 a, a GSM network includes a Short Message Service Centre (SMSC) 110 to support the GSM Short Message Service (SMS). GSM SMS messages are defined in ETSI documents GSM 03.38 and GSM 03.40, and such messages comprise up to 160 7 bit characters or 140 8 bit characters. Messages with 8 bit characters are used for so-called smart messaging and over the air (OTA) services such as defining Wireless Application Protocol (WAP) settings. SMS messages may originate from or terminate at mobile station 102 and may be stored on a SIM (subscriber identity module) card, described in more detail below. In a GSM network SMSC 110 interfaces to the network at an SMS-GMSC (GSM Mobile services Switching Centre) for mobile terminating messages and at an SMS-IWMSC for mobile originating messages. In other networks, such as 3G networks, other interfaces to the network may provide digital data communication facilities for mobile station 102.

As illustrated in Figure la, mobile station 102 comprises mobile equipment, for example, a handset, and a (removable) SIM card 104. SIM card 104 enables mobile station 102 to connect to operator network 108, and specifies to which services a user of MS 102 has access. In a GSM network, generally speaking it is SIM card 104 which controls access to the network rather than the mobile station handset. The SIM card is therefore specified to be protectable by a 4 digital personal identification number, the GSM PIN1 key. A user is identified to the network by an International Mobile Subscriber Identity (IMSI) which is stored on the SIM card.

As illustrated, SIM card 104 includes code for a wireless Internet browser (WIB) and cryptographic code to provide encryption and a digital signature for messages sent by a user from mobile station 102, to a recipient, via operator network 108. Such SIM cards are available from SmartTrust of London, UK and Helsinki, Finland (www. smarttrust. com). A SIM card of this type, that is, including a wireless Internet browser on the SIM, is manufactured by SmartTrust. An additional menu option area of the SIM is programmed such that the wireless Internet browser appears as an additional menu option on the phone handset. An account field on the SIM defines what is effectively the WIB home page by pointing to a delivery platform machine 112, described in more detail below. When accessed, the wireless Internet browser code displays a list of menu options, each with an associated URL, not dissimilarly to a conventional web browser. This provides a wireless Internet gateway (WIG) with a menu structure which allows a user to access a range of services which may, but need not be, controlled by the network operator.

The cryptographic code on the SIM may be selected according to the degree of confidence and security required. Thus in one embodiment the cryptographic code comprises code to implement the US Data Encryption Standard (DES) algorithm (FIPS46, FIPS-47-1, FIPS-74, FIPS-81, US National Bureau of Standards) or a variant of this, for example Triple DES (3DES) in which 3 keys are used successively for additional security. Alternatively a more secure but computationally more intensive public key infrastructure (PKI), may be employed such as SET, Verisign, ICETEL, or the US Federal System. In PKI a public key (or asymmetric) algorithm uses a pair of keys, one "private"and one"public". A message encrypted with the public key can only be decrypted with the private key, and vice versa. To prevent an individual posing as someone else, an individual may prove his identity to a certification authority, which then issues a certificate signed using the authority's private key, and including the public key of the individual. The certification authority's public key is widely known, and therefore trusted, and since the certificate could only have been encrypted using the authority's private key, the public key of the individual is verified by the certificate.

Thus an individual, such as a user of operator network 108, can verify or authenticate his or her identity by employing SIM 104 to encrypt or sign a message with his or her private key (which can be verified with the user's public key). A common public key algorithm is the RSA (Rivest, Shamir, and Adleman) algorithm and one common Internet standard for digital certificates is the ITU (International Telecommunications Union) X. 509 standard. A SIM card which provides digital signatures using a 1024 bit RSA algorithm, employing dedicated hardware, is available from SmartTrust. PKI provides strong non-repudiation, data integrity, authentication, and confidentiality.

The digital signature code is used to verify that a user of the system is authorized to perform a transaction, as is described in more detail below. The skilled person will recognise that it is not essential that any particular digital signature or encryption process is implemented on the SIM card and, in some embodiments, the requirement for cryptographic user authorization may even be dispensed with entirely.

In the embodiment illustrated in Figure la, the wireless Internet browser provides a wireless Internet gateway using SMSC 110 and delivery platform machine 112. Broadly speaking, the SMSC 110 and delivery platform 112 comprise separate computer systems, linked either by a direct physical connection or by a logical connection such as Internet Protocol (IP) over an X. 25 network or the Internet.

A GSM SMS message comprises metadata as well as the message string itself. This metadata includes, inter alia, a sender address (or phone number), an SMSC address (or SMS service centre phone number), message length data, a time stamp, and other data, for example, protocol data. The SMS message also includes a destination address which may be the phone number of another mobile phone, or an account number; account numbers are assigned to the direct SMSC physical or logical connections described above.

A transaction management service provider has a connection to SMSC 110 and when the SIM wireless Internet browser is started a destination address is retrieved from the SIM card to identify the transaction management service provider account to which SMS messages are to be directed. The wireless Internet browser communicates with delivery platform machine 112 using SMS messages and the delivery platform machine interprets these messages to provide access to Internet 118. Thus the wireless Internet browser sends encoded messages using the GSM SMS service to delivery platform machine 112 and this machine then decodes these messages and retrieves data at the requested URLs (Uniform Resource Locators). The retrieved data is then encoded, sent back to the wireless Internet browser of the mobile station 102, decoded by the wireless Internet browser, and displayed or otherwise output to the user of mobile station 102.

The wireless Internet browser translates the encoded instructions and data into GSM SAT (SIM Application Tool-kit) commands which are then executed by mobile station 102.

Delivery platform machine 112 provides a wireless Internet gateway (WIG) which translates, inter alia, WML (Wireless Markup Language) code from Internet 118 into compressed byte code for transmission using SMS to the wireless Internet browser. In other mobile communications networks a simplified interface to Internet 118 may be possible where, for example, the network provides for more direct access to Internet data. The US cdmaOne system does not use SIM cards but for such systems other conventional means may be employed for accessing the Internet 118, such as are well known to those skilled in the art. The invention is not restricted to use of a wireless Internet browser which operates using the GSM SMS service (or a similar service), and other gateways to the network such as a Wireless Application Protocol (WAP) gateway or an i-mode gateway for use with NTT DoCoMo (registered trade mark)-type networks may be employed.

As the skilled person will know, WAP includes a mandatory security layer, WTLS (Wireless Transport Layer Security), which broadly corresponds to the Internet Secure Sockets Layer (SSL), and this may be used to provide user authorization/verification in some embodiments.

Broadly speaking, the function of delivery platform machine 112 and the SIM's wireless Internet browser is to provide mobile station 102 with an interface to the Internet 118 for WML applications and, more generally, content provided by means of HTTP (or HTTPS) over TCP/IP.

In more detail, and referring particularly to the wireless Internet browser/delivery platform embodiment of the invention in a GSM network, the delivery platform machine 112 includes delivery platform code 114 and has an SQL link to an associated delivery platform database 116. As mentioned above, the delivery platform machine 112 also has IP (Internet Protocol) ports to SMSC 110 and to an X. 25 network, the Internet 118 in the illustrated example. In one embodiment delivery platform machine comprises a SUN Ultra Enterprise 450 running SUN Solaris 2.6, and database 116 is implemented using Oracle 8.1. The delivery platform machine 112 has provision (not shown) for managing SMS charging records in ASM. 1 format, and for alarm handling according to the X. 733 standard.

The delivery platform code 114 comprises code to receive SMS messages from mobile station 102 and to convert these from compressed byte code to ASCII data. The code then reads this data to retrieve the required instruction, executes the instruction, and retrieves the result. The delivery platform code converts the results to an SMS message with the address of mobile station 102 as the destination address. This SMS message is then sent to SMSC 110, which forwards it to mobile station 102, where it is interpreted by the wireless Internet browser on SIM 104 to, for example, display data on a user's phone.

Where the instruction to be executed comprises a URL the delivery platform machine 112 sends an HTTP request to the appropriate web server and returns the content at that URL. The format of the returned content is preferably adapted for a display on a mobile phone. Other instructions implementable by the delivery platform code include an instruction to download additional program code to SIM 104 and a set menu list instruction to define a menu list for SIM 104.

Delivery platform database 116 comprises, inter alia, data relating to SIM cards of system users who are connectable by means of operator network 108. The database is accessed using a mobile subscriber's MSISDN (Mobile Subscriber ISDN), which is the directory number dialled to reach a mobile subscriber. Database 116 is preferably maintained by the network operator as a subscriber's phone number (i. e. MSISDN) does not necessarily always correspond with a given SIM identity (International Mobile Subscriber Identity).

Each entry in database 116 includes SIM profile data specifying, for example, the application menu options which are available (corresponding to options defined by the delivery platform set menu list instruction mentioned above), and SIM data including data identifying the SIM manufacturer and version. The SIM data is used, inter alia, for converting instructions and data to byte coded SMS messages.

To implement the transaction management functions which are herein described the delivery platform machine 112 (or other Internet access means) accesses web pages on a web server 120 also coupled to Internet 118. The structure of the components providing these functions is illustrated in Figures 1 b and 1 c. Each application menu item displayed by the mobile station wireless Internet browser has an associated URL (Uniform Resource Locator) which accesses a page on web server 120, which then performs the requested function.

In some cases the URL returns data for a subsequent menu option, navigating the user through a series of preselected options. Other URLs return data values, such as the balance of an account. Still further URLs perform actions such as transferring part of an account balance from one user to another user, or effecting a payment to top-up a user account. In general each function has a separate URL for accessing separate pages of data and code on web server 120.

These URLs may be thought of as instructions which return a value. Because the values returned by the URLs are dynamic, that is not constant, when web server 120 receives a URL request over Internet 118, the web server itself sends a further URL request to another machine which then returns the required data for web server 120 to return a web page with the requested data to delivery platform machine 112 and, eventually, to mobile station 102 for display to the user.

Referring to Figure I b, it can be seen that web server 120 is coupled to a top-up/transfer machine 128 by means of a private IP (HTTP) network 127. The top-up/transfer machine 128 comprises a suitably programmed general purpose computer and, in practice, web server 120 and top-up/transfer machine 128 may be implemented-by separate programs on a single computer system, as will be understood by those skilled in the art.

In Figure I b, web server 120 is coupled to presentation layer code storage 122 which comprises Java server pages. These Java server pages (JSPs) provide a user interface in either HTML or WML. Separating web server 120 and JSPs 122 from top-up/transfer machine 128 keeps the transaction management system's user interface broadly speaking independent from the application functions provided by top-up/transfer machine 128.

This simplifies customization of the system for different networks and deployments.

For example, the language in which the user interface is presented can be changed simply by calling different JSP pages. Code other than Java may be employed, but Java has the advantage that the presentation layer may be kept relatively independent of the hardware on which it is implemented.

The presentation layer code preferably operates to provide a variety of user interfaces including one or more of an interface based upon delivery platform machine 112, a world wide web-based interface, a WAP-based interface and an SMS-based interface.

Preferably none of these front-end interfaces includes client-side scripting. This facilitates portability and provides greater independence across front-end platforms.

The top-up/transfer machine 128 is coupled to top-up/transfer machine code storage 130, which stores code to provide transaction management functions for the system.

Four main functions are implemented, a function to return the balance of a user account, a function to top-up an account, a function to transfer all or part of an account balance from one account to another, and a function to allow a user or a so-called dependant to register with the system. Subsidiary functions include administration functions. All these functions are initiated by calls to web pages made to top-up/transfer machine 128, made by the presentation layer code on web server 120 using HTTP. The code in storage 130 may be termed application layer code and this code implements the transaction logic and provides session handling functions. In a preferred embodiment the interface for the presentation layer code is provided by Servlets which implement the application logic and Enterprise Java Beans (registered trade mark) to implement the business logic. The Servlets and Enterprise Java Beans (EJBs) run within a container application 132 which provides life cycle management, security, deployment, naming and run time services to the components it contains. Further information relating to the implementation of Enterprise Java Beans within a container may be found at http ://java. sun. com/j2ee. The Servlets have fixed URLs, run Servlet code when their URL is called, and normally return data values. The Servlets call the EJBs, multiple copies of which run inside the container 132. Examples of EJBs which may be invoked by the Servlets include a payment Bean, a prepay top-up Bean, a get balance Bean, a create listener Bean, and a co-ordination Bean. A co-ordination Bean manages other Beans to, for example, carry out a top-up procedure by calling payment and prepay to-up Beans.

The EJB business logic layer accesses a business rules database 134, as well as an operator prepay accounting system and a payment network (via an operator gateway) described below, using remote method invocation (RMI). The container may be any J2EE-compliant container, such as BEA Weblogic, which manages JDBC (Java Database Connectivity) database connections to business rules database 134, as well as managing other system resources and offering clustering and SNMP (simple network message protocol) functions. Business rules are represented within the transaction management system by individual classes within the EJBs and data, related to the business rules such as parameters and execution priorities, are stored within the business rules database 134. Preferably each business rule consists of just a single class. The business rule related data may be configured from an administration front-end terminal (not shown in Figure I b) or by direct database access. With such an implementation it should be understood that business rules, as such, are not stored within database 134, but instead this database supports implementation of business rules by the Enterprise Java Beans.

Where the transaction management system is implemented to manage prepay transactions for a mobile communications network the business rules may include a rule to limit the maximum monetary balance of a prepay (top-up) account and/or a rule to limit the number of top-ups or interaccount transfers within a time period.

Generally speaking the business rules comprise global business rules applicable to at least a particular user group, rather than rules which are specific to individual users.

Thus further business rules may define a set of discrete, permitted top-up or transfer values, and/or rules relating to which accounts or types of account may participate in top-up or transfer transactions. Different rules may apply to accounts storing network subscription balances and accounts storing call credit and/or debit balances. Further separate account types may be provided for other services, such as GSM SMS, and "Value Added Services". In general, mobile network operators will have a variety of prepay and other payment packages with different tariff and transfer/top-up structures and the business rules implemented by the Enterprise Java Beans in container 132, in conjunction with business rules database 134, are tailored according to the operator's specific needs.

Other business rules which may be implemented include a rule to warn a user, in advance, that a credit or debit card being used to pay for a top-up service is about to expire, and a rule which allows the network operator to add an advertising message at the beginning or end of a top-up or transfer confirmation. Thus, for example, the message"product X is now available in all operator stores"could be sent to a user's mobile station after top-up/transfer and/or balance requests, for display on a user's phone. Other rules may be added at the operator's request.

Referring again to Figure I b, top-up/transfer machine 128 is also in communication with a transaction authorisation system, verification server 136, by means of private IP network 127. The verification server 136 comprises signature verification code 138, and is coupled to a signature verification database 140. The server 136 operates to verify the identity of the user requesting a transaction. As will be understood by the skilled person, server 136 may be implemented by code running on the same hardware as code to implement top-up/transfer machine 128. The signature verification database 140 comprises a list of phone numbers (MSISDN numbers) for users of the mobile communications network who are also users of the transaction management system, and corresponding decryption keys for verifying a signature of or decrypting a message signed or encrypted by a system user. The transaction management system also includes a customer terminal 124 which is able to communicate with verification server 136 over Internet 118. Customer terminal 124 is employed for, inter alia, storing a user's decryption key in signature verification database 140.

In use, the verification server 136 sends a message to a device associated with the user's phone number, such as a SIM in the user's handset. The user then encrypts or signs the message and returns it to the server 136. The signature verification code 138 then employs the relevant key, which is retrieved from signature verification database 140, to decrypt the message or verify a signature of the message received back from the user.

The signature verification code 138 compares the original message string with the decrypted version and, if a match is found, the system knows that the message was signed or encrypted by a user with access to the correct encryption key. The signature verification code 138 provides an authorisation signal output to top-up/transfer machine 128 comprising a"true"/"false"logic signal and, in a preferred embodiment, a time-out flag to signal when no response is received within a predetermined time interval.

In other embodiments of the system the user (that is, the user's phone or SIM card) may compute a message digest, and in this case the signature verification code 138 computes the same digest of the unencrypted message and then compares this with a decrypt of the digest received from the user. The US cdmaOne network has no SIM card but it is still possible for a user of such a network to encrypt or sign a message, for example using a handset.

The message to be encrypted may comprise a random string generated by verification server 136, but preferably top-up/transfer machine 128 sends a message to verification server 136 for encryption by the user such as, for example,"confirm top-up my phone with EUR 10".

As illustrated in Figure 1b (although omitted from Figure la, for clarity) a secure link 126 is provided between private IP network 127 and delivery platform machine 112. It one embodiment this secure link comprises a separate physical connection of the top

up/transfer machine 128 to the delivery platform machine 112 ; in some other embodiments secure link 126 may be coupled directly to top-up/transfer machine 128 rather than via private IP network 127.

The secure link 128 is employed to protect details of requested transactions. Thus, the message sent by the verification server 136 to the user, which is not encrypted, is not sent over Internet 118. Similarly, the encrypted message from the user is also preferably returned over secure link 126 as, for example, where a public key cryptography system is used, the message content is potentially visible to anyone with the user's public key.

Preferably the secure link is, as illustrated, a separate physical connection between private IP network 127 and the delivery platform machine but, in other embodiments, a logically secure link via Internet 118 may be employed. In a GSM based implementation, the data sent over link 126 comprises message data, an SMS destination address, and a flag to request signature of the message by the SIM card. The need for a secure link 126 is greater when the message sent from verification server 136 to the user is a meaningful, rather than a random message. The skilled person will appreciate that the need for secure link 126 will depend upon the content of the message sent for signature by the user, and also upon the signature/encryption algorithm employed by the system. The system is compatible with 3DES, PKI and other digital signature/cryptographic algorithms. In one embodiment, the wireless Internet browser on SIM card 104 includes a message authentication code (MAC) signing algorithm which uses two 3DES keys to add a 4 byte signature to the end of the body of a conventional SMS message. By default, the

GSM PIN1 value, sometimes referred to as CHV1, is used to sign the message. The PIN1 function must be activated on the SIM card to enable signing, and the SIM is programmed to recognise PIN1 entry. If the PIN1 value is entered incorrectly three times, the SIM is locked. In a GSM network, the PIN1 value is never sent over the air, which maintains a high level of security. Functions such as changing the PIN 1 value and locking the mobile phone (or other device) when the PIN1 value has been entered incorrectly are all standard on GSM-compatible handsets and other communication devices. Thus the network operator is free of any additional key management duties.

However, in other networks other personal identification numbers (PINs) may be employed.

Once the signed SMS sent from the wireless Internet browser has been received by the verification server 136, the relevant 3DES keys are retrieved from database 140, accessed by the user's MSISDN. The SMS message body is then signed, using the retrieved keys, to create a digital signature which is compared with that received in the SMS from the user. If the two signatures match, the verification server 136 provides a "true"output to top-up/transfer machine 128, which then performs the requested transaction.

A removable storage device, represented by floppy disk 129, may be used to store part or all of the presentation layer code in storage 122, the top-up/transfer machine code in storage 130 including container 132 and the associated Servlets and Enterprise Java Beans, the signature verification code 138, and the data in business rules database 134, signature verification database 140, and registration database 142 (which is described below).

Referring now to Figure lc, this illustrates further aspects of the transaction management system which were not illustrated in Figure lb for reasons of clarity. In particular, Figure Ic shows interfaces of the top-up/transfer machine 128 of Figure lb to a network operator's prepay system and to an external payment system, and system elements associated with these interfaces. Top-up/transfer machine 128 is coupled to a registration database 142 which stores, among other things, user payment data. In one embodiment, this data comprises, for each user, the user's name and address, and an associated credit card number and credit card expiry date. Database 142 also stores a history of payment transactions comprising, for each transaction, a payment amount (positive for payments from the user to the network operator), a payment authorisation code (provided from an external payment authority), and a date and time stamp. Other transaction-related data may also be stored in database 142, for example, for marketing purposes.

The top-up/transfer machine 128 may be directly connected to a payment authority but normally the mobile communications network operator will have such a connection. In this case interfaces to the transaction management system can be simplified by connecting to the payment authority through a gateway 150 provided by the network operator to the payment authority. This is represented in Figure Ic, by the connection of top-up/transfer machine 128 to operator gateway 150 which in turn connects to a payment network 152 linked to a credit card company 154 and a bank 156. The interface between top-up/transfer machine 128 and operator gateway 150 will generally comprise a short section of proprietary code, implemented according to available connections to gateway 150. Such connections may include an Internet connection and/or a land line connection, typically password protected. In practice, machine 128 and gateway 150 will often be physically located within the same room. To make a payment, the top-up/transfer machine 128 sends at least a credit card number, card expiry date, and payment amount to gateway 150, which then sends a corresponding payment request, together with a merchant identifier code, to payment network 152. Payment is confirmed by receipt of an authorisation code from the payment network, which the operator gateway 150 forwards to top-up/transfer machine 128 for storage in registration database 142 as part of the transaction history record.

The top-up/transfer machine 128 includes code (not shown in Figure lc) to provide an interface to payment network 152 through operator gateway 150. The payment interface is an open interface which can be adapted for different payment methods, although payment by credit and debit card is convenient as on-line authorisation and clearing houses for this type of payment are widely available.

The payment interface provides a make payment function and a refund payment function. Each interaction with the payment system is assigned a transaction identification code, which is also appended to each entry logged in the transaction history in the registration database 142, irrespective of whether the transaction was successful or unsuccessful. This assists with auditing, traceability, and billing.

To make a payment, a user's card details and a payment amount are provided to the payment interface and thence to payment network 152, together with a transaction identification code as a reference for the payment. The interface receives back from the payment network a payment authorisation code or a failure code, indicating authorisation or failure of the transaction. To refund a payment the payment interface is again provided with card details and a refund amount, together with a transaction identification code, and again an authorisation or failure code is returned, the authorisation code indicating that the requested refund has been or will be credited to the card.

The top-up/transfer machine 128 is also coupled to an accounting system for the mobile communications network, for example, using a LAN. In the illustrated embodiment, the accounting system comprises an operator prepay system 146 coupled to a prepay database 148. The prepay database 148 comprises at least one account balance for each user. Generally, a user's balance is accessed using the user's MSISDN. One or more account balances may be available, for example, balances for call fees, subscription fees, SMS fees, and fees for other data services.

The interface to the operator prepay system receives instructions and, optionally, data from the top-up/transfer machine 128 and returns data in response. In particular, the prepay system interface operates to retrieve a balance for an account, top-up an account, determine whether an MSISDN is registered as a prepay account and, optionally, return a list of permitted tariffs for an account.

To return an account balance, prepay system 146 is provided with an MSISDN and, optionally, an account identifier (where more than one account is associated with a given ISDN). The prepay system then returns the balance for the specified account.

To top-up an account the prepay system 146 is provided with an MSISDN, a top-up value (tariff), and an account type (for example, SMS). The prepay system then returns

a code indicating either success or failure (i. e."true"or"false") of the top-up request.

To determine whether an MSISDN exists in database 146 as a valid prepay account, the MSISDN number is provided to the prepay system and a"true"/"false"code is returned according to whether or not there is an entry corresponding to the MSISDN number in database 148. This function may also be obtained from a look-up external to the prepay system, for example, by accessing another database maintained by the mobile operator. To retrieve a list of tariffs (that is, permitted top-up voucher types) prepay system 146 is provided with an MSISDN number and the system returns a list of permitted top-up values. Where an MSISDN number has more than one associated account a list of tariffs is provided for each account and thus the data returned by this function may include more than one voucher (or permitted top-up value) of the same monetary value.

In a preferred embodiment of the system a user is able to top-up another person's prepaid phone in what may be termed a"parent/child"top-up, the"parent"performing the top-up and the"child", referred to as the dependant account, receiving the top-up. The dependant or"child"may be another family member or, in a corporate context, the "child"may comprise an employee and the"parent"his or her line manager. In such embodiments, the registration database 142 includes, for each user of the transaction management system, a list of dependent users whose accounts can be topped up and/or whose account balances can be checked by the registered user. A dependant need not necessarily subscribe to the transaction management service although, in practice, the dependants will also be system users or at least customers of the transaction management system service provider.

As the"parent"user has access to the dependant's balance information, it is desirable in many embodiments to require the dependant's permission before an entry is made in registration database 142 allowing parent/child top-up and balance inspection. This may be provided by a separate registration procedure, for example, on-line registration using the Internet, or permission may be obtained by having the dependant user digitally sign a message, in a similar way to that described above with reference to the verification server 136.

The registration database 142 is accessed via the parent's MSISDN and this links to the dependant's MSISDN and, preferably, a name or nickname for the dependant. If appropriate there may also be a list or reference to a list of permitted tariffs for the dependant (the list itself may be obtained from prepay database 148). The parent user also has the ability to add and delete dependant users, the system automatically seeking a dependant user's permission via the dependant's MSISDN, when a new dependant is added. The prepay system interface function described above which determines whether an MSISDN is a valid prepay account is preferably also invoked when a user requests the addition of a new dependant or their own registration. Preferably, to simplify interfacing, dependants are restricted to users of the same mobile communications network as the parent. In embodiments of the system without this restriction, an additional interface for top-up/transfer machine 128 is required to the second operator's prepay system and an additional communications link is required for communicating with the user over the second operator's network.

A terminal such as customer terminal 124 of Figure 1 b allows a user to register his or her personal details (including payment data) as well as the addition and removal of dependants. The registration interface is provided by the presentation layer code in storage 122 running on web server 120, which provides a world wide web (HTML) interface for terminal 124. Terminal 124 also allows a user to top-up or transfer account balances over the Internet 118, for example, using Netscape's (registered trade mark) secure sockets layer protocol.

Referring again to Figure Ic, the top-up/transfer machine 128 is also coupled to storage 144 storing integration program and listener code. Some operator prepay systems have the facility to provide an account status output signal to indicate when a predetermined condition for an account is met, such as low balance conditions. Preferably therefore the interface of top-up/transfer machine 128 to operator prepay system 146 includes further functions to add and remove listener instances to provide account condition warnings. A listener instance is provided for each status report output signal rather than for each MSISDN so that, for example, 103 instances may be set up to monitor 106 subscriber accounts.

Some prepay systems are able to output a low balance warning when the balance of a prepay account falls below a predetermined level. Such a warning typically includes a prepay subscriber MSISDN for the account. The threshold warning trigger level is normally determined by the network operator, but could be set by top-up/transfer machine 128. Integration program code in storage 144 monitors LAN 145 for such notification events issuing from operator prepay system 146. When an event is received, the integration program code checks that the MSISDN associated with the notification has an entry in registration database 142, i. e. that the notification relates to an account which has been registered with the transaction management system and is able to participate in a transaction. If the MSISDN is found to belong to a transaction management system customer the integration program creates an instance of a listener program running on top-up/transfer machine 128, and passes to it a customer identity retrieved from registration database 142 corresponding to the MSISDN of the low balance warning.

The listener instance running on top-up/transfer machine 128 then sends a warning message corresponding to the account status message from operator prepay system 146 to delivery platform machine 112, for forwarding to the user's mobile station 102.

The account status warning may relate to one of the user's own accounts or to the account of a dependant, for example, to allow a parent to top-up the account of a child when the balance of the child account falls below a threshold minimum level. The listener instance may send an information-only notification or may provide an entry point into a top-up procedure. In some mobile communication networks, such a systeminitiated top-up may be performed concurrently with access to other services. For example, in a GSM network a triggered top-up can take place during a voice call where SMS is used as a bearer for wireless Internet browser communications.

Referring now to Figure 2, this shows data flows (200) between the wireless Internet browser of SIM card 104 and top-up/transfer machine 128 for an exemplary user Internet data page request. In the example shown, a user of mobile station 102 selects a menu option for a top-up function and is presented with a wireless Internet web page in response to this selection. The web page lists a number of top-up options, in particular, the accounts which the user is permitted to top-up. At step 202 the user selects a top-up menu option and the wireless Internet browser then issues a top-up URL request to delivery platform 112 using the GSM SMS service. The URL request includes the user's MSISDN, that is the user's phone number.

The delivery platform 112, at step 204, decrypts the SMS byte code and forwards the top-up URL request to web server 120, to access a Java server page in presentation layer code storage 122 of Figure lb. The Java server page accessed by the top-up URL request then, at step 206, issues a second top-up URL request to top-up/transfer machine 128, to a web page including a Servlet in container 132 which holds application layer code for the requested function.

The second top-up URL request includes the user's MSISDN, and the Servlet invoked by this URL request retrieves a list of accounts the user is permitted to top-up from registration database 142. This will generally comprise the user's own account and the accounts of one or more dependants. For other actions, such as actual payments or account balance transfers, top-up/transfer machine 128 may interact with prepay system 146 and/or payment system 150,152.

Once the Servlet function associated with the second top-up URL request has been executed top-up/transfer machine 128 returns a web page to web server 120 comprising a list of names of accounts the user is permitted to top-up. Web server 120 then formats this data for presentation to the user, at step 210, and returns a wireless Internet web page with the formatted result to delivery platform 112.

The delivery platform then converts the web page to byte code, at step 212, for transmission back to the wireless Internet browser as a GSM SMS message. The delivery platform 112 employs the user's MSISDN number to determine to which mobile station 102 to send the web page data to for display to the user. Finally, at step 214, the wireless Internet browser displays the wireless Internet web page on the phone display. The limitations imposed by the displays of many mobile phones may dictate that the displayed web page is very simple. Thus, the displayed portions of the web page may simply comprise between 50 and 100 characters listing the available options separated by carriage return-line feeds. The URLs associated with each menu option, and other data which is not displayed, may be longer. Other system menu options involve similar data flows. Thus, for example, selecting a balance request menu option causes the wireless Internet browser to issue a balance request URL including the user's MSISDN number and identification data for the account whose balance is requested. A balance request URL is then issued by web server 120 to top-up/transfer machine 128 and Servlet code on the corresponding web page then retrieves the balance for the specified account from the prepay system 146.

This data is then returned to the web server 120 where it is formatted and sent back to the wireless Internet browser for display on the user's mobile phone.

Where a user has selected an option to perform a top-up, after the account and amount have been selected, the wireless Internet browser sends a URL request comprising the user's MSISDN, the account and the amount to web server 120 which then issues a further URL request to top-up/transfer machine 128. The top-up/transfer machine 128 then generates an ASCII top-up confirm string which it sends to verification server 136 which then communicates with the user's phone via private IP network 127, using delivery platform 112. The verification server 136, in one embodiment, receives a response from the user via Internet 118, although in other embodiments the response may instead be received over secure link 126 to private IP network 127. The topup/transfer machine then communicates with the prepay system 146 and payment system 150,152 to perform the transaction and returns a confirmation web page to web server 120. Web server 120 then returns a second, formatted web page to mobile station 102 for display to the user. These processes are described in more detail below.

Figure 3 shows an exemplary menu structure to assist a user of the transaction management system in navigating through options available in an embodiment which allows the user to top-up more than one account. The menu structure (300) is not implemented by code on a mobile phone SIM card or handset but is instead determined by the structure of links on wireless Internet web pages displayed to the user on mobile station 102. Thus hypertext links comprising URLs associated with displayed menu options dictate which web pages (or further options) are available from a displayed page. The SIM card 104 is configured so that an option to access the wireless Internet browser is displayed on one of the mobile equipment's menu options. When this wireless Internet browser option is selected a main menu home page 302 is displayed using data stored on SIM card 104. In the illustrated example data has been downloaded to SIM card 104 to give the user access to three applications, a top-up application and two other applications, applications two and three. In Figure 3 displayed menu options are indicated by boxes and each box or menu option has an associated URL for accessing a web page to display the menu options or boxes following on from the option. Thus home page 302 displays menu options for a top-up application 304, for a second application 306, and for a third application 308. When the top-up application is selected a menu is displayed with a balance request option 310, a top-up option 312 for performing a top-up, and a"dependants"menu option 314 for adding to and amending the list of user's dependant accounts.

From the balance menu option 310 the user is presented with further menu options 316, 318 for obtaining account balances of dependant's registered to the user, and a menu option 320 to allow the user to view his or her own account balance (s). Where the user has more than one account he or she is permitted to access menu option 320 which may have a sub-menu, for example to display calls, subscription and SMS account options.

The top-up menu option 312 has a corresponding set of menu options 322,324, 326 which are presented to the user when top-up option 312 is selected.

When the balance menu option 310 is selected, once the account whose balance is requested has been identified the system returns a web page comprising the account

name and balance and then presents the user with an"OK/back"option, which returns the user to the wireless Internet browser main menu 302. Where the top-up option has been selected, each of options 322,324, and 326 then presents further options 330,332, and 334, to allow the user to select the amount by which he or she wishes to top-up an account, in the example shown EUR 5,10, and 25. In other embodiments the permitted top-up amounts may be different depending upon which account is topped-up. In other embodiments, for example where the user is settling a bill, the amount to pay may be determined by the transaction management system leaving the user without a choice.

Once the account to be topped-up has been identified and the amount to pay has been determined the user is prompted, at web page 336, to enter a PIN code to sign a confirmation message displayed on the phone. Standard phone handset features allow the user to set up and modify the PIN code. Finally, a wireless Internet web page is returned confirming the transaction and the user is presented with the"OK/back"menu option 328. The web page displayed at this stage comprises a confirmation message with the account name, the new balance and"top-up successful". Where the user was topping-up a dependant's phone a corresponding message is also sent, as a web page, to the dependant's phone.

When the user selects the"dependants"menu option 314, add 338 and remove 340 menu options are presented. Following selection of the add option 338 the user is prompted, at page 342, for the name and MSISDN number of the dependant to be added. Following selection of the remove dependant menu option the user is prompted, at page 344, for the name of the dependent to remove (or is presented with a list from which the user may select). In both cases the process then presents a confirmation message with the"OK/back"menu option 328. Other menu options (not shown in Figure 3) may also be provided, for example, to add low balance level triggers to the user's own account or to dependant's accounts. Referring now to Figure 4, this shows a flow diagram of a process for customer or user registration with the transaction management system using customer terminal 124.

At step S400 the customer or user loads a system registration web page into terminal 124. Then, at step S402, the customer or user enters their registration data into the terminal, this data comprising a name and address and data for at least one form of electronic payment, such as a credit card number and expiry date. This registration data is then transmitted to the top-up system at step S404, via Internet 118 and web server 120, and stored in registration database 142. The by then registered user is then presented with the transaction management system main menu web page received from the top-up/transfer machine 128, via web server 120, at step S408. Where a user has already registered, this main menu web page may also be accessed via an access control web page as shown at step S406, into which the user enters a user name or phone number and password for verification by the transaction management system. A similar registration process may be used by dependants to register their permission for a parent user to have access to the balance of, and to be able to top-up, their accounts. At step S408 the user is presented with a set of menu options. These include options for the user to amend their name and address, password, and payment data, an option to add additional payment data, for example for additional credit cards, and an option to add other accounts to the list of accounts the user is permitted to top-up. Other menu options may include an option to view the balance of an account and an option to set up a low balance notification. The menu also provides an"exit"option.

Figure 4 illustrates the process followed by the"add account"menu option. At step S410 the customer selects the add account menu option and at step S412 the add account web page is loaded into terminal 124 and displayed. The customer then enters the phone number for the account and a nickname by which to identify the account. The customer or user may also select check boxes to set up services such as low balance notifications. This data is then sent to the transaction management system at step S416 and the customer or user is then returned to the main menu web page. When the user is adding a new dependant's account, the system sends a message to the dependant's phone and waits until a signed message is received back from the dependant, confirming the user's permission to top-up and check the balance of their account, before the new account data is entered in registration database 142. This provides a one-off check, to prevent a user having access to another user's account without the other user first having given their permission, preferably by means of a digital signature.

Figures 5a and 5b show a flow diagram of a top-up process performed on a mobile phone handset. Initially, at step S500, the mobile phone is switched on and connects to the operator's mobile communications network. Then, at step S502, the user selects the transaction management system service provider menu option and, at step S504, the wireless Internet browser on the SIM card is started with the service provider's home page.

At step S506 the phone handset displays a menu of applications on the SIM card, such as an account top-up application and/or an account transfer application. In the illustrative process of Figure 5 the user selects a top-up application (option 304 of Figure 3) and proceeds to step S508 at which the wireless Internet browser sends a URL request for the selected top-up menu option to delivery platform machine 112 via SMSC 110. Other selected menu options send other URL requests as has already been described. As discussed with reference to Figure 2, the URL request accesses web server 120 which in turn accesses top-up/transfer machine 128 to execute a Servlet in container 132.

If, at step S510, there is only a single account to top-up the process moves to step S518 at which a list of permitted top-up vouchers is retrieved from top-up/transfer machine 128 for the selected account, and displayed on the phone handset. If the user has the option of topping-up more than one account, the wireless Internet browser displays a list of nicknames for the accounts the user is able to top-up (which may be the user's own accounts or the accounts of registered dependants). Then, at step S514, the user selects one of these accounts to top-up and, at step S516, a URL request for a list of permitted top-up vouchers for the selected account is sent to top-up/transfer machine 128 via SMSC 110, delivery platform machine 112, and web server 120. The system then proceeds to step S518 where the list of permitted vouchers is displayed, as has been mentioned. At step S520 the user selects a top-up voucher and this causes a URL request to be sent to SMSC 110 and thence to web server 120, which in turn calls a URL to execute the request on top-up/transfer machine 128. Machine 128 then communicates with verification server 136, which generates a confirmation message and sends this with a request for signature to the phone handset where it is displayed, at step S522, to the user. At step S524 the user enters a key for encrypting the message or generating a digital signature, such as a GSM PIN1 code, and the SIM wireless Internet browser MAC signing code recognizes the signature request, signs the message, and, at step S526, the signed message is sent to SMSC 110 where it is forwarded to verification server 136.

At step S528, if the signature is incorrect an error message is sent from top-up/transfer machine 128 to the phone handset where it is loaded into the phone and displayed (step S532). The process then returns to step S504 to once again display the wireless Internet browser home page. If the signature was correct the system then checks whether or not the top-up was successful, at step S530. If the top-up was not successful again an error message is displayed, at step S534, and again the system returns to step S504. If the signature was correct and the top-up was successful a confirmation message web page, including the new balance of the topped-up account, is sent from top-up/transfer machine 128 to the user's phone and displayed (step S536). Finally, at step S538, the user selects"back"or"OK"and in either case is taken back to step S504 and the transaction management system service provider's quote"home page".

Figure 6 shows a flow diagram of a top-up process as implemented on top-up/transfer machine 128. The illustrated process is execution of a top-up command received from a user's mobile phone, as interpreted by web server 120. Before reaching this stage the user must navigate through the menu structure of Figure 3, and these steps are not shown in Figure 6. In particular, the top-up machine sends the top-up application home page to the user's phone in response to a URL request transmitted by the user. One or more further wireless Internet data pages may also be sent to the phone including a topup page, a dependant list page, and a top-up voucher (payment amount) list page.

As illustrated, at step S600 a top-up request is received by machine 128 in the form of a URL request from web server 120 including, as data in the URL, the originating phone number for the request, the account to top-up, and the top-up amount (or so-called "voucher"). In response to this top-up request, at step S602 the top-up machine retrieves customer registration data for the user from registration database 142. The retrieved data is used to check consistency of the top-up request with permissions data stored in the database. However, where a user is constrained so that only permitted transactions may be requested, for example, by means of a menu structure as shown in Figure 3, this step is optional. In other embodiments, an error message may be returned if the top-up request is invalid because, for example, the user does not have permission for the requested top-up.

At step S604 top-up machine 128 generates a top-up message for signature and sends this to verification server 136 over private IP network 127. The message may be a random message but, preferably, is a meaningful message for display to the user confirming details of the requested transaction. At step S606 the verification server receives the message from the top-up machine and forwards the message, via secure link 126 and delivery platform machine 112, to the user's handset. The message comprises a text data string, an SMS destination address for the user, and a flag requesting signature of the message using code on the SIM 104. The user receives the message, enters the appropriate code, SIM 104 generates a signature and, at step S608, verification server 136 receives the signed message from the phone. Then, using data already stored in signature verification database 140, verification server 136 checks whether or not the user's signature is correct, in accordance with pre-registered data. At step S608, if no response is received from the user's mobile phone the verification server times out and provides a false verification indication.

At step S610 top-up machine 128 receives true/false signature verification data from verification server 136. At step S612 top-up machine 128 checks whether or not the user's identity has been verified and, if"false"data was received from the verification server, at step S614 an error message is sent to the user's handset and the process ends.

If the signature was verified as"true"the process proceeds to step S616 and payment data for the customer or user is retrieved from registration database 142. At step S618 payment data is sent to payment network 152, via operator gateway 150, requesting authorization of the top-up payment. As described above, an authorization code or a failure code is returned by the interface to the payment system. At step S620 the top-up machine 128 checks whether the payment was authorized and if it was not authorized, at step S622, again sends an error message to the phone and the process ends.

If the user's payment was authorized the process continues at step S624 and a top-up request is sent to prepay system 146, the request including data identifying the account to top-up and the amount by which to top-up the account. The process continues in Figure 6b, at step S626, in which top-up confirmation data is received back from the prepay system 146, either confirming that the top-up has been correctly performed or indicating that the requested top-up failed.

At step S628, the top-up machine 128 checks whether the top-up was successful and, if a successful top-up was confirmed, proceeds to step S630 in which the new account balance is retrieved from prepay system 146. A confirmation message wireless Internet web page, including the new balance, is then sent to the user's phone at step S632. If the user topped-up the account of a dependant, the same or a similar confirmation message web page is also sent to the dependant's phone to alert the dependant to the new balance.

The process then ends at step S634.

If, at step S628, the top-up was not confirmed as successful a refund request is sent to the payment system (step S636) and, again, a code is received back from the payment system indicating authorization of the refund or failure. At step S638 the top-up machine checks whether the refund was successful and if it was sends an error message to the phone at step S640 and ends the process at step S642. If the refund was not successful step S638 proceeds to step S644 and data indicating the failed refund transaction is stored in a transaction history area of registration database 142 (or, alternatively, in a separate payment history database). The refund error data preferably comprises a transaction identification code, details of the payment method (such as credit card data) and the requested refund amount. The system then again sends a message to the phone at step S646 and the process ends at step S648. The message sent to the user at step S646 preferably specifies the requested transaction, notes that the transaction failed, and warns the user that money was removed from the user's credit card account but that the subsequent refund failed. Referring now to Figure 7, this shows a flow diagram of a portion of the top-up process implemented on web server 120. The figure illustrates the interaction between web server 120 and top-up/transfer machine 128 during a top-up procedure.

At step S700 web server 120 receives a URL request for a top-up web page from the user's mobile station 102. Web server 120 then performs, at step S702, a Java Server Page call to top-up machine 128 to request a list of authorized accounts.

At step S704 JSP code running on web server 120 determines whether the user is authorized to top-up more than one account. If the user is authorized to top-up more than one account the web server, at step S708, returns a web page to the phone listing the accounts which the user is authorized to top-up. If the user is not authorized to topup more than one account, at step S706 the web server 120 makes a further JSP call to top-up machine 128 to request a list of permitted top-up vouchers for the single account the user is authorized to top-up.

Following this, at step S708, the web server returns a web page listing the permitted vouchers to the user's mobile station 102, for display by the wireless Internet browser on SIM card 104. A list length of zero returns an exception error to the phone since a registered user should always be able to top-up their own account. Other operations performed by web server 120 operate in a similar manner to that described above. For example, a balance request URL call from the user's handset invokes a JSP call on web server 120 to request the balance of the specified account from top-up machine 128. Figure 8 shows a flow diagram of a system-initiated top-up process implemented by integration and listener code in storage 144 oftop-up/transfer machine 128. At step S800 a low balance notification is received from operator prepay system 146 via LAN 145, and processed by integration program code as described above. The low balance notification includes the MSISDN of the account concerned and, at step S802, the integration program determines whether the relevant MSISDN is registered in database 142 as a customer of the transaction management services provider. If, at step S804, there is no entry for the account in registration database 142, the process ends at step S806, otherwise the process continues to step S808.

At step S808 the system determines whether the account identified in the low balance notification from the prepay system is that of a (parent) user or that of a dependant. If the account belongs to a registered dependant, at step S810 the payer or parent account for that dependant is retrieved from the registration database 142 and the process continues with step S812. If the account with a low balance is not a dependant's account step S808 proceeds directly to step S812. At step S812 a listener program instance is started and the integration program passes to the listener program instance the identity of the payer or parent account, or simply the account identified in the prepay system notification where no dependant's account is involved. Then, at step S814, the listener program retrieves a list of permitted top-up values for the relevant account and sends this data as a web page to the MSISDN of the account payer or parent. This web page corresponds to the web page displayed on the user's phone at step S518 of Figure 5b. The user may then, if he or she wishes, send a top-up request to top-up/transfer machine 128 at step S816 (which corresponds to step S520 of Figure 5b). Such a top-up request is then received by top-up machine 128 and the procedure continues as illustrated in Figure 6.

In other embodiments the listener program instance merely sends a notification, for example by means of an SMS message, to the payer and, optionally, to the dependant where appropriate, but does not invoke the user top-up procedure. Events other than a low balance notification from the prepay system may also cause the transaction management system to initiate a top-up procedure. For example, scheduler code may be implemented on top-up/transfer machine 128 to invoke a predetermined top-up procedure on a time-based basis. With such an arrangement, a user may employ customer terminal 124 to set up details of such a system initiated transaction, such as when the transaction is to occur, and details of what transaction is to be performed.

Figures 9,10 and 11 show, broadly speaking, account balance transfer procedures corresponding to the top-up procedures illustrated in Figures 5,6 and 7. For this re only an outline description of these procedures will be given, highlighting the differences from the procedures of Figures 5 to 7 where necessary.

Referring first to Figure 9, at step S906 the user selects a transfer menu option and, at step S908, the wireless Internet browser retrieves and displays a list of accounts between which the user is permitted to transfer part or all of an account balance. In some embodiments the user is only permitted to transfer an account balance from a parent account to registered dependant accounts, that is, to the accounts of other users who have been registered as"dependants"of the parent. In such embodiments only the dependant's accounts need be listed.

Steps S910 to S916 broadly correspond to steps S510 to S516 of Figure 5, except that the user selects an account to transfer to and permitted transfer amounts or values, rather than an account to top-up. Permitted transfers are displayed on the user's phone at step S918 and a transfer request is sent to top-up/transfer machine 128 at step S920. In the case of a transfer, however, the transfer request URL specifies an account to transfer from, an account to transfer to, and a transfer value (monetary value, unused time, or some other quantity). The remaining part of the process then proceeds analogously to the process of Figure 5 except that, since the transfer involves two accounts, at step S936 two confirmation messages are sent, to provide notification of an increase in the balance of a first account and notification of a decrease in the balance of a second account. Referring now to Figure 10, this shows a flow diagram of a transfer process implemented on top-up/transfer machine 128. At step S1000 a transfer request is received by top-up/transfer machine 128 in a similar way to the receipt of a top-up request as described in connection with step S600 of Figure 6. Thus, steps S1002 to S1012 correspond to steps S602 to S612 of Figure 6.

The transfer request URL received at step S 1000 comprises corresponding data to that received in step S600, but with the addition of data identifying an account to be debited, as well as an account to be credited. For this reason, steps S616 to S620 are not present in the process of Figure 10 since, generally speaking, where a transfer of part of an account balance is taking place there is no need for payment to an external payment system (although in some embodiments a compensatory payment may be implemented).

Figure 10 illustrates a transfer of credit between two prepay accounts of users of a mobile communications network. This transfer is implemented by debiting a first account and crediting a second account. Thus, at step S 10 16 a debit request and the identity of the account to be debited is sent to prepay system 146 and then, at step

S1018, a credit request and the identity of an account to be credited is also sent to prepay system 146. The requests of steps S1016 and step S1018 each result in the return of confirmation data from prepay system 146 indicating success or failure of the debit or credit request. This confirmation data is received at step S 1020, and at step S 1022 this confirmation data is checked to determine whether or not both the debit and credit were executed successfully.

If the credit transfer was successful, at step S 1024 the new account balances for both accounts are retrieved from prepay system 146 and, at step S1026, web pages comprising confirmation messages and the new balances are sent, via web server 120 and delivery platform machine 112, to the MSISDN numbers for the accounts involved in the transfer. Where only a single MSISDN number is involved, for example where a user transfers credit between two accounts associated with a single phone number, only a single wireless Internet web page confirmation message is sent. The successful process then ends at step S 1028.

Where the transaction was not successfully completed, a correction request is sent to prepay system 146 at step S1030, to credit and/or debit the accounts as necessary to return the account balances to their initial levels. Confirmation data is again received from prepay system 146 and, at step S1032, a check is made that the necessary correction was carried out successfully. If the correction was successful an error

message is sent, at step S 1034, to the user to indicate that the transaction failed, and the process ends at step S1036. A record of the failed transaction is normally also stored in database 142.

If the necessary correction could not be made, at step S1038 a complete record of the erroneous transaction and the failed correction is stored in registration database 142 or,

if appropriate, in a separate payment/transaction history database. An error message is v then again sent to the user, at step S1040, to inform the user of the failed transfer and failed correction. In either of steps S1034 and S1040, where more than one user is affected by the failed transfer messages are sent to all the registered system users or customers. The process then ends at step S 1042.

Figure 11 shows a flow diagram of a portion of a transfer process as implemented on web server 120. This process approximately corresponds to the process illustrated in Figure 7.

At step SHOO web server 120 receives a request for a transfer web page from a user's mobile station 102. At step S 1102, the web server requests from top-up/transfer machine 128 a list of accounts registered in database 142 as accounts which the user is permitted to transfer part or all of a credit balance from (to another account). Web server 120 requests the list using a Java Server Page call to a web page (with associated Servlet code) held on top-up/transfer machine 128. At step S1104 the web server 120 determines whether transfer from more than one account is permitted, and if this is permitted returns a web page to the phone, at step S 1106, listing the permitted account to transfer part or all of a balance from. If, at step S 1104, it is found that the user is authorized to transfer from only a single account web server 120 then, at step Sol108, makes a JSP call to transfer machine 128 to request a list of accounts the user is permitted to make credit transfers to.

At step S 1110, in a similar way to step S 1104, the web server checks whether the user can transfer to more than one account and, if so, at step S 1112 returns a web page to the phone listing the accounts the user may transfer credit to. Otherwise the process continues to step S1114 where the web server 120 checks that the account the user is permitted to transfer from is different to the account the user is permitted to transfer to. If the"transfer from"and"transfer to"accounts are the same, at step S 1116, the web

server returns an error message web page to the phone. Otherwise, at step S 1118, the \1 web server presentation layer code in storage 122 constructs a wireless Internet web page comprising the single permitted"transfer from"and"transfer to"accounts, identified either by MSISDN numbers or by nicknames or in some other way. This web page is then returned to the phone for display to the user by means of the wireless Internet browser on the SIM card 104. An embodiment of the invention has been described in which a mobile phone handset is used to effect a transaction. However other mobile communications devices, such as wireless enabled personal organisers, can also be used with the system. No doubt many other effective alternatives will occur to the skilled person and it will be understood that the invention is not limited to the described embodiments and encompasses modifications apparent to those skilled in the art lying within the spirit and scope of the claims appended hereto.

Claims

CLAIMS: 1. A transaction management system for use with a mobile communications network, to enable a user of a mobile communications device coupled to the network to carry out a transaction; the mobile communications network having: a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the system comprising: a transaction authorization system, coupled to the network communications interface, for communicating with the user to obtain authorization for the transaction; an instruction store storing processor implementable instructions; a processor coupled to the accounting system, to the transaction authorization system, and to the instruction store for implementing the stored instructions; wherein the instructions stored in the instruction memory comprise instructions for controlling the processor to: receive a transaction request; communicate with the transaction authorization system to seek user authorization of the requested transaction; and communicate with the accounting system to update the account data relating to the user to perform the requested transaction if said user authorization is obtained.
2. A transaction management system as claimed in claim 1 wherein the processor is further coupled to the network communications interface and wherein the transaction request is received by the processor from the network communications interface.
3. A transaction management system as claimed in claim 2, wherein the instructions further comprise instructions for controlling the processor to communicate with the user to collect transaction related data from the user and wherein the processor communicates with the accounting system to perform the requested transaction in accordance with the transaction related data.
4. A transaction management system as claimed in claim 3, further comprising a user interface server coupled between the processor and the network communications interface, the user interface server comprising code to format data received from the processor as pages of Internet data for transmission over the communications network to the user.
5. A transaction management system as claimed in claim 2,3 or 4, wherein the processor is coupled to the network communications interface via the Internet.
6. A transaction management system as claimed in any preceding claim further comprising : a registration data store to store registration data relating to the user; and wherein the instructions further comprise instructions for controlling the processor to use the registration data to enable the transaction.
7. A transaction management system as claimed in claim 6, wherein the registration data includes permission data associated with the user, the permission data determining permitted transactions.
8. A transaction management system as claimed in claim 6 or 7, further comprising an interface to a payment system, wherein the registration data includes payment data for making a payment using the payment system, and wherein the instructions further comprise instructions for controlling the processor to make a payment for the transaction using the payment system and payment data.
9. A transaction management system as claimed in claim 8 when dependent upon claim 7, wherein the network accounting system has a plurality of user accounts, wherein the permission data determines to which of the user accounts the user is permitted to make a payment, and wherein the transaction comprises a payment to a permitted said user account.
10. A transaction management system as claimed in claim 9 wherein the transaction comprises a payment by the user to an account of another user, and wherein the permission data comprises data identifying at least one such permitted recipient user.
11. A transaction management system as claimed in claim 7, wherein the accounting system has a plurality of user accounts each having account data including balance data indicating the balance of a user account, wherein the transaction comprises a transaction between two said user accounts to transfer at least part of an account balance between the accounts, and wherein the permission data comprises data identifying at least one such permitted transfer.
12. A transaction management system as claimed in claim 11, wherein the account balance comprises the balance of a prepay account for a mobile communications device, and wherein the transaction comprises a transaction between the user and a second user of the mobile communications network to transfer at least part of a prepay account balance from the user to the second user.
13. A transaction management system as claimed in claim 7, wherein the instructions further comprise instructions for controlling the processor to determine, using the permission data, whether the requested transaction is permitted.
14. A transaction management system as claimed in claim 7 or 13, wherein the instructions further comprise instructions for controlling the processor to communicate with the user to present to the user one or more permitted transactions, determined using the permission data, for selection by the user.
15. A transaction management system as claimed in claim 1, wherein the instructions further comprise instructions for controlling the processor to implement one or more rules for transactions common to a plurality of users.
16. A transaction management system as claimed in claim 15, wherein said rules comprise rules common to a plurality of users governing permitted transactions.
17. A transaction management system as claimed in claim 15 or 16, wherein said rules include at least one rule selected from a rule to send an advertising message to a user after a transaction request by the user, and a rule to warn a user of impending expiry of a payment method.
18. A transaction management system as claimed in claim 1, wherein the instructions further comprise instructions for controlling the processor to: receive an account status signal for an identified account from the accounting system; and send notification of an account status to a user associated with the identified account in response to reception of the account status signal.
19. A transaction management system as claimed in claim 18, wherein the instructions further comprise instructions for controlling the processor to initiate a transaction relating to the identified account in response to reception of the account status signal.
20. A transaction management system as claimed in claim 1, wherein the instructions further comprise instructions for controlling the processor to prompt the user at time intervals to perform a transaction.
21. A transaction management system as claimed in claim 7, wherein the network accounting system has a plurality of user accounts, and wherein the instructions further comprise instructions for controlling the processor to: input from the user a request to register permission for a transaction type with a user account; communicate with the transaction authorization system to request authorization for the transaction type from a user associated with the user account; determine whether authorization for the transaction type has been obtained; and store, in the registration data store, permission data comprising data permitting transactions of the requested type with the user account.
22. A transaction management system as claimed in claim 1 or 2, further comprising a secure link between the transaction authorization system and the network communications interface.
23. A transaction management system as claimed in claim 22, wherein the processor is coupled to the network communications interface via the Internet, and wherein data communicated between the transaction authorization system and the network communications interface over the secure link is not accessible via the Internet.
24. A transaction management system as claimed in claim 22 or 23, wherein the transaction authorization system comprises a data store storing at least one cryptographic key for the user, and an instruction store storing program code for controlling a processor to: send a message over the secure link for transmission to the user; receive an encrypted message from the user; determine, using the stored key, whether the encrypted message has been encrypted by the user; and output an authorization signal in response to said determination, the authorization signal indicating that user authorization has been obtained when said determination indicates that the encrypted message has been encrypted by the user.
25. A transaction management system as claimed in claim 24, wherein the mobile communications network is a GSM-based mobile communications network, and wherein the key stored in the data store and the code to determine whether the encrypted message has been encrypted by the user comprises a key and code to determine whether the message has been encrypted using the GSM PIN1 key.
26. A transaction management system as claimed in claim 24 or 25 wherein the instructions further comprise instructions for controlling the processor to: generate a message which is meaningful to the user; and send the generated message to the transaction authorization system for sending to the user.
27. A mobile communications network comprising the transaction management system of any preceding claim.
28. A mobile communications network as claimed in claim 27, further comprising a short message service centre (SMSC) and a wireless Internet gateway coupled between the network communications interface and the SMSC, and wherein communications between the user and the transaction management system are sent across an air interface of the mobile communications network using a short message service provided by the network.
29. A data carrier carrying the processor implementable instructions of any preceding claim.
30. A method of using a mobile communications network to enable a user of a mobile communications device coupled to the network to perform a transaction; the mobile communications network having: a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the method comprising: receiving a transaction request; communicating with a transaction authorization system coupled to the network communications interface to communicate with the user to seek user authorization of the requested transaction; receiving an authorization signal from the transaction authorization system; and communicating with the network accounting system to update the account data relating to the user to perform the requested transaction in response to the authorization signal indicating that said user authorization has been obtained.
31. A method as claimed in claim 30, wherein the transaction request is received via the network communications interface.
32. A method as claimed in claim 31, further comprising: communicating with the user to collect transaction related data from the user; and communicating with the accounting system to perform the requested transaction in accordance with the transaction related data.
33. A method as claimed in claim 32, further comprising formatting data for transmission to the user via the network communications interface as pages of Internet data.
34. A method as claimed in any one of claims 30 to 33 further comprising: storing registration data relating to the user in a registration data store; and using the registration data to enable the requested transaction.
35. A method as claimed in claim 34 wherein the registration data includes permission data associated with the user, the permission data determining permitted transactions.
36. A method as claimed in claim 34 or 35 wherein the registration data includes payment data for making a payment using a payment system, and wherein the method further comprises: reading payment data from the registration data store; and writing payment data to the payment system.
37. A method as claimed in claim 36, wherein the accounting system has a plurality of user accounts, the method further comprising: determining, using the permission data, to which of the user accounts the user is permitted to make a payment; and writing payment data to the payment system for making a payment to a permitted said user account.
38. A method as claimed in claim 37, wherein the transaction comprises a payment by the user to an account of another user, and wherein the permission data comprises data identifying at least one such permitted recipient user.
39. A method as claimed in claim 35, wherein the accounting system has a plurality of user accounts each having account data including balance data indicating the balance of a user account, wherein the transaction comprises a transaction between two said user accounts to transfer at least part of an account balance between the amounts, and wherein the permission data comprises data identifying at least one such permitted transfer.
40. A method as claimed in claim 39, wherein the account balance comprises the balance of a prepay account for a mobile communications device, and wherein the transaction comprises a transaction between the user and a second user of the mobile communications network to transfer at least part of a prepay account balance from the user to the second user.
41. A method as claimed in claim 35, further comprising: determining, using the permission data, whether the requested transaction is permitted.
42. A method as claimed in claim 35 or 41, further comprising: communicating with the user to present to the user one or more permitted transactions, determined using the permission data, for selection by the user.
43. A method as claimed in claim 30, further comprising: determining whether the requested transmission is permitted using one or more rules for transactions common to a plurality of users.
44. A method as claimed in claim 43, wherein said rules include at least one rule selected from a rule to send an advertising message to a user after a transaction request by the user, and a rule to warn a user of impending expiry of a payment method.
45. A method as claimed in claim 30 further comprising: receiving an account status signal for an identified account from the accounting system; and sending notification of an account status to a user associated with the identified account in response to reception of the account status signal.
46. A method as claimed in claim 45, further comprising: initiating a transaction relating to the identified account in response to reception of the account status signal.
47. A method as claimed in claim 45 or 46 further comprising: monitoring an interface to the accounting system for a low balance notification from the accounting system.
48. A method as claimed in claim 30 further comprising: prompting the user, at time intervals, to perform a transaction.
49. A method as claimed in claim 35, wherein the network accounting system has a plurality of user accounts, and further comprising: inputting from the user a request to register permission for a transaction type with a user account; communicating with the transaction authorization system to request authorization for the transaction type from a user associated with the user account ; determining whether authorization for the transaction type has been obtained; and storing permission data, comprising data permitting transactions of the requested type with the user account, in the registration data store.
50. A method as claimed in claim 30, further comprising: receiving said transaction request from the network communications interface via the Internet; and sending a request for user authorization of the transaction from the transaction authorization system to the network communications interface over a secure link.
51. A method as claimed in claim 50, further comprising: sending a message for transmission to the user from the transaction authorization system to the network communication interface over the secure link; receiving an encrypted message from the user at the transaction authorization system; determining, using a stored key, whether the encrypted message was encrypted by the user requesting the transaction; and outputting the authorization signal from the transaction authorization system in response to the result of the determination, the authorization signal indicating that user authorization has been obtained when said determination indicates that the encrypted message has been encrypted by the user.
52. A method as claimed in claim 51 further comprising: generating a message which is meaningful to the user; and sending the generated message to the transaction authorization system for sending to the user.
53. A method as claimed in claim 51 or 52 wherein the stored key is suitable for determining whether the encrypted message was encrypted with a GSM PIN 1 key of the transaction requesting user.
54. A method as claimed in claim 32 wherein the communicating with the user includes communicating using a wireless Internet protocol.
55. A method as claimed in claim 54 wherein the wireless Internet protocol uses a GSM mobile communications network short message service.
56. Program code for controlling one or more processors to implement the method of any one of claims 30 to 55.
57. A data carrier carrying the program code of claim 56.
58. A method of using a mobile communications device coupled to a mobile communications network to perform a transaction, the method comprising sending a URL request over the mobile communications network to a transaction management system to request the transaction; and receiving an Internet data page from the transaction management system indicating whether the requested transaction was performed.
59. A method as claimed in claim 58, wherein the URL address specifies the transaction to be performed.
60. A method as claimed in claim 58 or 59, further comprising: receiving a message from the transaction management system over the mobile communications network; inputting a code number into the mobile communications device; using the code number to process the message to generate encrypted data; and sending the encrypted data to the transaction management system over the mobile communications network to confirm the requested transaction.
61. Transaction facilitation apparatus for a mobile communications network, to facilitate performance of a transaction by a user of the network; the mobile communications network having a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the apparatus comprising: a registration data store to store registration data relating to the user; an instruction store storing processor implementable instructions; a processor coupled to the network communications interface, to the accounting system, to the registration data store, and to the instruction store for implementing the stored instructions; wherein the stored instructions comprise instructions for controlling the processor to: receive a transaction request from the user over the network communications interface; retrieve registration data relating to the user from the registration data store; use the registration data to determine an allowed transaction for the user; and communicate with the accounting system to perform the requested transaction if the transaction is allowed for the user.
62. The transaction facilitation apparatus of claim 61, further comprising a transaction authorization system coupled to the network communications interface, the stored instructions further comprising instructions for controlling the processor to seek user authorization of the requested transaction using the transaction authorization system.
63. A method of facilitating a transaction using a mobile communications network; the mobile communications network having a network communications interface for sending and receiving messages to and from the user; and an accounting system for storing and accessing account data relating to the user; the method comprising: receiving a transaction request from a user of the mobile communications network over the network communications interface; retrieving registration data for the user from a registration data store; using the registration data to determine an allowed transaction for the user; performing the requested transaction using the accounting system if the transaction is allowed for the user.
64. A transaction management system for use with a mobile communications network, the mobile communications network having an accounting system for storing and accessing account data relating to the subscriber, the system enabling a subscriber to the network to carry out a transaction modifying a balance of an account held by the subscriber, the system comprising: a transaction authorization system having an interface to a computer network, and for providing cryptographically validatable communications with a subscriber terminal couplable to the computer network, for obtaining authorization for the transaction; an instruction store storing processor implementable instructions; and a processor coupled to the accounting system, to the transaction authorization system, and to the instruction store for implementing the stored instructions; wherein the instructions stored in the instruction memory comprise instructions for controlling the processor to: receive a transaction request; control the transaction authorization system to communicate with the subscriber terminal to seek cryptographically confirmable user authorization of the requested transaction; and communicate with the accounting system to update the account data relating to the user to perform the requested transaction if said user authorization is obtained.