US20030069855A1

US20030069855A1 - Control server for supporting the charging of services

Info

Publication number: US20030069855A1
Application number: US10/262,851
Authority: US
Inventors: Thomas Hormann; Nicholas Prinz
Original assignee: Alcatel SA
Current assignee: Alcatel Lucent SAS
Priority date: 2001-10-04
Filing date: 2002-10-03
Publication date: 2003-04-10
Also published as: US20050194821A1; EP1300323A3; JP2003160065A; US7104350B2; JP3960894B2; EP1300323A2; DE10149116C1; DE50202307D1; EP1300323B1; US20030098192A1

Abstract

The invention concerns a Process and a control server for supporting the charging of services that are provided to a service user by a service server. A service request message from a terminal of the service user, requesting a service, is transmitted via a communication network to the service server. The service request message and one or more replies from the service server sent out on the service request message are routed via a control server. The control server carries out a procedure for the authentication of the service user and, using the result of the procedure, determines whether or not the charging of services requested by the service user is supported by the control server. The control server checks whether the reply from the service server contains an identification code, that classifies the requested service as chargeable. The control server prevents the provision of the requested service if the requested service is classified as chargeable and the control server has not determined that it supports the charging of services requested by the service user.

Description

BACKGROUND OF THE INVENTION

The invention is based on a priority application No. DE 101 49 160.3, which is hereby incorporated by reference.

The invention concerns a process and a control server for supporting the charging of services that are supplied to a service user by a service server. In such a type of process a service request message for requesting a service is transmitted from a terminal of the service user via a communication network to the service server.

There is the problem, particularly in the area of services offered in the Internet, as to how the user of a service can be charged for the use of the service. The invention is based on the process described below for charging services that are offered to a service user via the Internet.

The so-called NET900 service employs a special dial-in node in the Internet in order to charge the service user for the use of information, to which he/she has access via the Internet. A service user can access this service only by dialling in via this dial-in node, to which a special telephone number is allocated. A call to this dial-in node is charged at a higher rate by the charging system of the telephone network than that of a “normal” dial-in node.

The disadvantage of such a process is that it can only be employed for an Internet access by means of ISDN (Integrated Services Digital Network) or modem.

Further solutions consist in installing special software modules on the terminal of the service user and on the server of the service provider, which facilitate payment of services by means of “electronic money”. The software module in the terminal can be loaded with “electronic money”, which is then used for payment of services.

These solutions have the drawback that they require the use of special terminals and are only usable in the pre-paid area.

SUMMARY OF THE INVENTION

The object of the invention is now to facilitate a user-friendly charging of services and in so doing keep the technical outlay as small as possible.

Here a service can consist, for example, in the delivery of information, data or software, but also in the sale of “concrete” goods.

The invention has the advantage that no special hardware or software is required in the terminal area. It is thus particularly economical and user-friendly.

Furthermore, the entire charging process is transparent for the service user and service server. Existing charging systems can be integrated in a simple manner. The technical outlay for the introduction of the invention into existing systems is thus also very small.

Advantageous developments of the invention are revealed in the sub-claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is explained below by means of several exemplifying embodiments and with the aid of the attached drawings. [0013]
FIG. 1 shows a block diagram of a system with several service users, several service servers and two control servers according to the invention. [0014]
FIG. 2 shows a functional representation of a control server according to the invention, as in FIG. 1. [0015]
FIG. 3 shows a first flowchart of the communication between a terminal and a service server. [0016]
FIG. 4 shows a second flowchart of the communication between a terminal and a service server. [0017]
FIG. 5 shows a third flowchart of the communication between a terminal and a service server. [0018]
FIG. 6 shows a fourth flowchart of the communication between a terminal and a service server.[0019]
FIG. 1 shows two communication networks KN[0020] 1 and KN2, three service users SU1 to SU3, to which respective terminals TE1, TE2 and TE3 are assigned, two control servers CC1 and CC2, two charging systems BS1 and BS2, and four service servers SS1 to SS4.
The communication networks KN[0021] 1 and KN2 involve the Internet, that is to say a communication network that uses the IP protocol (Internet protocol) as level 3 protocol. However, the communication networks KN1 and KN2 can also be formed by different types of communication networks.
The communication network KN[0022] 1 can be formed by a data network, for example, that itself is composed of different sub-networks. Such sub-networks can be assigned to different network operators, for example. These sub-networks can also be mobile radio networks in which communication is based, for example, on the DECT, GSM, UMTS or Bluetooth standards (DECT=Digital European Cordless Telecommunication, GSM=Global System for Mobile Communication, UMTS=Universal Mobile Telecommunications System). Such sub-networks can also be formed by telephone networks (data transmission by means of modem or ISDN). The communication network KN1 can also consist entirely of a telephone network.
The communication network KN[0023] 2 can be formed by a data network, for example, that is based on a LAN (Local Area Network) protocol. Here again it is theoretically possible for the communication network KN2 to be a telephone network.
Each of the service servers SS[0024] 1 to SS4 are formed by one or more interconnected computers and by the software running on these computers. In each case, the service servers SS1 to SS4 provide the service users SU1 to SU3 with one or more services. Here the services provided by the service servers SS1 to SS4 can be of a different nature: for example the delivery of information, data, programs, user-controlled filtering of information or the sale of goods and services.
The service users SU[0025] 1 to SU3 access the service servers SS1 to SS4 by means of the Internet. But it is also possible for the service users to access the service servers SS1 to SS4 by means of the WAP (Wireless Application Protocol) or by means of a telephone terminal. Depending on the type of access, the service servers SS1 to SS4 thus fulfil the function of a WEB server, WAP server or IN (Intelligent Network), SCP (Service Control Point) and are accordingly technically equipped.
The terminals TE[0026] 1 to TE3 are computers that are equipped with hardware and software components for communication via the communication network KN1. The terminals TE1 to TE3 therefore have a WEB browser via which they access the services provided by the service servers SS1 to SS4. It is also possible for the terminals TE1 to TE3 to be WAP terminals, UMTS terminals or just standard telephone terminals.
The control servers CC[0027] 1 and CC2 are used to support the charging of services supplied to the service users SU1 to SU3 by the service servers SS1 to SS4. In this case, on the one hand it is possible for the control servers CC1 and CC2 to be assigned in each case to one specific group of service users. The control server CC1 Processes, for example, all service requests of the subscribers of a specific network operator or Internet access operator. On the other hand, it is possible for the control servers CC1 and CC2 to be assigned in each case to one or more service servers. The control server CC2 Processes, for example, all service requests that are directed to services of a specific service operator.
Here service servers and control servers can also constitute logic function blocks that are implemented by applications programs running on the same hardware platform. [0028]
The charging systems BS[0029] 1 and BS2 constitute systems by which charges for the use of the telecommunication services are billed to the service users. In this case the charging systems BS1 and BS2 can reduce a sum of money previously paid in (pre-paid) by the respective charges incurred. There is an additional facility whereby the charges incurred in a specific time period are added and billed to the user at the end of the time period. The charging system BS1 can be, for example, the usual charging system of a first telephone network operator and the charging system BS2 that of a second telephone network operator. However, the charging systems BS1 and BS2 can in each case also be the payment system of a bank or credit institute.
To request a service, the terminal TE[0030] 1 of the service user SU1 sends a service request message to the service server SS1. This service request message can, for example, consist of an HTTP/IP (Hypertext Transport Protocol) message that is directed to the Internet address or the WEB address of the service server SS1. However, this service request message can also be a call request message of a telephone network, which is addressed to an IN service provided by the service server SS1.
The service request message is transmitted to the service server SS[0031] 1 via the communication networks KN1 and KN2, and via the control server CC1. For this, the routing line in the communication networks KN1 and KN2, or the addressing of the services provided by the service servers SS1 to SS4, is selected so that communication between the terminals TE1 to TE3 and the service server SS1 takes place via the control server CC1. The service request message and one or more replies of the service user SS1 sent out on the service request message are therefore routed via the control server CC1.
On receipt of the service request message from the terminal TE[0032] 1, the service server SS1 sends a reply to the terminal TE1. This reply can be used for the provision of the service. However, the exchange of several messages between the terminal TE1 and the service server SS1 can also take place before the service is provided by the service server SS1.
The control server CC[0033] 1 checks whether the reply from the service server SS1, or one of the replies from the service server SS1 contains an identification code that classifies the requested service as chargeable. This identification code can also consist of a symbol in the reply code or consist of a specific file name.
If this is the case, then the control server CC[0034] 1 carries out a procedure for authenticating the service user and determines from the result whether or not the charging of services being requested by the service user SU1 is supported by the control server. It is also possible for the service server to carry out this procedure independently of the reply from the service server. It is also possible for the service server to carry out this procedure only once in the case of successive requests from several services.
The procedure for authenticating the service user can also contain an authorisation procedure, pre-price information at the service user or an explicit sales confirmation by the service user. [0035]
The control server CC[0036] 1 thereupon prevents the provision of the requested service if the requested service is classified as chargeable and the control server has not determined that it supports the charging of services that are being requested by the service user. Here the control server CC1 can, for example, prevent the provision of the requested service by not forwarding replies from the service server SS1 to the terminal TE1 or not forwarding messages from the terminal TE1 to the service server SS1. The forwarding of an alternative content can replace the non-forwarding action. Furthermore, the control server can also send to the service server SS1 a special control message that prevents the provision of the service. This can also be done by means of a suitable manipulation of a message forwarded to the service server SS1.
The detailed mode of operation of the control server CC[0037] 1 is now explained with the aid of FIG. 2.
FIG. 2 shows the control server CC[0038] 1 that communicates with the terminals TE1 to TE3 and with the service servers SS1 to SS4, and with the charging system BS1.
The control server CC[0039] 1 has one or more interconnected computers and a software platform running on these computers. Several application programs run on this software platform. During the execution of these application programs on the system platform of the control server CC1, formed by the hardware and software platform, the control server CC1 is controlled in such a way that the control server CC1 carries out the function of the control server CC1 as described below. The application programs and the system platform needed to run the application programs thus form a control unit CONTR, which is configured in such a way that it carries out the functions of the control server CC1 as described below.
From a functional point of view, the control unit CONTR has three functions SH, AUT and LOG. [0040]
The AUT function carries out a procedure for authenticating service users. Using the result of the procedure, it determines whether or not the charging of services that are requested by a service user is supported by the control server. [0041]
During the procedure for the authentication of service users, the control server requests from the service user a user identification code, a password or an electronic signature, for example. Using these data, the function SH then checks which service user is requesting the service. [0042]
During the procedure for the authentication the service user, the control server CC[0043] 1 can also check the authorisation by a charging system. Only with positive authorisation does it determine that the charging of services that are requested by the service user is supported by the control server.
The authentication and authorisation of the service user can be implemented by the control unit CONTR alone or with the support of the charging system BS[0044] 1.
Data for authenticating the service user can be stored locally in the control server CC[0045] 1. Furthermore, data that specify an authorisation of the charging system BS1 for certain charges or for a certain charge level can be stored locally in the control server CC1 for the service user. A general authorisation for all charges incurred by a specific service user is also possible. These data specify a type of “pre-paid” account, for example, which is reduced by each payment process, or form a type of credit frame for charges incurred by the service user. Using these data, the AUT function checks the authentication of the service user and determines whether there is an authorisation for the respective charges in the context of the local, existing information. If the local frame is used up, then recourse is made to the charging system BS1. Especially in the case of small charges, this procedure has the advantage that the charging outlay is very small and the charging costs are reasonable in comparison with the incurred charges.
A further possibility is that a server of this charging system is accessed for checking the authorisation of the charging by the charging system BS[0046] 1. Using the transmitted data, this server determines whether it approves a charging procedure in every individual case.
The function SH processes the messages received by the control server CC[0047] 1, which come from the terminals TE1 to TE3 and from the service servers SS1 to SS4. For each request for a service by one of the terminals TE1 to TE3, which is routed via the control server CC1, a process is started by the function SH, that controls the Processing of the respective service session by the control server CC1. Three processes CH1 to CH3 are shown in FIG. 2 by way of example.
The process CH[0048] 1 is started on receipt of a service request message and forwards the service request message to that service server to which it is directed. It checks whether the reply or one of the replies of the service server to the service request message contains an identification code, which classifies the requested service as chargeable.
The process CH[0049] 1 further decides if and when the AUT function is carried out for this service session: the determination as to whether or not the charging of services being requested by the service user is supported by the control server CC1, can in this case be made at each request for a service. However, it is also possible for this determination to be valid for the request for two or more services.
With positive authorisation by another control server, for example by the control server CC[0050] 2, the process CH1 can dispense with the execution of the AUT function and determine that the charging of services requested by the service user is also supported by the control server CC1.
The process CH[0051] 1 further prevents the provision of the service requested by the service user if the requested service is classified as chargeable, and the AUT function has not determined that the control server CC1 supports the charging of services that are requested by this service user.
The LOG function stores data that provide information about the chargeable services requested by the individual service users. Such data concern, in particular, the level of these charges. The stored data are transmitted to the charging system BS[0052] 1 at specific intervals or directly for billing.
The detailed mode of operation of the control unit CONTR is also shown by the process sequences represented by way of example in FIGS. [0053] 3 to 6.
FIG. 3 illustrates the mode of operation of the control unit CONTR for the case where a non-chargeable service is requested by the terminal TE[0054] 1.
A service request message REQ[0055] 1, which contains the request for a specific HTML page, for example, is transmitted by the terminal TE1 to the control server CC1. The latter forwards the service request message REQ1 unchanged to the service server SS1. The service server SS1 transmits a reply ANS1, which contains the requested HTML page, for example, to the control server CC1. The control server CC1 checks the reply ANS1 and determines that this is not classified as chargeable. It therefore forwards the reply ANS1 unchanged to the terminal TE1.
FIG. 4 shows the mode of operation of the control unit CONTR for the case where a chargeable service is requested by the terminal TE[0056] 1.
A service request message REQ[0057] 2, which contains for example the request for a specific HTML page, is transmitted by the terminal TE1 to the control server CC1, which forwards the service request message REQ2 unchanged to the service server SS1. The service server SS1 transmits a reply ANS2(PT) to the control server CC1. The reply ANS2(PT) contains an identification code PT that classifies the requested service as chargeable. Furthermore, the identification code PT contains additional data that specify the level of charges, or refer to a specific charging system.
The control server CC[0058] 1 checks the reply ANS2(PT) and determines that this is classified as chargeable.
Since the reply ANS[0059] 2(PT) contains the identification code PT, which classifies the requested service as chargeable, the control server CC1 carries out a procedure for the authentication of service users. For this it sends an HTML page LOGP to the terminal TE1. This page requests the service user SU1 to enter data for his authentication and to confirm that he wishes to accept this chargeable service.
If the control server CC[0060] 1 hereupon receives a user name UN, a password PW and a confirmation PA, then it checks the authenticity of the service user SU1 and the authorisation for the charging. If the result of the authentication and authorisation is positive, then it determines that the charging of services requested by the service user SU1 is supported by the control server CC1 and sends a message AD to the service server SS1. On receipt of the message AD, the service server determines an authorisation code PAC and a session cookie SCOOK and transmits both to the control server CC1, which transmits these to the terminal TE1. Here the session cookie SCOOK contains a data record with service user-specific data.
Advantageously, both the session cookie SCOOK and the authorisation code PAC are provided with a specific expiry time. The session cookie SCOOK is given a parameter, for example, that instigates the erasure of the session cookie SCOOK from the memory of the terminal TE[0061] 1. The authorisation code PAC is stored in the control server CC1 along with the time instant at which it had been generated. The authorisation code then becomes invalid after about 1 minute.
The session cookie SCOOK can contain the following service user-specific data, for example: language of the service user, currency in which the service user wishes to pay, country in which the service user is located, service user's operator, service user's charging scheme, time instant at which the session cookie becomes invalid, identification code of the session, or IP address of the service. [0062]
These service user-specific data can of course also be communicated between service server SS[0063] 1 and terminal TE1 in another way.
It is also possible for the authorisation code PAC and the session cookie SCOOK to be determined directly by the control server SS[0064] 1 and transmitted to the terminal TE1.
The session cookie SCOOK is stored by the terminal TE[0065] 1. The terminal TE1 is then induced to transmit a new service request message REQ5 to the control server CC1. In this case the service request message REQ5 contains the authorisation code PAC and the session cookie SCOOK.
The control server detects the session cookie SCOOK in the service request message REQ[0066] 5, determines an assigned session code SC and forwards the service request message REQ5 with the session code SC instead of the session cookie SCOOK to the service server SS1. The service server SS1 now sends a reply ANS3 via the control server CC1 to the terminal TE1. The reply ANS3 contains the requested chargeable WEB page CONT, the authorisation code PAC and the session code SC.
It is advantageous to determine the session code SC along with the authorisation code PAC and transport them to the terminal TE[0067] 1 in the session cookie SCOOK. However, the session code SC can also be transmitted to the terminal TE1 in another reply.
The control server CC[0068] 1 now checks the reply ANS3 to see if the session code SC and the authorisation code PAC are correct.
Using the session code SC, the control server CC[0069] 1 detects that the service furnished by the reply ANS3 is chargeable. A reply which results in a non-chargeable service contains no session code (see exemplifying embodiment in FIG. 3).
Using the check of the session code SC and the authorisation code PAC, the control server CC[0070] 1 detects whether the control server CC1 has determined that it supports the charging of services of the service user SU1. If the authorisation code and the session code is correct, then this is the case. This check can be made, for example, by means of a database in which the valid authorisation code and the assigned session codes are stored.
If the control server CC[0071] 1 detects that the service is classified as chargeable, and the control server has determined that it supports the charging of services of the service user SU1, then it forwards the reply ANS3 to the terminal TE1. In this case it removes the session code SC and the authorisation code PAC from the reply ANS3. If this is not the case, then it prevents the provision of the requested service by not forwarding the reply ANS3 of the service server SS1 to the terminal TE1.
FIG. 5 shows an alternative exemplifying embodiment to the exemplifying embodiment of FIG. 4 for the case where the terminal TE[0072] 1 accepts no cookies.
The exemplifying embodiment of FIG. 5 corresponds to the that of FIG. 4, except for the following differences. [0073]
A service request message REQ[0074] 3 from the terminal TE2 is forwarded to the service server SS1 via the control server CC1. No session cookie SCOOK is generated on pages of the service server SS1 and the authorisation code PAC is transmitted without session cookie SCOOK to the terminal TE2. However, it is possible for the session code SC to be transmitted to the terminal. The service request REQ5 contains no session cookie SCOOK (some service user-specific data could therefore also not be communicated between terminal TE2 and control server CC1).
FIG. 6 explains the mode of operation of the control unit CONTR for the case where a chargeable service is requested by the terminal TE[0075] 1 and an authorisation code PAC has already been determined in an earlier service request and transmitted to the terminal TE1. This is the case, for example, if, in connection with the exemplifying embodiment in FIG. 4, a service of the service server SS1 is requested again by the terminal TE1.
A service request message REQ[0076] 4, which, for example, contains the request of a specific HTML page, is transmitted by the terminal TE1 to the control server CC1, which forwards the service request message REQ2 unchanged to the service server SS1. Here the service request message REQ4 contains the session code SC that has been transmitted to the terminal during an earlier request for a chargeable service. The service server SS1 transmits a reply ANS2(PT) to the control server CC1. The reply ANS2(PT) contains the identification code PT that classifies the requested service as chargeable. The reply ANS2(PT) also contains the session code SC.
The control server CC[0077] 1 checks the reply ANS2(PT) and determines that this is classified as chargeable. It further determines that the reply ANS2(PT) contains a valid session code SC.
Since the reply ANS[0078] 2(PT) contains the identification code PT, which classifies the requested service as chargeable, and the reply contains a valid session code SC, the control server CC1 does not carry out any procedure for the authentication of service users. Rather, it sends an HTML page CONFP to the terminal TE1. This page requests the service user SU1 to confirm that it wishes to accept this chargeable service. The transmission of the CONFP page could of course also be dispensed with.
The procedure for the authentication of service users is therefore not carried out if the reply from a service server to a service request message contains a valid session code. [0079]
If the service user SU[0080] 1 agrees with the request from the chargeable service, then the request message REQ5 with the authorisation code PAC and the session code SC is sent to the control server CC1. In this case the sending of this message and the management of the session code SC and the authorisation code PAC can be supported by the session cookie SCOOK, which is of course stored in the terminal TE1.
The request message REQ[0081] 5 is forwarded by the control server CC1 to the service server SS1, which then sends a reply ANS3 to the control server CC1. The reply ANS3 is handled by the control server CC1 like the reply ANS3 in FIG. 4.

Claims

1. A method for supporting the charging of services that are provided to a service user by a service server, wherein a service request message for requesting a service is transmitted by a terminal of the service user via a communication network to the service server, wherein the service request message and one or more replies of the service server sent out on the service request message are routed via a control server, the control server carries out a procedure for the authentication of the service user and, using the result of the procedure, determines whether or not the charging of services requested by the service user is supported by the control server, the control server checks whether the reply of the service server contains an identification code that classifies the requested service as chargeable, and the control server prevents the provision of the requested service if the requested service is classified as chargeable and the control server has not determined that it supports the charging of services that are requested by the service user.

2. A method according to claim 1, wherein during the procedure for the authentication of the service user, the control server also checks the authorisation by a charging system, and only in the case of positive authorisation, determines that the charging of services requested by the service user is supported by the control server.

3. A method according to claim 2, wherein during the checking of the authorisation by a charging system, the control server accesses a server of the of the charging system.

4. A method according to claim 1, wherein in the event of positive authorisation by another control server, the control server determines that the charging of services requested by the service user is supported by the control server.

5. A method according to claim 1, wherein the determination as to whether or not the charging of services requested by the service user is supported by the control server, is made at each request for a service.

6. A method according to claim 1, wherein the determination as to whether or not the charging of services requested by the service user is supported by the control server, is valid for the request for two or more services.

7. A method according to claim 1, wherein the service request message and one or more of the replies of the service user sent out on the service request message are routed via a control server assigned to the service operator of the requested service.

8. Control server for supporting the charging of services that are provided to a service user by a service server, wherein the control server is provided with a control unit that is configured in such a way that it carries out a procedure for the authentication of service users and, using the result of the procedure, determines whether or not the charging of services requested by a service user is supported by the control server, that the control unit is further configured in such a way that it checks whether the reply of a service server to a service request message of a service user contains an identification code that classifies the requested service as chargeable, and the control unit is further configured in such a way that it prevents the provision of a service requested by a service user, if the requested service is classified as chargeable and said control unit has not determined that the control server supports the charging of services requested by this service user.

9. Control server according to claim 1, wherein the control unit is further configured in such a way that it prevents the provision of a service requested by a service user if the service user is not entitled to its use, or the service user does not authorise the payment required for use.

10. Control server according to claim 1, wherein the control unit is further configured in such a way that it forwards a service request message received by a terminal of a service user to a service server.

11. Control server according to claim 1, wherein the control unit is further configured in such a way that it carries out the procedure for the authentication of service users if the reply from a service server to a service request message of a service user contains an identification code, that classifies the requested service as chargeable.

12. Control server according to claim 1, wherein the control unit is further configured in such a way that it determines an authorisation code for a service user if it determines that the charging of services requested by the service user is supported by the control server, and that it transmits the authorisation code to the terminal of the service user.

13. Control server according to claim 1, wherein the control unit is further configured in such a way that it requests the service server to determine an authorisation code for a service user, if it determines that the charging of services requested by the service user is supported by the control server.

14. Control server according to claim 1, wherein the control unit is further configured in such a way that it determines a session code for a service user, if it determines that the charging of services requested by the service user is supported by the control server, and that it transmits the session code to the terminal of the service user, and that the control unit is further configured in such a way that it does not carry out the procedure for the authentication of service users if the reply from a service server to a service request message contains the session code.

15. Control server according to claim 1, wherein the control unit is further configured in such a way that it determines for a service user a data record with service user-specific data, in particular a cookie, and transmits it to the terminal of the service user.

16. Control server according to claim 1, wherein the control unit is further configured in such a way that it prevents the provision of a service requested by a service user, so that it does not forward a reply from the service server to a service request message to the terminal of the service user.