EP1337950A1

EP1337950A1 - Control of billing in a communications system

Info

Publication number: EP1337950A1
Application number: EP01983624A
Authority: EP
Inventors: Pekka Lahtinen; Philip Ginzboorg; Pekka Laitinen; Jyri Salomaa
Original assignee: Nokia Oyj; Nokia Inc
Current assignee: Nokia Technologies Oy
Priority date: 2000-11-28
Filing date: 2001-11-15
Publication date: 2003-08-27
Also published as: AU2002215069A1; FI20002614A7; FI20002614L; FI20002614A0; WO2002044962A1

Abstract

The invention relates to the control of billing in a communications network. In order to achieve the free placement of billing information coupled with a minimum amount of modifications for standard servers, a proxy/gateway is used for detecting the resource requests related to chargeable resources, and for mapping the resource identifier of a chargeable resource, received in a resource request, to a locator referring to the pricing information relating to said chargeable resource. The pricing information is then retrieved from the address indicated by the locator, and the billing is initiated using the information retrieved.

Description

CONTROL OF BILLING IN A COMMUNICATIONS SYSTEM

Field of the Invention

The invention relates generally to the accessing of services in a communications system. More specifically, the invention relates to a method and an apparatus for controlling billing in connection with service provision. A service here refers generally to a process in which a client contacts a content server and a session is established between the two.

Background of the Invention

The strong growth in the number of Internet users and services provided through the Internet has been one of the most remarkable phenomena in communications in recent years. Another current trend is the strongly increasing use of various mobile terminals, such as laptops, PDA (Personal Digital Assistant) equipment, and intelligent telephones.

These two rapidly evolving network technologies, wireless communication and the Internet, are gradually converging to make the packet switched data services used in the Internet available to mobile users. So far this converging development has occurred rather slowly, since most of the technology developed for the Internet has been designed for desktop computers and medium or high bandwidth data connections. It has, therefore, been difficult to introduce the IP-based (IP; Internet Protocol) packet services to the mobile environment, which is characterized by less bandwidth and poorer connection stability in comparison to fixed networks, and where the terminals have many fundamental limitations, such as smaller displays, less memory, and less powerful CPUs, as compared to fixed terminals. However, the development of IP-based (IP; Internet Protocol) packet services for the mobile environment will occur at an increasing rate in the foreseeable future. This is partly due to the demand created by the market and partly due to the evolvement of new technologies designed to meet the various requirements of mobile networks, such as sufficient quality of service and data security. The increasing market demand is based on the rapid increase in the popularity of the Internet: Internet users are often also mobile subscribers and thus may also want to use in their mobile terminals the services familiar to them from the Internet environment. This commercial demand in turn enables investments necessary for the development of mobile services. The said new technologies include GPRS (General Packet Radio Service) and WAP (Wireless Application Protocol), for example. GPRS aims at providing high-quality services for GSM subscribers by efficiently utilizing the GSM infrastructure and protocols. WAP, in turn, defines a set of standard components enabling communication between mobile terminals and servers providing service in the network. WAP utilizes proxies which connect the wireless domain with the WWW domain.

The introduction of services in these new network environments is not a straightforward task, due to the different network technologies used and the fact that several parties (organizations) are involved. One area to be solved in connection with the introduction of services is the implementation of billing, i.e. how to implement efficient billing processes when an end user who is typically in the wireless domain uses the services provided by the WWW domain. Since a large network may include a large number of service and/or content providers, each of which can provide both free content and chargeable content with a variety of prices, one of the billing-related problems concerns the maintenance of updated pricing information and the activation of billing with correct pricing information. European published Patent Application 924630 describes a method for resource retrieval over a data network. In this method, a separate proxy server handles access control and billing functionalities. In order to find out the price related to a resource requested in a request from a client, the proxy intercepts all resource requests directed to a content server. The proxy caches each request and sends a header request to the content server, requesting the content server to transmit a header associated with the requested resource back to the proxy. The header informs the proxy about the billing and/or access information associated with the requested resource, whereby the proxy authenticates the client's right to receive the requested resource whenever the header indicates that there are billing and/or access restrictions involved. Thus, in this system the billing information (such as the price) related to the resource is in conjunction with the resources in the content server, and the proxy queries the information by means of the header request. Although a mechanism like this, using a proxy for handling access control and billing functionalities, allows the content server to communicate transparently with a separate billing server, certain modifications to a standard HTTP server are required in order for the server to operate as a content server, i.e. the server needs to be configured for reading price update information. Moreover, with this method of caching each request and sending a header request to the content server, the location of the pricing information is bound to that of the content, although the free placement of pricing information would often be desirable for update and maintenance reasons. The content providers are namely often separate organizations providing their content in a network that can be operated by a large operator. In order to allow the operator to control the prices of the resources offered in its network, the free placement of pricing information is desirable, instead of binding the location of the pricing information to the location of the corresponding resource.

The objective of the invention is to obtain a solution for eliminating the drawbacks described above, while also bringing about a solution allowing the free placement of the pricing information coupled with a minimum need for server modifications.

Summary of the Invention The objective of the invention is to devise a mechanism, which allows chargeable services to be billed so that the prices can be controlled and maintained efficiently, especially in larger networks or sub-networks, where the services can include content from a plurality of content providers.

This objective is achieved with the solution defined in the independent patent claims.

The idea of the invention is to use a proxy/gateway for detecting the resource requests which relate to a chargeable resource, and for mapping to another identifier the resource identifier, such as the URL (Uniform Resource Locator), received in a request. The said other identifier, which is called a locator in this context, refers to the pricing information associated with the requested resource. Thus, the locator is an identifier identifying the whereabouts (i.e. address) of the pricing information. The pricing information is then retrieved from the address to which the locator refers, and billing is requested from a separate billing entity, using the pricing information retrieved. According to one aspect of the present invention, a method for controlling billing in a communications network is provided, the method comprising

- receiving resource requests at a proxy located in the communications network between a client and a content server, - detecting the requests relating to a chargeable resource,

- mapping the resource identifier of a chargeable resource to a locator referring to the pricing information related to said chargeable resource,

- accessing said pricing information by means of said locator, and - sending a billing request to a billing entity, the billing request to include at least part of said pricing information.

In one preferred embodiment of the invention, the detection of those resource requests addressing a chargeable resource includes the filtering out of requests which clearly point to a free resource, so that only those resource requests which are not filtered out are passed further to the mapping process.

Although the pricing information can be placed anywhere in the network, it is preferable to store at least part of it in conjunction with a proxy/gateway which can detect the requests relating to a chargeable resource and find out the address of the pricing information. In this way, at least part of the pricing information retrievals can be carried out without sending messages to the network. A corresponding benefit relates to a proxy which includes said billing entity. Thus, in one preferred embodiment of the invention the proxy performs the above detection and mapping steps, stores the pricing information, and serves as a billing server. In present-day networks such a proxy can be a WAP gateway, for example.

Brief Description of the Drawings

In the following, the invention and its preferred embodiments are described more closely referring to the examples shown in FIG. 1 to 9 in the appended drawings, wherein:

FIG. 1 illustrates the basic architecture of the present invention, FIG. 2 illustrates the architecture of one embodiment of the present invention, FIG. 3 is a flow diagram illustrating the operation of one embodiment of the system, FIG. 4 illustrates the message exchange between the elements of the system, FIG. 5 illustrates the layout of a content URL,

FIG. 6 illustrates the separation of requests relating to chargeable content from requests relating to free content, FIG. 7 illustrates the treating of the content URL as a sequence of words in the URL mapping process, FIG. 8 illustrates a search tree used in the URL mapping process,

FIG. 9 illustrates the final mapping from the content URL to the price URL, and FIG. 10 illustrates an example of the structure of a record in a price repository.

Detailed Description of the Invention

FIG. 1 is a schematic presentation of the system of the present invention. During a service session established in the system, the client typically downloads content or resources from the content server, i.e. from the point of view of the client, the service consists of the retrieval of resources/content from the content server.

Clients 10, such as Nokia 7110 or 9110i mobile terminals, request resources (i.e. content) from a network 11 using browsers or other client software by means of which they can communicate with the content servers CS of the network. The resource requests (also called content requests in this context) from the client are directed to a proxy or gateway GW which (1 ) detects the requests for chargeable content and (2) maps the resource identifier, such as the URL, in each of said requests to a price information locator, such as a price URL, which indicates the address in the network of the pricing information related to the chargeable resource referred to in the request. The proxy/gateway then retrieves the pricing information from the indicated location, which can be a common price repository/database PR in the network, and requests billing from a billing server BS. As discussed below, the billing server and the gateway/proxy can be combined so as to be located at the same site. Since the pricing information can be placed freely, it can reside in a separate server somewhere in the network, in connection with the gateway/proxy or the content server, or it can be distributed among several servers.

The billing server of the system according to the invention can be similar to the billing server described in U.S. Patent 6,047,051 , for example.

However, the billing server according to the invention can further have a book-keeping feature for maintaining up-to-date information on the requests utilizing pricing information from a price repository.

FIG. 2 is a schematic presentation of the architecture of one embodiment of the invention, the proxy being now a WAP gateway and the client UT being a WAP-compliant terminal. As is known, the WAP architecture includes a gateway with encoders and decoders. In order to reduce the amount of data sent via a radio channel to the terminal, an encoder encodes the content received from a server into a compact encoded format. Accordingly, a decoder decodes the encoded data received from a radio channel before the data is forwarded to the server. Due to its role as the operator-controlled intermediary between the radio network and the Internet, the gateway knows, inter alia, the MSISDN number (Mobile Subscriber ISDN Number) of the subscriber relating to the client. The connections between the terminal and the gateway typically use WSP (Wireless Session Protocol), whereas the connections between the gateway and the server typically use HTTP. The gateway, therefore, performs translations from the WAP protocol stack (WSP, WTP, WTLS, and WDP) to the WWW protocol stack (HTTP and TCP/IP). The gateway can also perform content conversion. If the server provides WWW content (such as HTML), the gateway can translate the WWW content into WAP content (WML).

FIG. 2 shows two separate price repositories, PR1 and PR2, and two content servers, CS1 and CS2. In this example, it is further assumed that the billing server BS is located at the gateway, although for this invention the billing server can be anywhere in the network. It will be understood that there can be more than two repositories or servers.

With reference to the flow diagram of FIG. 3 and to the message diagram of FIG. 4, a sample process of chargeable content downloading in the system of FIG. 2 is now illustrated. For the sake of clarity, the reference numerals of the messages in FIG. 4 correspond to the reference numerals of the steps shown in FIG. 3.

When a WAP-compliant client requests content from a content server, the client connects, through a browser, to the operator-controlled gateway GW and sends a GET request with the address, i.e. the URL, of the desired resource (step 30). In response to the request, the gateway initiates a process in which it first detects whether the requested resource is chargeable or not (step 31). If the gateway finds out that the request is related to a chargeable resource, it maps the URL of the resource to the URL of the corresponding pricing information, i.e. performs a price location mapping (step 32). Having obtained the URL of the pricing information, which is here denoted by URL', the gateway sends a HTTP GET message requesting the pricing information specified by URL' (step 33). In response to this request, the price repository addressed to by the pricing information URL sends the gateway a price file including the pricing information of the requested resource (step 34). The gateway then extracts the desired information from the file (step 35) and sends a billing request to the billing server (step 36). The billing request includes preferably at least the subscriber ID (i.e. the MSISDN), the price received from the price repository, and the URL of the chargeable content. If the billing server acknowledges successful billing (step 37), the gateway creates an HTTP session with the content server concerned and sends a GET request for the content specified by the URL (step 40). The content server processes the request and sends the HTTP content to the gateway (step 41), which then returns the encoded WAP content to the client (step 42). In addition to the above steps, the client can be informed of the price of the resource after the billing server has acknowledged successful billing at step 37, so that the client has a chance to accept or reject the price. These steps, which have been denoted by reference marks 39a and 39b in FIG. 4, are optional since the client typically knows the price of at least some services in advance. If the billing server does not, for some reason, acknowledge billing at step 37, an error message informing the client of the situation is returned to the client at step 39a. Furthermore, if it is detected at step 31 that the original request received from the client does not specify chargeable content, but rather free content, the process jumps to step 40, i.e. the process is continued according to steps 40, 41 , and 42. The proxy/gateway must rapidly process large amounts of content requests, only some of which relate to chargeable content. It is, therefore, important that the gateway (1) efficiently separates the requests for free content from the requests for chargeable content and (2) quickly maps the content URL to the price URL whenever it detects that the content URL points to chargeable content.

These steps can be carried out in multiple ways, one alternative being now described with reference to FIG. 5 through 9.

As illustrated in FIG. 5, the proxy/gateway GW receives a content URL, which consists of a protocol identifier 2, a domain name 3 of the content server, a directory path 4 leading to the directory where the content is located, and the content file name 5.

FIG. 6 illustrates a fast method for filtering out the majority of requests for free content. It is assumed here that only some content servers, identified by their domain names 3, offer chargeable content. When the WAP gateway processes a resource request, it passes all domain names through a hash function 6, which maps each domain name to an integer value k; said k can be any integer between zero and an upper limit N-1. A bit string P consisting of N bits is then indexed with the integer value output by the hash function, whereby a certain bit P[k], denoted by the reference numeral 9 in FIG. 6, of the bit string is arrived at. This bit is called here the payment flag. If the value of the payment flag is one, the content may be chargeable, and the procedure continues. However, if the value of the payment flag is zero, the content is not chargeable, and the content request can be forwarded directly to the content server. In other words, the process can jump from step 31 directly to step 40 (cf. FIG. 3).

Prior to the filtering operation described above, the operator of the WAP gateway sets each such bit in the bit string to the value of one, to which at least one of the domain names with chargeable content is mapped by the hash function. The other bits are set to zero. Since the hash function may be overlapping, i.e. since it may map several domain names to the same integer value k, the fact that the payment flag 9 has the value of one does not necessarily indicate that chargeable content does exist behind this domain name, let alone that the content specified by the actual URL being processed is chargeable. However, the filtering operation illustrated in FIG. 6 provides a means for speeding up the processing of most content requests. Furthermore, the operator of the WAP gateway can control the number of potential hash overlaps with well-known methods by choosing the hash function and the size of the bit vector in a suitable way. If the payment flag 9, which is read in the above-described manner, has the value of one, the procedure continues as follows.

The domain name 3, the directory path 4, and the file name 5 of the content URL are now handled as a sequence of words 10, separated by the slash character ". The separate words of the content URL are illustrated in FIG. 7.

The word sequence is then matched in a known manner against a word sequence search tree or some other suitable data structure or database. A simple example of such a search tree 11 is illustrated in FIG. 8. The search in the tree proceeds from root 13 through nodes 14 to payment locations 12, which are either addressed from the leaf nodes of the tree or which compose the leaf nodes of the tree. In the search tree of FIG. 8, the dash character "*" indicates a node which matches any sequence of words, while each of the other nodes match one word in the sequence. The organizing of such a search tree is obvious to a person skilled in the art, while the technology preferred at any one time depends, for example, on the size of the search tree and on the storage types available.

For each sequence of words extracted from the content URL, a certain number of words have a "match" in the search tree 11 , leading to a payment location 12. As shown in FIG. 8, the payment locations may have two types of data: either a free content indicator 17 or a combination of a prefix 15 and a suffix 16.

If a free content indicator 17 is found in the search process, the content is not chargeable, and the request is sent to the content server. In other words, the process can jump from step 31 directly to step 40 (cf. FIG. 3). If a prefix-suffix pair is found instead, the content is indeed chargeable and a pricing information retrieval must be performed. For this purpose, a price URL is computed from the original content URL, as illustrated in FIG. 9, where the price URL is denoted by the reference numeral 20. The words that match the search tree 11 (FIG. 8) are replaced with the prefix 15, and the suffix 16 is appended to the result. The protocol identifier 2 and the unmatched part 19 of the word sequence remain unchanged.

In the example of FIG. 8 and 9, the following mapping from the word sequence to the prefix-suffix pair is first achieved: www.provider.com/content/forwap

- www.provider.com/prices/forwap & .pr.txt

Thus, the following overall mapping from the content URL to the price URL is obtained: http://www.provider.com/content/forwap/wapstack.wml - http://www.provider.com/prices/forwap/wapstack.wml.pr.txt

Hence, the domain name 3 remains in its original form, the directory path 4 is replaced by a new one, and a suffix is appended to the file name 5. This is a suitable mechanism for cases where the pricing information is on the same server as the content, but in a different directory. By appending the suffix, the type of file to be returned as pricing information can be defined without adding any new intelligence to the HTTP server; for instance, the ".txt" ending of the URL typically denotes a plain text file. Thus, owing to the suffix, the pricing information file can be of any type supported by the HTTP server containing it. Owing to the prefix, and the way a word sequence is replaced by it, the pricing information can reside anywhere in the network.

If the pricing information is placed on the same server and in the same directory as the content, the search tree mapping can begin by first mapping from the word sequence www.provider.com/content/forwap to the prefix and suffix pair www.provider.com/content/forwap & .pr.txt which leads to overall URL mapping as follows: http://www.provider.com/content/forwap/wapstack.wml -» http://www.provider.com/content/forwap/wapstack.wml.pr.txt

Thus, only the suffix is appended to the content URL in order to obtain the price URL.

If it is desirable to have the pricing information on another server, the search tree mapping can be carried out by first mapping from the word sequence www.provider.com/content/forwap to the prefix and suffix pair www.prices.com/provider.com & .pr.txt which leads to overall URL mapping as follows: http://www.provider.com/content/forwap/wapstack.wml -> http://www.prices.com/provider.com/wapstack.wml.pr.txt

Thus, both the domain name and the directory path are now replaced by new items. Here, any domain name can be used, including a domain name referring to the WAP gateway; hence the pricing information can be on the WAP gateway itself.

The pricing information can even be retrieved from a database, rather than from a separate file. This is achieved, for instance, by using the known CGI (Common Gateway Interface) technique of creating dynamic content for the HTTP requests. To give an example, it is assumed here that the search tree mapping is performed by mapping from the word sequence www.provider.com/content/forwap to the prefix and suffix pair www.prices.com7provider.com & (empty suffix) which leads to overall URL mapping as follows: http://www.provider.com/content/forwap/wapstack.wml -> http://www.prices.com7provider.com/wapstack.wml

The HTTP request to the resulting price URL then executes a CGI script at the HTTP server http://www.prices.com with the argument string provider.com/wapstack.wml

The CGI script can now separate the argument string into two keys, the "provider.com" identifying the content server and the

"wapstack.wml" identifying the content on that server. These keys can then be used to fetch the price from the database. The pricing information must then be formatted into a suitable format and returned to the gateway/proxy as the result of the HTTP request.

Although the URL mapping of FIG. 9 leaves the protocol name 2 unchanged, the protocol name can be changed when desired in addition to the prefix 15 and the suffix 16, for instance by adding the price URL protocol name as a third field in the payment location 12 of FIG. 8.

As is obvious from the above examples of FIG. 5 through 9, the proxy/gateway can efficiently separate the free content URLs from the chargeable content URLs, as well as map the content URLs efficiently to the price URLs. As is also shown above, the location of the pricing information can be freely chosen, as well as the way of storing it and the protocol for accessing it.

FIG. 10 shows an example of the structure of a price file/record in the price repository. The last field shown in the figure indicates the way billing is settled. This field is preferably optional, and it can be overridden by the settlement method indicated in the user profile, which may be in the billing server, for example. Instead of the billing being included in the normal phone bill, the billing may also be settled through a credit card, an automatic bank transfer, etc.

Although the invention was described above with reference to the examples shown in the appended drawings, it is obvious that the invention is not limited to these, but may be modified by those skilled in the art without departing from the scope and spirit of the invention. For example, the price repository/database can send the pricing information directly to the billing entity, and optionally a confirmation to the proxy/gateway. The idea of the invention can also be applied to services in various other types of networks or systems.

Claims

1. A method for controlling billing in a communications network, the method comprising the steps of - receiving resource requests at a proxy located in the communications network between a client and a content server, whereby each resource request includes a resource identifier referring to the resource requested,

- detecting the requests relating to a chargeable resource, - mapping the resource identifier of a chargeable resource to a locator referring to pricing information relating to said chargeable resource,

- accessing said pricing information by means of said locator, and

- sending a billing request to a billing entity, the billing request including at least part of said pricing information.

2. A method according to claim 1 , wherein said accessing step includes retrieving the pricing information to the proxy.

3. A method according to claim 1 , wherein said resource identifier is the URL of the resource and the mapping step includes mapping said URL to another URL serving as said locator.

4. A method according to claim 1 , wherein the proxy is a WAP gateway, the steps being performed in said gateway.

5. A method according to claim 1 , wherein the method further comprises

- testing in the detecting step whether the request relates to a free resource, and

- in response to said testing, delivering the resource requests which pass said testing to the content server.

6. A method according to claim 5, wherein said testing includes

- inputting at least part of said resource identifier to a hash function, whereby a hashing result is obtained from the hash function,

- retrieving a payment indicator by means of the hashing result, a specific value of said payment indicator indicating whether the resource request immediately passes the testing.

7. A method according to claim 5, wherein said mapping step includes - matching at least part of the resource identifier against a predetermined data structure including pre-stored information for constructing said locators.

8. A proxy for controlling billing in a communications network, the proxy comprising

- first means for receiving a client-originated resource request intended for a content server, said requests to include a resource identifier addressing a resource on said content server,

- second means for detecting the requests related to a chargeable resource,

- third means for mapping the resource identifier of a chargeable resource to a locator addressing pricing information related to said chargeable resource,

- fourth means for delivering a billing request to a billing entity, said request to include at least part of the pricing information to which the locator refers, and

- fifth means for delivering the client-originated resource request to the content server.

9. A proxy according to claim 8, wherein the fourth means are adapted to retrieve said pricing information by means of said locator, and to send a billing request to the billing entity.

10. A proxy according to claim 8, wherein the second means are adapted to filter out resource requests relating to a free resource.

11. A proxy according to claim 10, wherein the second means include a hash function element for filtering out resource requests related to a free resource.

12. A proxy according to claim 8, wherein the third means include a data structure that stores data units for constructing the locators.

13. A proxy according to claim 12, wherein the data structure is a tree-like search structure.

14. A proxy according to claim 8, wherein the proxy is adapted to operate as a WAP gateway for receiving resource requests from WAP- compliant clients.

15. A proxy according to claim 8, wherein the proxy further includes said billing entity.

16. A proxy according to claim 8, wherein the proxy further includes said pricing information.

17. A proxy according to claim 8, wherein the proxy further includes said billing entity and said pricing information.

18. A system for billing in a communications network, the system comprising

- a proxy for receiving client-originated resource requests, including resource identifiers addressing resources on content servers, the proxy being adapted to detect the resource requests related to a chargeable resource, and to map the resource identifiers to locators addressing predetermined resources in the network,

- a database for storing pricing information related to the chargeable resources, whereby said pricing information represents said predetermined resources, and - billing means for billing for the use of said resources, the billing means being adapted to receive said pricing information.

19. A system according to claim 18, wherein the proxy is adapted to retrieve said pricing information from the database and to forward at least part of the information to the billing means.

20. A system according to claim 18, wherein the billing means is a billing server.