HK1115244A - Implementation of charging in a telecommunications system - Google Patents

Description

Implementation of charging in a telecommunications system

The present application is a divisional application of chinese patent application No.97180604.7 entitled "implementation of charging in a telecommunications system" filed 11/1997.

Technical Field

The present invention relates generally to the implementation of charging in telecommunications systems, and more particularly to the implementation of charging for multimedia services.

Background

Service billing is the implementation of a contract between a service provider and a client. In principle, there are two types of charging: distributed and centralized.

In distributed charging, a customer pays a fee to a vendor (vendor) each time the vendor provides a service. The payment may be made in cash, or by other comparable means. For example, the delivery of mail is paid by using a stamp. A more recent example of a payment method in distributed charging is electronic cash. Each "coin" of electronic cash contains an encrypted binary sequence that must be verified by the bank's server.

In centralized charging, the vendor or third party monitors the usage of the service. The client is charged periodically, for example once a month. The bill is based on data collected during a previous billing period. Three well known examples of centralized charging are telephone, telephone and credit card charging. The centralized charging consists of 3 phases. The first stage is the contract between the user and the service provider for the service and the charging of the service. The second phase is to monitor (or measure) and store the usage data. The third phase is the generation and distribution of bills for the customer. The bill processing system generates a bill based on the stored information.

For example, a centralized billing system used in a telephone network is based on a contract between the subscriber and the telephone company. The essence of the contract is that the subscriber has access to the telephone service, i.e. he/she can make and receive calls. In return he/she pays the telephone company according to a predetermined rate. Bills generally contain two types of charges: fixed costs and use costs. The fixed charges need to be charged whether or not the service is used. The usage charge then depends on how many calls the tenant has made and possibly also on how many calls he/she has received. In order to be able to bill for usage, the telephone company must monitor calls made and received. This monitoring is connection-based; i.e. it is done by a switch in the network.

Fig. 1 shows a part of a public telephone network to illustrate a well-known centralized charging method used by the telephone network. The network switch SW (the subscriber's local switch) creates one or more charging records CDR (charging data records) for each outgoing call. These records are first stored in memory and then sent to a centralized bill handling system, which stores them in mass storage, such as tape or hard disk. There may be additional processing stages between the switch and the bill processing system. At this stage, the billing records are pre-processed, i.e., prepared for the bill processing system. The pre-processing may include, for example, converting the rate category field to another format. The mass memory of the bill handling system may contain millions of records. These records form the "raw data" that the billing system processes. Thus, the processing of the billing records is performed in a separate batch process at a date after the record generation date. It should be noted that in practice charging may be much more complex than the example given here. For example, in a cellular network, each participating cellular network switch may generate a billing record. However, the charging principle is similar to the aforementioned principle.

The billing records will be referred to as "CDRs" hereinafter, and the procedure for generating these billing records will be referred to as "CDR generator".

Centralized charging of telephony services is based on offline charging, and there is a CDR generator in the network that records the time of setup and release. However, this type of charging is technically not suitable for the case of providing multimedia services in a network. There are two basic reasons for this. First, most multimedia services currently use IP (Internet protocol), which is used to provide connectionless services. Charging based on a telephone network connection is not suitable for such systems. Secondly, it is clear that the charging of multimedia services must be based on the content of the transmitted information. Current telephone networks can monitor set up and release times but cannot monitor what is being delivered. When using CDR generators, the network operator must choose between two schemes: either (a) charging is based on the connection, independent of the content, or (b) at each transfer, content information is obtained from the service provider for the transfer information. The first solution means that the operator cannot provide charging for the content; existing centralized telephone network bill processing systems cannot be effectively utilized. For the client this means that he/she gets a single bill from the operator, and in addition to this, a different bill from each service provider. The second solution requires a highly integrated, technically complex system, where there is a large amount of traffic between the server and the CDR generator.

ｃA billing system for ｃA communication network is described in european patent application EP- ｃA-0647052. The system has a separate bill processing server for processing bills of service providers in the network. In this system, the client terminal always first reports its own identity, as well as the identity of the required service, to the billing server. The billing server then determines whether the client is entitled to receive the service (e.g., whether the credit required for the service can be given). If so, the billing server sends a temporary service key to the server providing the service and the client terminal, which key allows the client terminal to access the server providing the service. The client terminal then sends a connection request message to the server providing the service, after which the two can negotiate for the service before service delivery. After delivery of the service, the server providing the service sends a report message regarding the provided service to a billing server, which prepares a bill for the client based on the message. The bill may be sent, for example, by E-mail or mail.

The main drawback of this type of system is that it cannot make use of existing systems except for the transport connection. To this end, setting up a billing service is a rather complicated operation. Furthermore, the information security of the system is not sufficiently guaranteed, for example in terms of denial prevention. This means that the customer must fully trust the accuracy of the numbers on the bill generated by the billing terminal. The client also has no idea of the amount on the resulting bill, for example, because of the delay in the network or other adverse factors, which may cause poor quality of service at the client terminal, because the server has delivered the service by contract. This is especially important in continuous long-term traffic.

Disclosure of Invention

The object of the present invention is to eliminate the aforementioned drawbacks and to propose a solution that makes it possible to use the existing systems for centralized charging as efficiently as possible, for example during billing processes for multimedia services.

This object is achieved by the solution defined in the independent patent claims.

The basic idea of the invention is to use at least one separate device (called "billing server") in the system, which negotiates an online contract with the client based on the service selected by the client; or at least may verify that the customer has accepted the specific terms of the service. The billing servers serve as a point of sending the billing records to the actual billing system, and furthermore they can verify the correctness of the billing records generated by the client terminal before storing and/or sending these records to the billing system. In practice, therefore, this solution is based to a large extent on the implementations already in the telephone network, with the difference that the service usage is no longer measured in the network and the accounting records or messages associated with it are generated, but rather these operations are performed by the client terminal, which sends these accounting records to the different billing servers.

The system according to the invention is easy to implement, since it uses existing solutions as much as possible. Furthermore, the principle of the system is that it is easy to implement all factors important for data security: authentication, data integrity, anti-repudiation (the party that transmitted the data cannot deny having participated in the transaction) and privacy (the eavesdropper cannot interpret any captured data),

the system also makes it easier for new service providers to start operation because of the existing billing solutions (i.e. the billing system of the telephone network). They do not need to invest in the implementation of billing.

The customer may also have a direct impact on the resulting bill, for example, due to delays in the network or other undesirable factors, resulting in poor quality of service being received by the customer.

The system also allows parallel payment methods to be used, e.g. electronic money may be an alternative implementation, or parallel payment methods in the system according to the invention. In addition, the system may monitor the level of service used by the user. Since the monitoring is performed in the client terminal, which also generates the charging record, the process of generating the charging record can react quickly to changes in the service level. Furthermore, the system is easy to adjust.

The solution is also applicable to mobile or cellular networks, so the use of services is not limited by geographical areas.

The solution according to the invention can be used for very different communication solutions, since it is independent of the data transfer protocol and method.

Drawings

The invention and its preferred embodiments are described in detail below with reference to examples 2-10 of the accompanying drawings:

figure 1 illustrates a known charging method used in a telephone network;

FIG. 2 illustrates a network environment in which the present invention may be applied;

fig. 3a illustrates the message passing between the different components of the system before the actual charging is initiated;

FIG. 3b illustrates a scenario corresponding to FIG. 3a, wherein the network uses a gateway between the billing server and the service providing server;

FIG. 4 illustrates a contract window displayed on a client terminal;

FIG. 5a illustrates an example of messaging between a client terminal and a billing server during a billing session;

fig. 5b illustrates a case where a deviation occurs between clocks of the billing server and the client terminal;

FIG. 6 illustrates the content and structure of a billing record;

FIG. 7a illustrates in functional block diagram form the architecture of a client terminal;

FIG. 7b details the structure of the CDR generator shown in FIG. 7 a;

FIG. 8 illustrates, in functional block diagram form, the structure of a billing Server;

FIG. 9a illustrates a scenario where a client uses a service of a server that does not belong to an area managed by the client's own billing server;

FIG. 9b illustrates messaging between the bill processing servers in the scenario shown in FIG. 9 a; and

fig. 10 illustrates an example of message delivery when the client terminal is located in a cable television network.

Detailed Description

The invention is described in detail below with reference to the example of fig. 2, fig. 2 illustrating a system according to the invention in a general operating environment.

The system includes a Client Terminal (CT) located at a client front end. These client terminals may be, for example, personal computers, mobile stations or separate client terminals connected to conventional terminal equipment. The terminal device may also be integrated into a modem, for example.

Furthermore, the system comprises at least one billing server WD, which collects and verifies billing records generated by the client terminals. The billing server may be located, for example, at the edge of the internet, connected to a server of an internet service provider ISP. The location of the billing server has no logical significance, but in practice, the choice of the location is influenced by the following factors. First, the billing server is preferably located in connection with or close to the public telephone network so that it can easily access existing billing systems of the telephone network. From an efficiency point of view, the connection between the client terminal and the billing server must be as fast as possible, with a delay that is easy to control (which is not the case at present if the billing server is located deep in the internet, for example). Since the purpose of the system is to also provide local services (in geographically limited areas) enabling billing for customer usage services, e.g. once a month, it is not advisable to locate the billing server remotely from the customer.

The billing server comprises a memory MS, for example a cassette, for storing all billing records that the billing server has accepted. The collected billing records are periodically transmitted to a billing system BS, which is an existing billing system in the public service telephone network PSTN or a system similar to the existing billing system located in the broadband network. The billing records are temporarily stored in the mass storage device MS1 before being transferred to the billing system.

Furthermore, the system comprises service providers, which provide services for which the customer is charged using the system according to the invention. For simplicity, fig. 2 includes only one service provider (SP 1). The service provider may provide video on demand services, for example, over the internet.

The Client Terminal (CT) may be connected to the network in different ways as shown in fig. 2. For example, an ISDN connection is one possible option. The ISDN connection can be implemented, for example, by means of a normal router (R), in which case the TCP/IP protocol is used over the ISDN connection, or by means of an ISDN card and an ISDN basic group access (BRI). The client terminal may also be connected to the network switch via a modem and an analogue subscriber line. Furthermore, current Asynchronous Digital Subscriber Line (ADSL) and high bit rate digital subscriber line (HDSL) technologies offer new possibilities for fast data and video transmission over telephone network twisted pair to subscriber terminals. Later, the system can be used for ATM connections, for example. The client terminal may also be located in a local network of, for example, a company or other organization, or it may be a cable television network terminal. The internet service provider may also be connected to the network switch, for example, by ISDN primary group access (PRI).

The operation of the system according to the invention is described in detail below. This example assumes that the billing service provider is an independent organization that only utilizes the controlled billing server WD for billing of services. Thus, the billing service provider has its own billing system.

Initially, the billing service provider makes a long-term contract with each service provider. In this contract, the billing service provider should allow monitoring of the service usage and make a charge for the usage. In return for this, the billing service provider may receive some portion of the service's profit, or a flat fee. After the contract is made, each service offered by the service provider gets a unique identifier, which is the same in the billing server (WD) and the server (SP1) of the service provider. In addition, each identifier has given billing parameters, which are utilized by the billing server. Thus, in the primary embodiment of the present invention, the billing server has a database containing billing parameters for each service identifier for each service provider. As will be mentioned later, this implementation may become such as to transmit these parameters from the service provider's server to the billing server at the start of each session.

Thereafter, the billing service provider makes a long-term contract with the customer (those who use the services provided by the service provider). Each client gets a unique client identifier, which is stored in the billing server and possibly also in the service provider's server. In addition, each client obtains a pair of keys, including a public key and a secret key. This pair of keys is used to sign and sign verify the accounting record. The client's public key is stored in the billing server and the secret key is stored in the terminal device. In the master embodiment, only the client knows the secret key. An information file (profile) may also be defined for the client.

After these long-term contracts are established, the use of the service can begin.

After the client selects the service, but before the billing is started, a (short-term) online contract needs to be made between the client and the system. The contract covers only the services that the customer has just selected, for example watching a movie, or making a purchase. The following explanation refers to fig. 3a, which illustrates the generation of an online contract. In this way, the databases connected to the billing server are the business, billing and tenant databases.

The client terminal CT comprises a service browser (which may be e.g. a Web browser) through which the client finds the appropriate service from the internet. After finding the appropriate service, in this case a video on demand service of the service provider SP1, the customer selects the service (e.g. a movie) by e.g. clicking on the option. The service selection phase is indicated by arrow a. At this time, the client terminal communicates with the server of the service provider.

If the customer has made a selection, the service provider's server sends (arrow B) to the billing server WD a service identification "Sid" representing the movie, and a user identification "Cid" of the customer. Cid may be derived, for example, from the client's browser from the source address of the received message (e.g., the socket address of the TCP connection). Thus, the browser always provides at least the customer identification and address to the billing service provider, but preferably also to the service provider. The tenant identifier may also be retrieved, for example, from a database based on a password given by the tenant. In this way, several different clients may use traffic from the same address. A separate server may also be provided in the network that hides the client identity from the service provider but provides this information to the billing service provider. However, such solutions are complex.

Thereafter, the billing server WD starts a process to handle the use of the service. First, the billing server retrieves the parameters corresponding to the service from the service database and sends (arrow C) a specific type of charging record (CDR) to the client terminal. The billing record contains billing parameters that need to be used during the session, as well as the contract number. After receiving the initial billing record, the client terminal program opens a window, hereinafter referred to as a contract window, on the client terminal. Fig. 4 illustrates an example of a contract window using fictitious server names. The window displays data for different parties and the billing service based on information received from the service. In addition, the window displays a contract number that identifies the particular service session. This contract differs from the long-term contract described above in that the contract is short-term; it only relates to the current traffic session. Thus, the contract only covers, for example, watching a selected movie. The customer clicks the accept button to accept the service and charge for the service. The customer can click a cancel button to cancel the service. The customer may also set the terminal to automatically accept the service, for example in case the total price or the price per time unit is less than a predetermined value.

After the client accepts, the client terminal returns the billing record it received to the billing server. However, the accounting record that needs to be returned includes a digital signature (fig. 3a, arrow D). Digital signature refers to a known cryptographic algorithm based on a key pair. Encryption is performed using a secret key, while anyone can decrypt the message using a public key. In this way the confidentiality of the message is lost, but it can be ensured that the message comes from the correct origin. The sender cannot deny him/her after the fact that he/she sent the message. If a digital signature is used, the entire message is typically not encrypted, but only a digest from the message. The digest is a checksum. From an encryption point of view, such digests are very strong and no outsiders can generate messages with the same digest. The digest and the time stamp are encrypted by the sender's secret key, which constitutes a digital signature. There are several different ways of implementing such signatures, but since the present invention does not relate to the signing of messages, the implementation of signatures is not described in detail here. Readers interested in this aspect may find more detailed information in the various books describing the field. (see, e.g., Schneier, applied Cryptographic, ISBN 0-471-

Thereafter, the billing server WD verifies the signature by known methods to authenticate the CDR. To do so, the billing server retrieves the client's public key from its tenant database (arrow E). The billing server stores the accepted billing record in its billing database (arrow F) and holds it for a period of time in case the client later withdraws the service. Thereafter, the billing server asks the service provider to start sending information to the client (arrow G).

The above procedure may be varied, for example so that the server SP1 sends the service identifier and other information that may be required directly to the client terminal after the client has selected the service, which in turn sends the service identifier to the billing server. In order to prevent the client from changing the service identifier, the server must either add a digital signature to the message, which is recognized by the billing server, or the billing server must verify the service identifier separately by the server SP1 after receiving it from the client terminal. Another variation is to let the server SP1 generate an initial charging record containing billing parameters that need to be used during the service session. In this case, the billing server merely verifies the message and sends it to the client terminal, or the billing server may add a contract number to the message.

A separate gateway computer may also be used between the billing server and the service provider's server in the network. In this case the gateway computer has a set of available services and the server SP contains only the actual service information (e.g. video data). Figure 3b illustrates the generation of an online contract when such a scheme is employed. In this case the operation of the gateway computer GW process is the same as the server in the scenario shown in fig. 3 a. When the gateway computer receives a request to send information from the billing server (arrow G), it sends a start request to the server (arrow H), the request containing the client terminal address and the service identifier. In such an embodiment, an additional check may be made so that the gateway computer alone checks via the server whether the requested service can be delivered to the client. There may be several reasons for this additional check, which is indicated by the dotted line in fig. 3b, which may be, for example, checking the server load. The billing server and gateway computer need not be physically separate; they may be integrated in one computer.

The operation of the method after an online contract is signed by one of the above-described implementation methods is described below.

After starting the service (e.g. starting playing a movie), the client terminal sends, for example, a billing record periodically, which has a digital signature and contains information of the amount to be billed. Therefore, each CDR that needs to be transmitted represents charging for a specific time period, and the total charging can be obtained by accumulating the charging amounts of all charging records having the same contract number. The time between two consecutive CDRs (and thus the charging of one CDR) may depend on the service provider.

The billing server verifies the source of each billing record using the client's public key and stores the accepted billing records in a billing database.

The billing records are periodically transmitted from the billing database to the billing system BS (fig. 2), which uses them to generate bills by known methods. The bill is sent to the customer. A bill contains a list and a charge for all services used by the client during a charging period, e.g. one month. The bill may be delivered as a printed copy by mail or in electronic form to the customer's terminal. Because the operation of bill handling systems is well known, it is not described in detail herein.

There may be, for example, the following 9 different types (0-8) of charging records (charging messages) in the system:

0. contract: this is the initial billing record (arrow C, fig. 3) which the billing server sends (unsigned) to the client and if the client accepts the contract, the client terminal returns the signed billing record to the billing system.

1. And (4) payment: such charging records are sent together with the signature from the client terminal during the service session to the billing server, which verifies it.

2. And finally: this type of CDR otherwise corresponds to type 1, but it declares in the form of additional information that it is the last CDR to be transmitted by the client terminal during the current traffic session. Such records are for example sent when a customer interrupts the service. It can also be used for one-time charging.

3. Pulse (pulse): such CDRs are sent from the billing server to the client terminal. The purpose is to tell the client terminal that it should send a new CDR if the service needs to continue. If the client terminal does not send a valid CDR within the specified period, the billing server sends an interrupt message to the service provider.

4. Missing sequence numbers: such CDRs are sent from the billing server to the client terminal (during successive billing contracts) informing that a CDR with a particular serial number has not arrived at the billing server or that the CDR is illegal. In this case, the client terminal may transmit the CDR again to correct the situation. However, neither party necessarily has such a function. If the client terminal does not respond to such a CDR, the best option is that the billing system has no authority to charge for the portion of the lost CDR.

5. The modified contract is: such a CDR is sent from the billing server to the client terminal, which otherwise corresponds to a type 0 charging record, but which has no new contract number. Its contract number is the same as the short-term contract number being used at that time. The charging record is sent during the service session to inform that the billing parameters have changed. If the price drops, the client terminal may for example automatically accept a new contract; the opposite case requires customer specified acceptance.

6. And (3) stopping: such a CDR may be sent in either direction to indicate that the contract is terminated. The sender signs the CDR.

7. Digital cash: the bill processing system may also be used in the following manner: the CDR (type 1 or 2) connected to a specific payment contains the payment in digital cash. However, the billing server does not transmit the digital cash to the billing system. The billing server transmits it directly to a server, e.g. a bank (always in case it collects a relatively small specific amount of digital cash), or to a network server (server BS' in fig. 2) maintained by some other organization, which directly charges the account of the client. Digital cash may be used for general electronic transactions in addition to the centralized bill handling system BS or as an alternative implementation to the centralized bill handling system.

8. And (4) charging synchronization: such CDRs are sent from the billing server to the client terminal (during successive billing contracts) informing the payment CDR that it is sent too frequently. In this case, the client terminal may skip the transmission of the payment CDR.

Fig. 5a illustrates an example of messaging between a client terminal and a billing server. The type of each message is given on the arrow representing the message. Messages with a digital signature are shown in the form of continuous lines, and messages without a digital signature (there is only one such message, which may also be signed) are shown in the form of dotted lines. The figure illustrates a situation where the billing server notifies a loss of a particular billing record once during a service.

The time (T) between two consecutive type 1 CDRs may vary depending on the number of processes simultaneously executing on the client terminal. If the load of the client terminal increases a lot and the generation of the CDR lags behind the nominal value, the charging included in the CDR becomes correspondingly large.

In practice, continuous charging involves synchronization problems caused by clock drift of the client terminal. Thus, it may happen that the client terminal does not transmit information at the correct rate. Such a problem may be addressed, for example, by having the billing server accept a certain percentage of "errors" (e.g., three percent) in the collected billing amount. This "error" can be increased by less precise calculations/rounding in the client terminal. If the "error" increases during the charging session such that it is greater than the billing server's acceptable range, the billing server sends a type 4 charging record with a sequence number that is the sequence number of the most recent charging record plus 1. Thereafter, the client terminal may return the billing record in a number of ways. The client terminal may for example be programmed to automatically accept all such billing records of a quantity smaller than a certain predetermined limit.

Fig. 5b illustrates the above situation with reference WDTF indicating consecutive time frames of the billing server and given reference CTTF at the client terminal time frame. The client terminal transmits a payment CDR (type 1) at the beginning of each time frame. If a time frame is not paid in the billing server, the server sends a type 4 CDR. In this case, the client terminal sends the payment CDR to automatically answer, followed by the transmission of the next payment CDR at the beginning of the next client terminal timeframe.

If the client terminal clock is too fast, the client terminal transmits both payment CDRs at some point in a billing server time frame. Such a situation can be corrected, for example, by: the billing server sends an additional message to the client terminal. The additional message is the logical inverse of the type 4 CDR. After receiving the additional CDR, the client terminal skips a payment CDR. For this purpose, a separate CDR type (type 8) is required.

All charging information required by the system is transmitted in a continuous field of protocol messages (charging records). Fig. 6 illustrates the domains used in the charging record:

type (2): the type of CDR is specified, i.e. which of the 8 charging records mentioned above.

Length: this field specifies the total length in bytes of the CDR, including the type and length fields.

Contract number: this field includes an integer given by the billing server. The integer pair is the same for all CDRs belonging to the same charging session.

Sequence number: an integer number indicating the order of generation of CDRs in the same charging session. The client terminal gives the number 0 to the contract CDR (type 0) it returns. Thereafter, 1 is added to each CDR number. This field is not defined in CDR types 3, 5, 6 and 7, and the sequence number of the missing CDR is indicated in type 4.

Service identification: the content of the domain indicates the services the user is charged for. The parameter of the domain contains its value as a result of the contract between the billing service provider and the (multimedia) service provider.

And (4) service type: the parameters of the domain divide the traffic into different classes for statistical purposes. Such as Web pages, video-on-demand, file transfers, etc.

Start time: the parameters of this field show the current time of CDR types 0 and 5 and 3, 4 and 6, and the start time of the charging period for types 1 and 2.

End time: the parameters of this domain define the end of the charging session for type 1 and 2 CDRs. For CDRs of types 0 and 5, the start and end time difference is the maximum charging period that is acceptable. This parameter is not defined in other types of CDRs.

Identifier: the parameters for the domain specify the client, billing server, and server identifier. These identifiers may be integers or network addresses, but they must be unique in the billing system.

The payment method comprises the following steps: types 0, 5, 1 and 2 define the parameters of the domain. The payment methods may be classified, for example, as follows: free, one-time charging (one CDR), periodic or external trigger, i.e. another process of the client terminal may trigger it. For example, the video player of the client terminal may trigger generation of a CDR once a minute if an acceptable video signal is received within the last minute.

Amount of money: this field indicates the customer's debt (the entire session or the time period between two CDRs).

Traffic data: the field contains information sent from an application external to the client terminal and further to the network.

Signature: this field contains the digital signature of the customer, which is used for the authentication of the CDR.

In appendix 1 of the present application, the CDR structure is described in detail using abstract grammar notation 1(asn.1), asn.1 being a generic description language for describing data structures in the field of telecommunications. An abstract syntax description language and a corresponding transmission syntax, which is a set of instructions to represent the data structure described by the description language as a bitstream, are defined in the ISO 8824 standard.

The accounting record may be sent, for example, in a data field of an IP packet, which may contain one or more accounting records.

Fig. 7a illustrates in functional block diagram form the operation of a Client Terminal (CT). In the present invention, the core of the device is the CDR Generator (CG), which generates the charging record. Connected to the CDR generator is a Security Library (SL). Its memory contains the client's secret encryption key, which handles the signature of the accounting record. The CDR generator generates CDRs and sends them to the secure vault, which signs them with the customer's secret encryption key. The secure vault returns the signed CDR to the CDR generator, which sends it to the billing meter (WD).

The secure vault handles encryption, signing and signature verification if the application and environment require that encrypted messages must be communicated between the client terminal and the billing server.

The security library may be implemented on a hardware or software basis. However, the hardware-based approach is faster. The secure vault, or a part thereof, may for example be implemented using a smart card containing for example a secret encryption key of the customer.

Further, the client terminal contains an element that accepts the service. These elements may include, for example, a service player VP, which may be a video player, which displays a video signal received from the network and may also instruct the CDR generator to generate a billing record. The service browser SB, the service player VP and the CDR generator are connected to the network via the communication library CL of the terminal. The CL creates a protocol stack, according to which the client terminal operates. The protocol stack may be, for example, a TCP/IP stack, such as Microsoft's Winsock.

The client terminal may also contain a bill counter BC which the client can use to check the accuracy of the bill sent by the service provider. Furthermore, the client terminal may have different components to monitor the quality of service (Qos) of the received information. For example, a video player may command a source to stop transmitting information when the quality of service drops below a certain value.

Fig. 7b illustrates a functional block diagram of the CDR generator in more detail. Contract logic unit CLU1 handles the generation of billing records based on the information stored in configuration database CDB. It contains logic that passes the accepted contract information to the graphical user interface GUI and generates a charging record of the type described above. The logic includes a timing component that defines a time between two consecutive CDRs. The contract logic unit CLU1 is connected to the communication library via an external control interface ECI and to the service player via an internal control interface ICI. The external control interface is responsible for converting the internal and external CDR formats. The internal control interface handles the message transfer between the service player and the contract logic unit, and performs the necessary conversion between the message format used by the service player and the message format inside the device. The connection between the internal control interface and the service player (interface a30 may be implemented, for example, by means of a communication library (TCP socket). the configuration database CDB is used to store user settings (user selections) which may be used to store information for different services (e.g. movies) and sent to the client based on accepted service identifiers.

If the service player is designed for video-on-demand, for example, it can be implemented using a personal computer and a program designed for video-on-demand services. One such program is StreamWorks, available from Xing Technology, usa.

The administration unit and the contractual logic unit are connected to the secure library through an a1 interface. The secure vault and a1 interface may be implemented, for example, using a SETCOS 3.1 smart card from Setec Oy, or using some comparable product based on the international standard for smart cards.

The data transfer method used in the implementation of the method varies with the type of network and the method used to connect the client terminal to the network. If the client terminal is connected to the network, for example, through a router (IP channel), the charging record may be sent in a TCP frame. If the client has e.g. an ISDN connection (2B + D), the CDR may be sent in ISDN signaling packets (user-to-user messages) of the D channel, or a TCP connection may be implemented on one B channel. The charging data may also be sent, for example, in TCAP messages of the SS7 network. The only part of the data transfer that is important is that there is a required connection between the client terminal, the billing server and the server, which makes it possible to transfer the above-mentioned messages.

The method of delivering information from a service provider to a customer is not defined above as it has no direct relation to the present invention. Information may be transmitted in packets (as is currently the internet), or a dedicated connection (fixed or virtual) may be used for transmission. Some services-such as video on demand-may require a dedicated connection between the client and the server. The network operator may charge for these connections individually, but if the specific charging for using these connections needs to be included in the bill of the system according to the invention, the CDRs generated by the network switch have to be collected. In this case, it is advantageous for these CDRs to be included in the contract number, since the price of such a connection can be associated with the traffic that caused the connection to be formed. It is therefore advantageous for the calling party to send the compact number to the exchange. This may be done by means of control messages related to the generation and interruption of the connection through which the traffic is carried out. Time tags may also be used in the CDRs to associate the connection and service usage together.

Fig. 8 illustrates the structure of the billing server WD in a general block diagram. At the heart of the device is a contractual logic unit CLU2, which has access to a service database SED, a tenant database SUD and a billing database BD. The service database contains information of different service providers, as well as charging parameters for service usage. The billing server may also change the billing parameters independently, for example, based on the time of day. The tenant database contains customer data (including the public key of each customer) for the operator managing the billing server. The billing record received from the client terminal is stored in a billing database. An encryption Component (CM) is associated with the contractual logic unit. The CM handles the verification of the accounting record signature. This component corresponds to the SL component of the client terminal. The contract logic unit receives the billing record signed by the client terminal from the client terminal, and sends the billing record to the encryption component for verification. And the contract logic unit stores the accepted charging records in a bill processing database. The contract logic unit is connected to the network via a communication library (CL') which generates a protocol stack defining the implementation of the connection.

In practice, the contractual logic unit described above may be implemented by a tool based on the international System Description Language (SDL) standard, for example, the SDT tool of Telelogic AB.

The database of the billing server may be in the above-mentioned memory MS (fig. 2) and may be located in the billing server. In addition, the billing record may be stored in a separate mass storage MS1 (fig. 2), with MS1 located between the billing server and the billing system of the network, so that the billing system may easily process the information stored in MS 1. With such separate databases, service providers can use the databases to make different types of queries, thereby improving their services. The service provider, or the client, may ask for the billing of a particular service, for example, during a billing period (e.g., via email).

The tenant and the service database may be located at both the billing server and the service provider's server (the latter using them, for example, for data authentication). These databases may be maintained by different organizations, not necessarily the same organization. For example, free services need not be stored in the billing server database. Furthermore, the tenant and business records in the database need not be the same. Only those tenants and service identifiers that the service-providing server sends to the billing server must be identical.

The billing server may comprise a plurality of parallel server units and may use known load distribution principles for them, e.g. equip them with a common load sharing unit which distributes the service requests among the parallel units in a specific way.

Because a billing server handles a specific set of clients located in a restricted geographic area, the services provided by the present invention are local in this regard. Fig. 9a illustrates the areas SA and SA' managed by two different billing servers WD1 and WD 2. One client of a particular billing server may naturally use the services of a server that is located in an area managed by a different billing service provider (and thus a different billing server), for example in another city or country. Fig. 9a illustrates this situation, where client C1, located in the area managed by billing server WD1, contacts server S3, and server S3 enters into an agreement with the billing service provider managing billing server WD 2. Fig. 9b illustrates message passing.

The billing server WD2 receives the customer identifier (Cid) (or address) and the service identifier Sid from the server S3, realizing that the customer is not his own customer. In this case, the billing service provider must sign a contract between both parties so that the billing server WD2 can send the initial CDR (contract CDR) to the billing server WD1 after receiving the customer and service identifier from server S3. The latter (i.e., WD1) converts the billing server specific information (billing server identifier and contract number) into corresponding information of its own, after which the initial CDR is sent to the client. A "null" CDR is stored in the billing server WD1, associating the initial CDR received from the billing server WD2 with the contract CDR sent to the customer, which is the same as the signed contract CDR received from the billing server WD2, but with the service identifier replaced by the contract number with which the billing server WD1 identifies the service. In this way, the billing server WD1 knows that the service is from a certain service provider that has contracted with another billing service provider.

Thereafter, the billing server WD1 may collect the CDRs generated using the service. The situation is similar to the situation where the client makes an international call.

The locally collected CDRs may be processed in a local billing system or they may be sent to a billing service provider with a billing server WD 2. In a telephone network, CDR processing and billing are typically performed in the local system. The bill handling part belonging to another operator will be returned to them later.

The above example shows commissioning of an online contract to a local billing server and using the same management method as the public telephone network, the method according to the invention can be extended globally.

The same roaming characteristics as in a mobile communication network can be achieved by adding home and visited registers in the system similar to those in a mobile communication network. In this case, it must be ensured that the client's public key is securely transmitted to the bill processing server in proximity to the tenant so that the bill processing server can verify the billing record. (if the transfer cannot be made securely, the third party may modify the key during the transfer, in such a way that the original tenant is lost.) the tenant's public key may be transferred to, for example, a database (VLR, visitor location register) in proximity to the billing server, which has access to the database. The billing server closest to the roaming subscriber may perform billing using the identifier of the subscriber's own billing server. After the service session is over, the collected CDRs are sent to the tenant's own billing server.

The client terminal may be, for example, a conventional mobile station into which the features required by the invention have been incorporated, and the invention may be used in a mobile telephone network or a mobile communications network.

If the client terminal is located in a cable television network, a service such as playing video on demand may be implemented as follows. Since the cable network is a broadcast network in which all clients receive the same signal, the server encrypts the video signal it transmits with a key that changes frequently, for example every 5-10 minutes. Each time the server changes the key, it informs the billing server of the key, and the billing server gives the new key to the client terminal after receiving the corresponding payment from the client terminal.

Fig. 10 illustrates the payment of a charge in case the client terminal is a terminal of a cable television network. After the contract is made, the billing server gives the first key it received from the server providing the service to the client terminal. The bill processing server periodically sends type 3 charging records (pulses) to the client terminal; in this way it requires a new payment. The billing server sends a new key in response to the payment, the key coming from the server providing the service. This key may be sent, for example, in a separately defined type (type 9) CDR, where it may be encrypted with the user's public key and then placed into the signature domain. Encryption may be performed if there is a risk of an outsider duplicating the key. The key is sent only to those client terminals from which the payment CDR has been received. The service provider does not need to send one key at a time to the bill processing server; all keys may be sent together. Furthermore, there is no need to sign a separate contract with the customer using the type 0 CDR. Instead, the sending of the first key is proposed as an online contract on the system side, with the first payment CDR acting as a client side acceptance of the contract. Thereafter, a contract number may be given to the service session.

Cable applications may also be implemented without type 3 billing records. In this case, the key is sent to each client terminal in response to the terminal sending the payment CDR.

Although the invention has been described above with reference to the examples shown in the drawings, it is obvious that the invention is not limited to these examples, which can be varied in several ways within the scope set by the appended patent claims. Some possible variations are briefly described below.

For example, the client terminal may not send the actual charging record to the billing server, but rather some other message that the billing server may use as a basis for generating the charging record. For example, the client terminal sends a so-called incentive message as long as the service is still continuing, after which the billing server generates a billing record in which the time between the last incentive message and the moment of acceptance of the contract is taken as the duration of the service. The billing server may also generate a charging record after the client terminal has informed that the selected service was accepted in a certain manner.

In the above system, the service provided by the service provider includes transmitting information. In principle, the service may also include the delivery of physical goods to the customer (e.g. by a mail service). In this case, the billing system generates a billing record (because the client terminal cannot measure the quality of service).

If the connection between the client and the billing server is secure enough, the digital signature need not be included in the billing record. Furthermore, there is no need to send a separate online service acceptance message to the billing server, since the first payment CDR can act as an acceptance message for the online service on the client side. The only important factor is therefore that a certain message informs the billing server that the client has accepted the contract.

It is also possible that the on-line contract is first made between the billing server and the client before the service provider's server is contacted.

The service may also be implemented in the form of a service session, in which more than one server participates in addition to the client terminal. One server may transmit, for example, a video signal to the client terminal while another server simultaneously transmits additional information, such as text or graphics, associated with the video signal.

If the servers have different owners, the payment may be divided among the owners in several ways. For example, the billing system may calculate the share of these service providers as bills are generated on a monthly basis. Alternatively, the bill processing server distributes payments as follows: upon receiving the first payment CDR from the client terminal, the billing server generates, for example, two new CDRs, which it signs and stores in mass storage. One of these billing records contains payment for video services and the other is payment for data services. The sum of these payments is the amount in the billing record received from the client terminal. The method of dividing the amount between service providers is a parameter of the combined service stored in the service database. If multiple servers are participating in the same business session, the billing server may divide the amount of money accepted from the client into multiple billing records accordingly. In addition to being able to divide payments among service providers by generating new CDRs, the billing server can take its share directly. Thus, if there are N service providers at the same time, the billing server may divide each received payment CDR into N +1 parts for a new billing record, enabling each service provider and billing service provider to get their share.

- -CDR Structure

-＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

In the initial version, the encoding is byte-oriented, without flags and

ENUMERATED, if nothing is specified

Encoded as one octet, INTEREGER is encoded as

-an octet string of the MSB first format

- (length 2, 4 or 8, depending on the maximum length).

CDR_cdrType::＝ENUMERATED{

contact (0), -initial CDR, WD- > client

payment (1) — normal payment CDR

final (2) — As above, the client stops

pulse (3), -indicating a new payment

missing _ seq (4) — CDR with missing sequence number

mod _ contract (5), -contract, renegotiation

abort (6), -terminating the connection without adding money

E _ cash (7) -electronic cash carrier CDR, type B

}

Type 0..6 reloading in CDRtypeA, type 7 use

-CDRtypeB

CDR_network::＝ENUMERATED{

unknown (0)，

TCP/IP (1)，

ISDN (2)}

CDR_serviceTypeType::＝ENUMERATED{

unknown (0)，

…

}

CDR_timeType::＝

hundrethOfSec OCTET STRING(SIZE(1))，

seconds OCTET STRING(SIZE(1))，

minutes OCTET STRING(SIZE(1))，

hours OCTET STRING(SIZE(1))，

days OCTET STRING(SIZE(1))，

year_lo OCTET STRING(SIZE(1))，

year_hi OCTET STRING(SIZE(1))}

CDR_identifierType::＝SEQUENCE{

type ENUMERATED{system_assigned(0)，E164_addr(1)，...}

data OCTET STRING(SIZE(16))

}

CDR_paymentMethodType::＝ENUMERATED{

free (0) - -, not charging

one _ time (1), -agree that one payment is valid

period (2), -based on time

WD _ req (3), -payment triggered by WD message

ext _ trig (4) -triggering of payments by an external client application

}

CDR_currencyType::＝ENUMERATED{

majorType ENUMERATED{bill(0)，E_cash(1)}，

currency ENUMERATED {FiM(0)，USD(1)，...}

}

Encoding into one octet so that the main type occupies

Most significant bit, cash bits 0-6

CDR_moneyAmountType::＝SEQUENCE{

currency CDR_currencyType，

value INTEGER(0..MAX_WORD)

-if electronic cash is used, the value defines

-serial number of electronic cash carrier CDR

CDR_signatureType::＝SEQUENCE{

present ENUMERATED{absent(0)，present(1)}，

type ENUMERATED{RSA-with-MD5(0)，DES-with-MD5(1)}，

signature OCTET STRING SIZE(64)

CDRformatA::＝SEQUENCE{

type CDR_cdrType，

Iength INTEGER(0..MAX_S_WORD)，

contractNr INTEGER(0..MAX_D_WORD)，

sequenceNr INTEGER(0..MAX_WORD)，

serviceld INTEGER(0..MAX_D_WORD)，

serviceType CDR_serviceTypeType，

startTime CDR_timeType，

endTime CDR_timeType，

clientld CDR_identifierType，

watchdogld CDR_identifierType，

serverld CDR_identifferType，

payMethod CDR_paymentMethodType，

moneyAm CDR_moneyAmountType，

trafficData OCTET STRING(SIZE(8))

signature CDR_signatureType

}

CDRformatB::＝SEQUENCE{

type CDR_cdrType，

length INTEGER(0..MAX_S_WORD)，

contractNr INTEGER(0..MAX_WORD)，

sequenceNr INTEGER(0..MAX_WORD)，

e_cash OCTET_STRING(SIZE(0..200))

}

Claims (33)

1. A method of processing service usage, the method comprising:

-providing a key for a cryptographic service to a device;

-receiving in the device a message from the terminal informing of the acceptance of the selected service in respect of the defined terms; and

-sending a key for the selected service from the device to the terminal.

2. The method of claim 1, comprising transmitting a message suggesting a contract for a service to a terminal before transmitting the message notifying acceptance from the terminal.

3. The method of claim 2, wherein the contract-advised message is sent from a device.

4. The method of claim 2, wherein the contract-advised message is sent from a server.

5. A method as claimed in any preceding claim, comprising negotiating terms of the selected service between the device and the terminal.

6. The method of claim 5, wherein the message notifying acceptance is a message related to the negotiation.

7. A method as claimed in any preceding claim, comprising sending at least one charging message associated with a selected service from the device to a billing system in dependence on a message received from the terminal.

8. A method as claimed in any preceding claim, comprising generating at least one charging record associated with a selected service upon receipt of the message notifying acceptance.

9. The method of claim 8, wherein the charging message associated with the selected service comprises a charging record.

10. A method as claimed in any preceding claim, wherein the message notifying acceptance comprises a charging record.

11. An apparatus for processing service usage, the apparatus comprising:

-means for receiving a key for the cryptographic service;

-means for receiving a message from the terminal, said message informing of the acceptance of the selected service in relation to the defined terms; and

-means for sending a key for the selected service to the terminal.

12. The apparatus of claim 11, configured to negotiate terms of the selected service with the terminal.

13. An arrangement according to claim 11 or 12, comprising means for sending a contract-proposing message to the terminal.

14. An arrangement according to any of claims 11-13, comprising means for sending at least one charging message associated with the selected service to the billing system.

15. An arrangement according to any of claims 11-14, comprising means for generating at least one charging record associated with a selected service upon receiving said message informing of acceptance for the respective service.

16. The apparatus of any of claims 11-15, wherein the apparatus is configured to process charging records.

17. The apparatus according to any of claims 11-16, wherein the apparatus is a charging server.

18. A terminal using a service, comprising;

-means for selecting a service;

-means for sending a message to the device that the selected service is accepted in respect of the defined terms; and

-means for receiving a key for the selected service from the device.

19. The terminal of claim 18, configured to negotiate terms of a selected service with the device.

20. A terminal according to claim 18 or 19, comprising means for receiving a message suggesting a contract for a service.

21. System comprising at least one device according to any of claims 11-17 and at least one terminal according to any of claims 18-20.

22. A client terminal connected to a network, the terminal comprising:

means for selecting a service from a plurality of services provided by a plurality of servers;

charging record generating means for generating a charging record in response to the service provided, the charging record generating means being configured to cause the generated charging record to be transmitted to the server.

23. A terminal according to claim 22, wherein the Client Terminal (CT) comprises means (SL) for adding a digital signature to the generated charging record.

24. The terminal of claim 22 or 23, wherein the terminal is configured to open a contract window in response to a command from the server to which the generated billing record is to be sent, the window presenting information about the service and an acceptance button to accept a contract for the service.

25. The terminal of claim 24, wherein the client terminal is configured to send contract information and a signature to the server to which the generated billing record is to be sent in response to pressing the accept button.

26. A terminal according to any of claims 22-25, wherein the client terminal comprises a service player connected to the means for generating a charging record for stopping the generation of the charging record when the quality of the signal received by the service player decreases.

27. The terminal according to any of claims 22-26, wherein the charging record generating means is configured to cause the generated charging record to be transmitted to a predetermined server.

28. The terminal according to any of claims 22-27, wherein the server to which the generated charging record is to be sent comprises a charging server.

29. A computer program, comprising:

at least one computer-executable component that, at run-time:

allowing selection of a service from a plurality of services provided by a plurality of servers;

generating a billing record in response to the provided service; and

causing the generated billing record to be sent to the server.

30. The computer program of claim 29, wherein the at least one computer-executable component adds a digital signature to the generated billing record at runtime.

31. The computer program of claim 29 or 30, wherein the at least one computer-executable component opens a contract window at runtime that presents information about a service and an accept button to accept a contract for a service.

32. The computer program of claim 31, wherein the at least one computer-executable component, when executed, causes contract information and a signature to be sent to the server in response to pressing the accept button.

33. The computer program of any one of claims 29-32, wherein the at least one computer-executable component is, when executed, for ceasing generation of a billing record when a received signal quality degrades.