Prior Art Discussion At present, there are quite extensive mechanisms for processing subscriber billing data in telecommunication networks such as mobile networks. However, such processing has been inflexible and so only generate billing data according to limited parameters such as time duration of a call. Such an arrangement is described in United States Patent Serial No. US5873030 (MCI), in which local mobile networks connect with a national mobile service platform (MNSP) to provide traffic-related billing data.

Objects of the Invention It is therefore an object of the invention to provide for more flexible billing data processing in a network environment.

SUMMARY OF THE INVENTION

According to the invention, there is provided a method of capturing billing data for operation of an application on a network server communicating with a client via a gateway, the method comprising the steps of :- the application automatically generating billing data relating to a service it provides ; the application automatically transmitting the billing data to the gateway ; and the gateway processing the billing data.

In one embodiment, the application transmits the billing data in an event message according to a pre-set format.

In another embodiment, the message comprises a HTTP header.

In one embodiment, the application generates a message for each activity recognised as an event and transmits said messages to the gateway.

In another embodiment, the application recognises a plurality of events for a transaction.

In a further embodiment, the application includes a common event linkage identifier in each event message associated with a particular transaction.

In one embodiment, the application recognises a transaction failure as an event.

In another embodiment, the application recognises a time-out as an event.

Preferably, each event message has a unique identifier.

In one embodiment, the identifier is a number whereby identifiers of sequential messages are sequential numbers.

In another embodiment, each event message comprises at least one parameter value.

In one embodiment, each parameter value is represented in a tag-length-value format in which a tag field identifies a parameter name, the length field identifies the length of the value in bytes, and the value field contains the parameter value.

In another embodiment, the gateway generates billing data according to signal flows between the application and the client, and stores said billing data in addition to that originating from the application.

In a further embodiment, the gateway recognises events according to signal flows between the application and the client, and generates corresponding messages.

In one embodiment, the gateway routes event messages to a billing log for off-line processing or to a real time mediation device for real time processing according to configuration settings.

In another embodiment, the gateway routes event messages to the real time mediation device if the events relate to pre-paid services.

In a further embodiment, within the gateway, messages are routed in real time to a billing manager, and said billing manager processes the messages.

According to another aspect, the invention provides a gateway for routing of signals between a client and an application hosted on a network server for performance of a transaction, the gateway comprising :

means for receiving billing data from the application, said billing data relating to a service provided by the application ; and means for processing the billing data.

In one embodiment, the processing means comprises means for classifying the data as requiring real time processing or off-line processing, and for routing the data accordingly.

In another embodiment, the billing data is incorporated in event messages.

In a further embodiment, the gateway comprises means for generating event messages according to handling of signals for transaction.

In one embodiment, the gateway comprises a billing manager, means for routing billing data in real time to the billing manager, and means in the billing manager for directing storage of the data in a log for off-line processing or for routing the data to a real time mediation device for real time processing.

According to a still further aspect, the invention provides a billing system comprising : a gateway as described above ; a mediation device comprising means for reading billing data in a billing log which is updated by the gateway and for processing said billing data ; and a real time mediation device comprising means for performing real time processing of billing data received from the gateway.

DETAILED DESCRIPTION OF THE INVENTION The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawing which is a schematic representation of a billing data processing method and system.

Referring to Fig. 1, there is shown a WAP gateway 1 communicating with a Web (or "origin") server 2 hosting Web-based applications such as on-line shopping applications. The gateway 1 communicates with mobile handset clients 3 via a mobile network 4. The gateway 1 maintains a billing log 5, and the log 5 is accessed by a billing mediation device 6. The gateway 1 also communicates with a real time billing mediation device 7. The gateway 1 comprises an internal software function called a Billing Manager.

An application on the server 2 carries out its operations in conventional manner for processing transactions. However, the application is also programmed to generate messages including a billing-related HTTP header. The header is in a pre-set format, which may be published and used by many Web-based applications on many Web servers. In this embodiment the header has the format"x-up-billing-info :". A simple example is"x-up-billing-info : 245" to indicate to the gateway 1 that a user (of the client handset 3) has made on-line shopping purchases worth $245 while accessing that application.

The application generates the messages in response to events associated with the service being provided. These events will not all be"billable"and so some messages do not include billing headers.

The gateway 1 detects and extracts each such header. In this embodiment, this is performed by code in the gateway stack recognising the header. The header is forwarded in real time to the (internal) Billing Manger.

Where the billing data is not required to be processed in real time, the Billing Manager sends the contents of the billing header (together with any others received in the preceding period) to the billing log 5. In this embodiment, the billing log 5 resides on the gateway 1, however, it may reside on an external entity.

Subsequently, the billing mediation device 6 (which is operated by the mobile network operator) accesses the billing log and uses the data for billing purposes. For example, the mobile network operator may use the data to charge the user or the operator of the application a handling fee of say, 1% of the transaction value. Thus, the invention allows parties who are not hosting the application to make charges for service events on an agreed basis with the application host organisation and the user.

In the embodiment described above, the header value is a single numeric value, however, it may be a combination of both text and numerical information and the content of the header may be set according to the particular application.

The Billing Manager may route the billing data to the mediation device 7 in real time. Also, the gateway 1 may transmit the billing data to the client.

In more detail, an event reflects some aspect of the processing of a transaction, and a transaction is a complete request/response cycle from the user's perspective. Each message generated in response to an event contains a number of fields, which hold common information such as source, destination addresses, and data specific to the event itself such as the URI being retrieved or the volume of data downloaded.

Multiple messages may be created for a single transaction. Each message has a numeric identifier, and all messages that relate to the same transaction are linked

with a unique number, called the event linkage id (ELID). The ELID is used to ensure that all messages related to one transaction can be associated, for example during processing by a billing mediation device 6 or 7. The gateway manages the generation and allocation of ELIDs.

The internal components of the gateway (for example processes) also recognise events to mark the progress of a transaction at discrete points, for example, when a response is received from the Web server or when the content has been confirmed to have been received by the client etc. As each event is recognised an associated message is communicated in real-time to the Billing Manager.

The Billing Manager may write the message (or some of its data) to the billing log 5 and/or can send it directly (in real-time) to a real-time billing mediation device 7.

The choice of whether to write the message to the billing log or send it via the real- time interface is configurable within the gateway 1. For example, real-time output might be used for prepaid subscribers to allow their available credit to be updated as they perform transactions, while the billing log 5 might be used for post-paid subscribers who are billed periodically. The exhaustion of a pre-pay user's credit would be detected by the real-time billing mediation device, and the configuration of the gateway components would automatically be updated to deny service to that particular subscriber. Subsequently, when the user's credit is re-established the configuration of the gateway would be altered to permit subscriber requests.

Each message is formatted as a Tag-Length-Value (TLV) as described in more detail below. Messages are written to the billing log file in their TLV format. For the real- time interface, a TCP socket connection is established between the Billing Manager and the real-time billing mediation device 7. The Billing Manager outputs the appropriate messages directly onto this connection.

A transaction is generally regarded as a single request and response between the client and the Web server. The transaction may have been initiated either by the client (pull) or by the web server (push). The pull model is used in the following description, but it applies equally to the push model.

A transaction may result in a number of distinct events, each of which is logged separately ; the messages of events for a particular transaction have the same ELID, and so all the events for a transaction can be associated. It is the responsibility of the billing mediation device 6 (or some other external system) to reconcile the events for a particular transaction into meaningful billing information for the operator.

While the gateway can track (and record events for) individual transactions between the client and the web server, it has no understanding of the content or value of the service being provided to the user of the client. For example, when accessing a banking application, a user probably has to navigate through a series of menus in order to achieve the service. In a scenario where a user wants to transfer money from one account to the other, an interaction with the web server might be as follows.

1. The user enters his username and secret password to get access to the basic menus 2. The user selects Account Transfer (rather than Balance Enquiry, Chequebook Order, Bill Payment, etc.) 3. The user selects the two accounts for the transfer and the amount to be transferred 4. The application asks the user to confirm the transfer, possibly requesting that the password is re-entered. The success of the transfer is indicated to the user.

5. The user would then sign-off from the application.

This simple service could result in as many as five events, but it is the fourth event that provides the real value for the user and the application provider, i. e. the successful transfer of money from one account to the other. If the user entered the wrong username or password, or unknown account numbers, or the bank was not allowing transfers at this moment in time, transactions would still take place between the client and the web server, but no valuable service has been provided to the user.

Similarly, moving £1000 from one account to the other might be considered to have more value than a balance enquiry or ordering a chequebook.

The gateway 1 cannot determine (purely from the transaction) whether a useful service has been provided to the user, or how useful/valuable that service was. Therefore, it would not be possible for the operator to take account of the value of the service provided in billing (or indeed not billing) the user. Only the application (resident on the Web server) can determine in all circumstances whether a service has been provided and the degree of value.

The invention provides a major advance for the network operator as it allows it to enhance its billing strategy and differentiate itself from competitors. The application can include any information it wishes in the billing header, for example the success of the service, the value of the service (e. g. £1000 transferred), the names of the books the user purchased, etc. The format of the information just needs to be agreed between the operator and the application.

The billing header is included in one or more of the event messages created for the transaction. The operator can then consider the information in the billing header when determining whether and how much to bill the user for the service. For example, the operator might choose not to bill the user for any of the transactions unless the user was successfully provided with a service ; or the user might be billed a small amount for each transaction, and then an additional fee for successful services ; and some services might be premium rate, while others might be lower rates. The

operator might enter into an agreement with the application provider where the operator bills the user and provides a portion of the revenue to the application provider. Conversely, the application provider may receive the revenue from the user, for example credit card transaction or account transfer, and have to provide a portion to the operator. In this case, the billing header could allow the operator to track the amount due from the application provider.

Event messages are created in a binary'Tag, Length, Value' (TLV) format. Each message has a numeric identifier, called the Event ID. The table below illustrates some example messages. Also shown is an example list of parameters, which might be included in the message. Every message is separately configurable as to whether or not it is logged to the Billing Manager. A number of parameters are common to every message. They are :

EVENTJD DATE TIME <BR> <BR> EVENT LINKAGE ID Event ID Desaiption Parameters present 3003 Confirms that a transaction response has been SOURCE ADDRESS received by the client. SOURCE-PORT BEARER TYPE MSISDN CLIENT IN POU SIZE 3004 A timeout occurred when waiting for a SOURCE ADDRESS confirmation of a transaction response from the SOURCE-PORT client. BEARER_TYPE 3005 There has been a WMLScript compilation SOURCE_ADDRESS failure. SOURCE PORT BEARER TYPE 3010 There has been a WML encoding failure. SOURCE ADDRESS SOURCE PORT BEARER TYPE 3013 Generated when the network is unavailable SOURCE ADDRESS (e. g. the requested site does not exist or a SOURCE PORT BEARER_TYPE timeout occurred trying to connect to the site DEST_ADDRESS DEST_PORT MSISDN CLIENT ID 3014 An HTTP response has been received from the SOURCE-ADDRESS origin server. SOURCE PORT BEARER TYPE STATUS URI CONTENT LENGTH MSISDN CLIENT NID BILL HTTP_HEADER** BILL HTTP VALUE** 3017 An HTTP request has been received from the SOURCE ADDRESS handset. SOURCE PORT BEARER TYPE URI MSISDN CLIENT NID CLASS OF INTERFACE USER AGENT HEADER CLASS OF SERVICE

As is clear from the above only the message for event 3014 has a billing header.

Many event messages do not include headers because : Only the application knows whether a useful service has been provided to the user, and so the application decides the transactions for which to return a billing header. Therefore, the billing header may not have been returned for some transactions and therefore cannot be included in the events resulting from that transaction.

Some events are recognised by the gateway before the web server has returned the response to the request. For example an event might be that a request had been received from the client, or that the request has been forwarded to the Web server. Since no response has yet been received from the Web server, no billing header exists and therefore cannot be included in any events.

'The gateway may produce a number of event messages once the response is returned from the Web server. If the billing header was included in the response, it does not need to be included in every event message because :

The first byte has the most significant bit set, so a second byte is read. The second byte doesn't have the most significant bit set so no more bytes are read. Excluding the most significant bits, the two sets of 7 bits make up a 14 bit number : 0 0 0 0 0 0 1 0 0 0 1 1 0 1 The value of this number is 141 in decimal.

The format of the value itself depends on the type of the tag. Below are some example tags. Each event will use the appropriate set of tags required to represent its parameters. Tag Name Type Notes 0x0006 STATUS Integer value The HTTP status code. Ox0007 SOURCE ADDRESS Dotted quad or The address is encoded depending on the ASCII text Bearer type. If the Bearer is ANY ANY_IPV4, then the address is an integer value suitable for an Internet address. If the Bearer is GSM SMS GSM MSISDN, then the address is SMS encoded as ASCII text. 0x0008 SOURCE-PORT Integer value Port number which matches the Source address. 0x0009 BEARER_TYPE Integer value Values as defined by WAP. ANY_ANY_IPV4 = 0, GSM SMS GSM MSISDN = 3. OxOOOA DEST_ADDRESS Dotted quad or Encoded in the same way as the Source ASCII text address. OxOOOB DEST_PORT Integer value Port number which matches the Destination address. OxOOlA URI ASCII text The URI which has been accessed. 0x0024 EVENT_LINKAGE_ID Integer value This is the identifier used to link all events related to a particular transaction together. It is a 32-bit number. Oxo28 EVENT_ID Integer value This number identifies the event itself, as defined in the table in Chapter 6. 0x002E DATE_TIME Integer value Epoch time when the event was generated. 0x0032 CONTENT LENGTH Integer value The length of the retrieved content. 0x0048 MSISDN ASCII text Represents an MSISDN number. 0x004A BILLHTTPHEADER ASCII text The name of the in-band billing header (always "x-up-billing-info"). Ox004B BILLHTTP VALUE ASCII text The corresponding value for the in-band billing header. 0x0056 PDU_SIZE lnteger value Size in bytes of the WSP PDU transmitted over the bearer.

-All events can be associated via the ELID and therefore the billing header only needs to be included in at least one event -On a system with high traffic levels, the processing and storage of unnecessary or redundant data needs to be avoided. For example, it could cause increased use of disk storage space, performance degradation, or unnecessary use of bandwidth on the real-time connection, all of which represent some form of cost for the operator.

All parameters are represented in a binary TLV format. Each parameter is composed of three parts : A numeric tag which identifies the parameter name ; a length which represents the length of the value in bytes ; and the value itself. These three parts are defined as : * The numeric tag is always represented with two bytes. See below for a table below defining some example tags.

The length is represented with one or more bytes, with the most significant bit in each byte being used to indicate if the next byte is also part of the length. This is known as Extension-Bit format. After reading the first byte, if the most significant bit is set then the next byte is also read. This continues until a byte read does not have the most significant bit set, up to a maximum of 5 bytes. The numbers represented by the least 7 significant bits of each byte are then used to give the total length. An example is : The number 0x810D would be decoded as : BYTE 1 BYTE 2 1 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1

It will be appreciated that the invention allows for control of billing data in a simple, reliable, and versatile manner. For example, this allows choice of which party obtains the"value-added"benefit for transactions or other application operations. It also allows pre-paid billing functionality by providing data for a subscriber account on a pre-paid billing platform. This may, for example, be used to determine if requested content should be returned to the subscriber. The returned data could also be used to influence other decision-making procedures in the gateway. Because the log entry is made after the client acknowledgement, the user will not be billed if there is a transmission error or if the user cancels.

The invention is not limited to the embodiments described but may be varied in construction and detail. For example, while the event messages are received and processed by a WAP gateway, they may alternatively be processed by any routing node between the application and the user device. The term"gateway"is intended to mean any such node or device.