EP1013067A1

EP1013067A1 - Improvements in, or relating to, telecommunications systems

Info

Publication number: EP1013067A1
Application number: EP98934084A
Authority: EP
Inventors: Lars-Erik Wedin; Magnus Johansson; Göran LINDQVIST
Original assignee: Telia AB
Current assignee: Telia AB
Priority date: 1997-08-14
Filing date: 1998-07-13
Publication date: 2000-06-28
Also published as: SE512479C2; EE200000084A; WO1999009733A1; NO20000643D0; SE9702937L; SE9702937D0; NO20000643L

Abstract

A billing system creating the opportunity to generate new types of price lists for provision of telecommunication services, making it possible to develop entirely new services with entirely new service structures. The system comprises means for receiving an SDR (Service Detail Record), sending said SDR to a service pricing scheduler where a Service Usage Module comprised in the SDR is associated with a price list to which the customer has agreed. The price is sent back with a Service Pricing Module associated with said Service Usage Module.

Description

Improvements in, or Relating to. Telecommunications Systems

The present invention relates to billing systems for use with telecommunications systems, especially telecommunications systems adapted to provide infocom, telecommunications system incorporating such billing system, and methods of costing infocom usage in telecommunications systems and billing for such usage.

At the present time, telecommunications systems employ billing chains based on national number plans and conventional base telephony, where charges are determined by the geographical distance over which a call is transmitted and the time for which a call is connected. The ability to base telecommunications charges on usage of IN-based services is limited by the fact that substantial parts of the pπcmg information generated by these systems is stripped out. This occurs during the normalisation which takes place because the billing chain uses a call record with a fixed length and fixed structure Information that is service-related does not appear in the call record.

The fixed length format runs counter to the requirements for renewal and supplementation which is imposed, by modern information services, on the billing chain. At the present time, service based charging i? b?s°<1 or. "fixcε", or . ,c solution is provided.

Typically, existing billing systems are based on a collection system which gathers TT records from Ax stations and IN nodes with a periodicity of once per hour to once per day The TT records are normalised to a call record with a fixed length which is base-priced. After one day, the call records are delivered to the system wnich is to place them with the correct invoicing system This takes another day It is only after two days that the invoicing systems can start processing the information in the call records

In summao/ the deficiencies of current billing systems are limitation to conventional base telephony (time and distance);

limited national number plans;

loss of important information;

inability to charge for service functions; and

> - inability to provide pricing details in real time.

In modem IN based telecommunications systems, entry of customer data is performed by a large number of support systems which administer the different organisational units of the telecommunications system. This results in some overlap of information and introduces a very substantial risk of faults and inconsistencies. To enable a customer to use a telecommunication service, three types of customer data need to be entered:

a descπption of the customer's network, i.e. company exchanges, directly connected telephones, modems, and fax machines, that form part of the customer's network,

^* - number plans, short-cut numbers, functions and call answer messages selected by the customer; and

billing information which reflects the customer's organisational structure so that he can be invoiced as required.

Ideally, customer information should be fed in via a central system which 0 distributes information to the administrative systems and service producing elements used to produce the service It is important, however, that the customer himself should have the opportunity to interact with his own services, i e via the Internet Customer cata should, therefore, be handled by a central customer care system which j - provides a unified input of customer data to a single place in a telecommunication's production apparatus,

permits the fast introduction of new services;

permits the fast extension and modification of existing services;

- provides service surveillance; and

provides customer management facilities.

The billing system of the present invention creates the opportunity to generate new types of price list for the provision of telecommunications services This in turn makes it possible to develop entirely new services with entirely new service structures Thus, the price plans used today can be superseded by price lists in the flexible billing concept of the present invention

In the present invention the pricing of a service is divided into a number of stages, namely:

the service provides information, on what the customer has done, to a SDR (Service Detail Record),,

a billing system handler, or SDR subscription service, receives a SDR and sends it to a service pricing scheduler;

the service pricing scheduler picks out a Service Usage Module, described later in this specification, in the SDR and, depending on the customer ID specified in the respective module, associates the moαϋe with a price list to which the customer has agreed

the pπce list system packs up the Service Usage Module and analyses what is to be priced, 09733

- 4 - the price is calculated and entered in a Service Pricing Module;

the Service Pricing Module is coupled with the Service Usage Module and returned to the pricing scheduler;

the pricing scheduler associates all Service Usage Modules with their Service Pricing Modules and returns the priced SDR to the billing system handler; and

the billing system handler sends priced SDRs to a SDR archive, or store, for intermediate storage until a post-processing system, e.g. an invoicing system, collects it.

The pricing scheduler is service-unique. One pricing scheduler may price each individual SDR per se, whereas another may assemble a number of SDRs, for one session, before calculating the price. This entirely depends on the way in which the service produces SDRs and how the service is priced.

Some pricing schedulers may assemble, in themselves, a number of SDRs, before sending the information to the price list system.

A customer can be handled either as =an individual customer, o. as one belonging to a customer group. All customers belong to a marketing company. A service can be marketed by one, or more, marketing companies.

A defined basic price list forms the basis of all price lists in the service. It specifies no prices, but represents a skeleton on the basis of which all other price lists are based.

Each marketing company has its own price lists. These are of the following types:

base price list; customer group price list; and

customer-unique price list

The base price list contains the basic underlying price list for the service within a specific market. The base price list is independent of the customer and the time when the service is used. The base price list may be the price list to which the vast bulk of customers are connected. There is only one base price list.

The customer group price list is a type of price list containing a special pricing for a specific customer group. The number of customer group price lists depends on the customer groups defined. Customer grouping is a way of offering, the vast bulk of customers, customer-unique pricing without being overwhelmed by a mass of different price lists.

The customer-unique price list is a type of price list produced for a specific customer. This price list is thus the actual customer adaptation. It is available for important customers, or customers who, for some reason, cannot be linked to any customer group.

Some price lists are in actual fact a list of prices, whereas others are based on algorithms, or functions, from which actual prices are calculated Th simplest form of price list merely tabulates prices. ,

A complex pπce list system assembles all SDRs relating to one session before it calculates a mass of prices.

The customer is involved in all pricing cases. This does not mean that a user is always involved, since services may act autonomously.

The costs c* one session can be shared by different customers. The A- and B-sides have c ~^'erent access forms.

Consider see basic pricing cases: 9733

- 6 - "A" communicates with "B", e g. connection via the PSTN

"A" accesses a service and, via this service, communicates with "B", e g calls from GSM to VCC, which, in a queuing system, makes an onward connection to the PSTN

"A" accesses a service, e.g. listens to his mobile answering system via the

PSTN.

The service communicates with "B", e g. provides an output from a Multifax service

5 The service performs a function not involving any communication, e g holds uncollected faxes for an extended storage period

6 The service communicates with another service, e g. VCC uses the tele answering service.

The present invention can readily cope with all these pricing cases, and is sufficiently flexible to cope with many other pπcing cases as well

According to a first aspect of the present invention, there is provided a telecommunications billing system, for use with a telecommunications system compπsing:

an information services network containing a plurality of service producing elements, and

- a communication services network containing:

a plurality of service switching elements,

a signalling network, and a transport network,

said telecommunications system being adapted to provide infocom services to customers and said billing system being adapted to provide flexible pricing and billing for usage of infocom services, characterised in that said billing system includes handler means for receiving SDRs generated by said service producing elements and transmitting said SDRs to a service pricing scheduler means in that said SDRs include Service Usage Modules, in that said service pricing scheduler means is adapted to associate a Service Usage Module with a pπce list appropnate thereto, and in that pricing means are provided for calculating a price associated with a Service Usage Module and inserting said price in a Service

Pricing Module associated with said Service Usage Module.

After insertion of a pπce in a Service Pπcing Module, said pricing scheduler means may be adapted to return a priced SDR to said handler means

Said handler means may be adapted to transmit pπced SDRs to a SDR archive means adapted to store said priced SDRs until they are transmitted to a post-processing system

A service use session may generate one, or more SDRs

Service Pricing Modules may be added to SDRs, only after an SDR has been priced

Each SDR may be a collection of tagged data items describing a service use session

An SDR's size and content may vary in accordance with an infocom service to which it relates

Tagged data items in an SDR may be encoded using the BER for ASN 1

Related tagged data items in an SDR may be grouped into service 9/09733

- 8 - modules.

A particular set of related tagged data items in an SDR may be grouped into one of the following four types of service module:

a Service Header Module, which contains tagged data items associated with a SDR as a whole;

a Network Service Module, which contains tagged data items related to consumption of network capacity by a particular service use session;

a Service Usage Module, which contains tagged data items relating to service usage; and

a Service Pricing Module which contains tagged data items relating to pricing of an infocom service.

An SDR may contain:

- one, or more, Network Usage Modules; and

one, or more, Service Usage Modules.

An SDR may contain a session identifier and a sequence number to enable a post-processing system to recover a chronological order in which SDRs were produced during a service use case.

An SDR may contain at least the following tagged data items:

an identity of a customer;

an identity of a marketing company; - 9 - an identity of a service to which the SDR relates;

and an SDR may contain one, or more of the following tagged data items:

an access form;

a time;

- a date;

an identity of a user;

a connection identity;

an operator;

a service provider;

- a customer price; and

a market price.

Relationships between service modules within an SDR may be governed by data items referred to as NSM/SUM correlators and SUM/SPM correlators, and these data items may have unique values within an SDR.

Said billing system may include one, or more, price lists, and said pricing system may be adapted to implement price list definitions, identify price lists to which an SDR relates and thereby produce priced SDRs.

Said pricing scheduler means may include said pricing system and may be adapted to receive SDRs, analyse SDRs and identify price lists appropriate to an SDR 09733

- 10 -

Said pricing scheduler means may be service independent, and anything which is service, customer, or market unique, may be incorporated in price lists.

Each infocom service may have a unique pricing scheduler means associated therewith.

Said pricing scheduler means may be adapted to assemble a plurality of

SDRs before said SDRs are priced.

Said pricing scheduler means may be adapted to price individual SDRs.

Customers may be handled, for pricing purposes, as individual customers, or as members of a customer group.

All price lists may be based on a basic price list.

Price lists may be of one of the following types:

a base price list which is independent of customer and time of use of an infocom service;

a customer group price list, applicable *o a group of c ctcmsi s; ana'

- a customer unique price list applicable to a single customer.

Price lists may be either lists of prices, or algorithms/functions for calculating prices.

SDRs may be generated independently of any action performed by a customer.

Costs for a service use session may be shared between different customers. /09733

- 1 1 -

Said billing system may include fault handling means adapted to process faulty SDRs

Said billing system may be adapted to operate with infocom services having plural functions

Said information services network may be an IN having a data server

Means may be provided to label an SDR as erroneous, if a pπce list relating to an SDR cannot be identified

According to a second aspect of the present invention, there is provided, In a telecommunications system comprising an information services network containing a plurality of service producing elements, and a communication services network containing a plurality of service switching elements, a signalling network and a transport network, said telecommunications network being adapted to provide infocom services to customers, a method of pricing usage of infocom services in a flexible manner, characterised by the steps of

- each service producing element, (SPE), generating SDRs,

collecting said SDRs at a handling means said SDRs mcludmπ ? Service Usage Module,

associating each Service Usage Module with a pπce list, and

dete mιnιng a price to be associated with each Service Usage Module and adding said price to the SDR, containing said Service

Usage Module in the form of a Service Pricing Module

Priced SDRs may be returned to a handler means

Priced SDRs may be transmitted to a SDR archive means and stored therein until collecie oy a post processing system 9733

- 12 -

Said post processing system may be an invoicing system

A service use session may generate one. or more SDRs

Service Pricing Modules may be added to SDRs, only after an SDR has been priced.

Each SDR may be a collection of tagged data items describing a service use session.

An SDR's size and content may vary in accordance with an infocom service to which it relates.

Tagged data items in an SDR may be encoded according to the BER for ASN.1.

Related tagged data items in an SDR may be grouped into service modules.

- a Service Header Module, which contains tagged data items associated with SDR as a whole;

- a Service Usage Module, which contains tagged data items relating to service usage, and

a Service Pπcing Module which contains tagged data items relating to pπcing of infocom service /09733

An SDR may contain:

one, or more, Network Usage Modules; and

one, or more, Service Usage Modules.

An SDR may contain a session identifier and a sequence number to enable a post-processing systems to recover a chronological order in which SDRs were produced during a service usage case.

An SDR may contain at least the following tagged data items:

an identity of a customer;

an identity of a marketing company;

an identity of a service to which the SDR relates;;

and an SDR may contain one, or more, of the following tagged data items

an access form;

a time;

- a date;

an iσentity of a user;

a connection identity;

an operator,

a service provider; 09733

- 14 - a customer price; and

a market price.

An SDR may include data items referred to as NSM/SUM correlators and SUM/SPM correlators which govern relationships between service modules in the SDR, and the values of these data items may be unique within an SDR.

Said billing system may include one, or more, price lists, and said billing system may be adapted to implement price list definitions, identify price lists to which an SDR relates and thereby produce priced SDRs.

A pricing scheduler means may be adapted to receive SDRs, analyse SDRs and identify price lists appropriate to an SDR.

A plurality of SDRs may be assembled before pricing.

All price lists may be based on a basic price list.

Price lists may be one of the following types:

a base price list which is independent of customer and tim° of ' εe of_. service);

a customer group price list, applicable to a group of customers; and

a customer unique price list applicable to a single customer.

According to a third aspect of the present invention, there is provided a telecommunications system, characterised in that said telecommunications system includes a billing system, as described in any preceding paragraph, or in that said telecommunicatioπs system is adapted to price telecommunications sen/ice and network usage using a method as described in any preceding.

Said post-processing system may be an invoice system.

SDRs may be moved from service producing element, to pricing scheduler means, to an invoicing system.

SDRs may be used for any of the following functions:

billing, both inside and outside a telecommunication operator's own organisation;

consolidated billing;

- production of reports and statistics;

quality assurance; and

service management, including identification of fraud, churning, abnormal traffic loads, failure rates and technical malfunctions.

Post-processing systems, requiring access to information contained in SDRs, may subscribe to said handler means.

Said system may have a single invoice printing function.

Said pricing scheduler means may handle pricing of traffic rates and service events, and pricing related to periodical charges, subscription charges and discounts may be handled by post processing systems.

Each post-processing system subscribes to SDRs from one, or more infocom services, and/or to selected data items from within an SDR. /09733

- 16 -

Post-processing systems may collect SDRs, at predetermined intervals from a SDR archive, and/or post-processing systems may be alerted when SDRs are available for collection in a SDR archive

At least some infocom service producing elements may issue SDRs as a request for pricing information, which SDRs are passed to pricing scheduler means, priced and returned to said service producing elements.

SDRs without a subscribing post-processing entity may be discarded while SDRs having a subscribing post-processing entity may be retained for a peπod of time in a SDR archive.

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 illustrates, in schematic form, an overview of a flexible billing system according to the present invention.

Figure 2 illustrates, in schematic form, the architecture of a flexible billing system, according to the present invention.

Figure 3 illustrates, in schematic form, tpp development cf α -εrvice employing the flexible billing system of the present invention.

Figure 4 illustrates the relationship between price lists in the present invention.

Figure 5 illustrates the basic structure of tagged data items.

Figure 6 illustrates the service module structure of an SDR

Figure 7 illustrates the structure within tre service usage module of Figure 6 Figure 8 illustrates the structure within the service module of Figure 6.

Figure 9 illustrates the relationship between service modules in an SDR.

Figure 10 illustrates that a service use session may include events within a single service, or within several services co-operating in sequence, or parallel.

Figure 11 illustrates how the number of SDRs produced by a service use session depends on the type of service, or co-operating services.

Figure 12 illustrates how a service usage module may contain one, or several related service events.

Figure 13 illustrates why certain information must be communicated between SPEs.

Figure 14 illustrates, in schematic form, a service pricing system

Figure 15 illustrates in schematic form the way in which a subscription service offers SDR information as a common resource to the post- processing systems.

Figure 16 illustrates the billing chain within, and outside, a telecommunications operators organisation.

Figure 17 illustrate the way in which consolidated billing permits a full range of services to be billed together on a single bill.

Figure 18 illustrates the ways in which SDR information may be accessed in a variety of forms

Figure 19 illustrates the use of SDRs, and the information contained therein, for calculating the cost of service provision, signalling and communication.

A glossary of terms and a set of formal definitions is set out at the end of this specification to facilitate an understanding thereof.

Turning now to Figures 1 to 4, an overview of a billing system, in accordance with the present invention, is given.

The core functions of the flexible billing system of the present invention are:

collection of data;

debiting;

- invoice production;

payment;

payment verification; and

follow-up.

The billing chain of the present invention realises a process, comprising several stages. The present invention solves, inter alia, the problems associated with pricing and debiting. However, more is required of a billing system - SDRs must be collected, and invoices must be produced.

Thus, it is necessary to:

make sure that SDRs which can be priced, are collected, but no others;

prepare the correct price list on the basis of the information in the SDR 9733

- 19 - pπce the SDRs as per the price list,

make sure that the priced SDRs can be reached by MPS and

make sure that erroneous SDRs are fault-handled

The flexible billing system of the present invention incorporates a number of useful functions, e g pricing scheduler and SDR fault handler This is illustrated in Figure 1 Within the overall service production module, there is located a register of service usage, a module for compiling pricing information and a module for creating SDRs These units feed out data to the billing system, as shown in Figure 1 In addition, data may be fed out from the register of service usage to a module for defining price lists located in a service development element Data from the module which compiles pricing information is fed to a module which identifies price lists, again located in the service development element Data is also fed from the service development element to the billing system, as shown in Figure 1, which contains units for pπcing service usage, analysing pricing information and collecting SDRs

The service and pπcing scheduler are interlinked through the price list and SDRs The price list defines what is to be priced and what it costs The SDR refers to what can be priced in each individual case

Considering an individual pricing case, an SDR informs the pricing scheduler what can be priced for service usage The price list gives the pricing scheduler the data it needs about the service so that it can correctly price an SDR

The system architecture used to implement the billing system is shown in Figure 2 The IN-service is supplied to a client, possibly via a data server 1 The client is linked, directly or indirectly with the billing system which contains a pricing scheduler and pπce list systems as shown The billing system sends priced SDRs on to other sub-systems in the telecommunications system, such as the subsystems labelled MPS FAKT and CAMS via a data server 2 As shown in Figure 2 three fundamental process are implemented by the system, namely price list definition;

price list identification; and

production of priced SDRs.

SDRs are moved from within a service production sub-system, i.e. a service producing element of the network, through the pricing scheduler in the billing system, to the invoicing train. The SDR has an information field which satisfies needs throughout the chain.

Operation of the billing system is not affected by the way in which SDRs enter the database. Neither is it affected by where and how SDRs are created. The only requirement is that SDRs end up in the database. The client collects all

SDRs to be priced. This is important, since there are SDRs which do not contain pricing information. The responsibility for the billing system starts with the client. The SDR comprises the interface between service and pricing scheduler.

The pricing scheduler receives and analyses each individual SDR. The analysis results in a defined price list, if everything operates correctly.

The price list system reads the SDR and Dicks out the correct price, r^r prices. Some manipulation may be needed to come up with the correct price for a given customer.

When an SDR has been priced, it is sent to the MPS. It may be sent alone, or, together with other SDRs, in one file. The MPS only needs to collect the SDRs with FTP. It is necessary to store the SDRs until the MPS has collected them.

The process of developing a service, as related to the billing system of the present invention, is illustrated in Figure 3 There are essentially three stages to this process^'

- sen/ice development itself, 9733

- 21 - service production; and

customisation

In the initial step of service development, it is necessary to develop the service functions, define price lists for the service, define SDRs and generate SDRs. In the step of service production, product unique, and market unique, price lists must be produced. In the final stage of this process, customer unique price lists must be produced.

A service will have a number of functions, which can be individually priced, using the billing system of the present invention. The precise charging regime is determined by the service. The billing system of the present invention does not impose any limitations on the charging possibilities.

The price list defines what can be priced in the service. If something is to be to be priced, an SDR must also be generated.

The SDR defines the basis for pricing. If an SDR is to be generated, the content must be defined.

In the stage of service production, the Dπce list for t rvodi'c .? c'efir.sd with regard for the marketing company which is to sell the service. Each rnarketing company can have its own pπcing and thus its own price list. However, it is only possible to price wπat is defined by the service.

In the stage of customisation, the price list for the individual customer is defined. Unique customer agreements may entail unique price lists. Individual customer-service provider contracts may mean that a customer has his own pricing

The pricing scheduler is a universal function within the billing system, i e it is completely traⁿsparent to the service Everything that is service-unique, customer-unique c market-unique must be included in the price list. 9733

- 22 -

New price lists can be entered during system operation. This covers both newly created services as well as supplemented existing services and modified price lists. The pricing scheduler must be able to find the correct price list despite changes during operation.

A price list should be changed at predetermined times. The old price list can be written over. A price list must have a validity schedule.

It is also possible to cancel price lists.

Forthe pricing scheduler to be able to price an SDR, it must be identified. It is, therefore, necessary to search in the database where SDRs are stored and to mark any unpriced SDRs, as unpriced.

In order to be able to price, the pricing scheduler must find the correct price list. An SDR contains information which identifies the correct price list. For example, an SDR may contain:

the identity of the customer - this must always be included;

the identity of the marketing company - this must always be included;

the identity of the service to which it relates - this must be available for service usage pricing;

access form - this must be available for access pricing;

- time - this must always be included;

date - this must always be included;

identity of the user; 33

- 23 - connection;

operator;

service provider;

customer price - this indicates that a customer-unique price list is available; and

market price - this indicates that a market-unique pπce list is available.

All optional terms need not be specified to identify a price list. The correct pπce list is identified through all specified requirements being fulfilled. Otherwise, no guarantee can be given that the correct price list will be identified.

A general pπce list, i e. one that is market-matched, or customised, is identified by the parameters

customer;

marketing company;

- service;

access form;

time, and

date

example

1 customer 123456-7 9733

- 24 -

2. marketing company: Telia Company

service: Faxbox

access form: Internet

5. time: 14:33:15

6. date: 30.11.96

These parameters will give a general price list for a Telia service known as

Faxbox.

Example:

1. customer: 123456-7

2. marketing company: Telia Company

3. service: Faxbox

access form: Internet

time: 14:33:15

date: 30.11.96

7. market price: YES

These parameters will yield a market-unique price list for Faxbox.

If the price list cannot be identified, the SDR is marked as being erroneous and the cause noted. 733

- 25 -

The pricing process is illustrated in Figure 4. The SDR contains tags for the number of services used during a session.

The price lists may largely consist of a conventional list with prices running up and down, or it may have functions for analysis and calculation to enable the correct price to be arrived at.

The price list system sets the price, and the pricing scheduler is thereby satisfied. In conjunction with pricing, the price list system marks the SDR as priced.

For reasons of settlement with the Net and other networks, this form of access has its own tag and price list.

Priced SDRs must be marked as already priced. It may happen that an SDR cannot be priced. The SDR must be appropriately marked as follows:

erroneous;

fault cause; and/or

- fault detector.

The SDR consists of a general part and a number of tags. The general part identifies the customer, and the tags report on services and access forms.

Example: 3

26 -

An SDR must have space for information needed for:

identifying unpriced SDRs,

identifying the correct price list;

pπce marking;

specifying the time of pricing;

marking priced SDRs (signing i e the price list which has set the price), and

marking erroneous SDRs

An SDR, as previously explained, contains a substantial amount of information, which is needed to identify the correct pπce list. SDRs are loaded with customer information and contain all the data needed.

As previously explained, the traditional telephony network can be regarded as being divided r.to an Information Services Network containing interacting Service Producing Elements and a Communication Services Network containing Service Switching Ξ'ements The latter consist of a signalling network and a transport network The signalling network carries commands to the Service Switching Eleme-ts for example, to establish a connection between two 33

- 27 - geographical locations in the transport network This network then conveys the information that is to be exchanged between these two locations such as voice, text, picture, or data

Services created by this combination of information and communication are called infocom services The Communication Services Network issues call detail records providing information about the geographical distance between the two locations being connected and for how long this connection has lasted This information is not sufficient for infocom service providers, hence, the Information Services Network issues service detail records (SDR) The purpose of the SDR is to provide the information necessary to properly bill the usage and production of infocom services The SDR may also provide information to support service management, quality assurance activities and production of statistics and reports about the service usage

A user, i e an individual, may take part in the generation of an SDR However, it is not necessarily essential for an individual to be directly involved in the generation of an SDR An SDR may be created as a consequence of

a user making a phone call to a colleague,

a facsimile message residing in a users fax box .being ^reta'ncd for a further, peπod of time, ,

- quality assurance activities prior to introducing a new infocom service or

a Service Producing Element reporting no call attempts have been made for the last 30 minutes

In the first two cases a user interacts directly and indirectly with an infocom service A service use session is produced and an SDR is issued to bill the user

In the latter two cases the SDR is produced for quality assurance and service management purposes and not for billing The present invention is primarily 733

- 28 - concemed with the generation of SDRs as a result of a user interacting with an infocom service where the main purpose is billing the user for usage of the infocom service

A Service Detail Record is a collection of tagged data items describing an infocom service use session The basic structure of a tagged data item is illustrated in Figure 5 The size and contents of the SDR may vary according to the infocom services used and the way in which it has been used it must be possible to append new data items to the SDR as, and when, new infocom services having different requirements emerge To accomplish this, the SDR data structure must be flexible and expandable, hence the concept of using tagged data items

As shown in Figure 5, tagged data items have three basic components a tag identifier, a length indicator and the actual data value The tag identifier descπDes how the associated data value is to be interpreted The length indicator gives tne length of the data value, in terms of a number of octets, without the length of the tag identifier and the length indicator itself For example, if the tag identifier says 'pπce to pay' the associated data value will be interpreted as a sum of money Because the data value may contain other tagged data items nested structures are created, somewhat like a set of Chinese boxes

Tagged data items are positioned in sequence, one after another, with no spaces inserted between them and no spaces reserved for unused fields A tagged data item is recognized by the tag identifier value associated with it and may appear in any output from a Service Producing Element, hence additional tagged data items may be appended to it, e g by the Service Pricing System

Tagged data items are encoded according to the Basic Encoding Rules

(BER; of the Absfact Syntax Notation Number One (ASN 1) as specified in the joint SO/CCITT set of international standards/recommendations An infocom ser ce provider may take responsibility for assigning tag identifiers to the various data items in the SDR 733

- 29 -

Related tagged data items are grouped into service modules There are four different types of service modules within the SDR The structure of a service module is illustrated in Figure 6

The Service Header Module contains data items associated with the SDR as a whole There is always one such module in the SDR

The Network Service Module contains data items associated with the service's consumption of network capacity There may be one, or several, network service modules in the SDR Within the module, information about several network hops may be recorded

The Service Usage Module contains data items associated with the usage of an infocom service The structure of a service usage module is shown in Figure 7 There may be one, or several, such modules in the SDR It contains data items that are present in all service usage modules and data items specific to a particular service

The Service Pπcing Module contains data items associated with the pricing of an infocom service There may be one, or several, such modules in the SDR

The structure of a service module is shown in mor^p n m\ ^> F-g rc 8 Each service module has its own set of module specific tags, i e tags unique wrthm the context of that service module The data items Service Module Identifier and Revision State are mandatory in all service modules When these data items are combined with the module specific tags, the data items within that service module become globally unique, i e unique even outside the context of that service module To make data items in a service usage module globally unique, a third data item, the Service Feature Code, is required

An ASN 1 -encoder/decoder may be implemented as a state machine executing the BER and having access to look-up tables containing tag identifier values for different service modules The decoding of an SDR begins with the state machine obtaining the Service Module Identifier and Revision State Having 733

- 30 - done this the proper look-up table for that service module may be loaded and its data values correctly interpreted. This logic applies for all other service modules in the SDR. In the case of the service usage module, the Service Feature Code must also be retπeved to determine which infocom service has produced the data items in the service usage module

The relationship between service modules is illustrated in Figure 9. The SDR contains, when output from a Service Producing Element, a service header module (SHM), one, or several, network service modules (NSM), and one, or several, service usage modules (SUM), When the Service Pricing System has produced the price information, the SDR also contains a service pricing module,

SPM, related to each service usage module, SUM.

A service pricing module is always related to a service usage module. One, or several SUM/SPM-pairs may be related to a network service module forming an NSM/SUM/SPM-triplet. Deciding the service module structure is part of designing an infocom service.

The relationship between the service modules within an SDR is governed by two optional data elements, the NSM/SUM-Correlator and the SUM/SPM- Correlator No correlators are needed if the SDR contains only one service module of each type If it contain several n^pfwork cory-ce modules, an NSiVϊ/SUfvi- Correlator must be shared between the network service module and the-one, or several, related service usage modules Network service module-wise, there is a one-to-one, or one-to-many, relationship between these types of modules

A service pnαπg module and a service usage module share a SUM/SPM- Correlator There is a one-to-one relationship between these types of modules. The series of values of the two correlator types must be unique within the SDR

The usage c^' an infocom service is called a service use session It begins at a given date arc time has a limited duration and eventually ends at another date, sometimes, aid time, always Dur.rg a service use session, one, or a number, of service events take place Seve'al infocom services may co-operate, either in sequence, or parallel, in time, to provide a more refined service Hence, a service use session may contain events from several infocom services, see Figure 10

Events within the same infocom service are grouped into a service module The chronological order in which the events take place are maintained in the SDR

A service use session may generate a single SDR - containing all service events within a single service, or within several cooperating services It may also result in several related SDR's, each containing events within a single service, or an SDR for each service event, see Figure 11 For example, the Virtual Call Centre service produces one SDR containing all events, one, or several, in a service use session, whilst the Broad Band service generates one SDR for each event taking place

Whether, or not, a service use session results in one, or several, SDR's is irrelevant to the Service Pπcing System which handles each SDR as an individual entity The SDR contain two optional data elements, a Session Identifier and a Sequence Number to enable a post-processing system to recover the chronological order in which several related SDR's were produced during a service use session Inside the SDR, events from an infocom service are grouped into a service usage module Such a module is specific to an infocom service and may contain a single service event, or a chronological sequence of related service events see Figure 12

The Service Pricing System appends the data items Basic Price and Individual Pπce to the service pricing module These data items may contain the pπce for an individual service event, or the total amount for all service events in the related service usage module

Service Producing Elements are part of the Information Services Network

Customer data, for an individual customer, may be allocated to his home location SPE Tne service logic of an infocom services may execute on a dedicated SPE or be cistriDuted amongst several cooperating SPE's

If more than one Service Producing Element is participating in a service 733

- 32 - use session and, if more than one SDR is being output, they must coordinate the values of the data items Session Identifier and Sequence Number present in the SDR header, see Figure 13, which illustrates the need for certain information to be communicated between SPEs

Infocom services may be offered by several marketing companies with differences in pricing, terms of payment, billing, etc Hence, it must be possible to pπce the provisioning and usage of infocom services according to price tables unique to each marketing company It must also be possible to give the service providers and users individual rates, either in terms of absolute rates, or a basic rate, with varying discounts and bonuses applied later on

The service pricing system is illustrated in Figure 14, which shows the interaction between the pricing scheduler, customer control data, service specific pricing logic and market/customer specific price tables in the production of pπced SDRs, indicated by SSDR in Figure 14, from unpriced SDRs

Some services require rate, or pπce, information on demand, more, or less, in real time, in different languages and in different currencies before, duπng and immediately after tne service has been used It must be possible for the service provider to change the rates and prices of an infocom service instantaneously This applies regardless of who is nrnvidmg tho ς_eP ^/._C *₀ vvhcm, the provider ay be a telecommunications network operator, or a customer , of the telecommunications network operator

The Service Pπcing System handles the pricing of traffic rates and service events Peπodical charges, such as subscription charges, various discounts and bonuses must be calculated by the post-processing systems

A Service P'oducing Element delivers SDRs to a Subscription Service with an intermediate storage capability, the SDR-Archive, see Figure 15 Due to the gross amount of ιr-ormatιon being produced the SDRs are only retaineα m this archive for a mitec period of time The post-processing systems may subscribe to SDRs from seve'al infocom services or selected data items within SDRs from - 33 - a particular infocom service, for example, only those data items associated with billing. SDRs having no subscribers are discarded immediately upon reception by the Subscription Service.

Those SDRs that do have subscribers are retained in the SDR-Archive for a specified period of time. The post-processing systems may ask the Subscription

Service for information to which they, (post-processing systems), subscribe, at recurrent time intervals, or may be alerted by the Subscription Service when they have information to collect. The SDRs are purged from the archive when all subscribers have collected the information to which they subscribe.

Some infocom services may issue an SDR as a request for price, or rate, information. Such an SDR is also sent to the Subscription Service and collected by the Service Pricing System. When the price, or rate, has been calculated and appended to the SDR it is returned to the Subscription Service and eventually fetched by the Service Producing Element that issued the request.

The information in the SDR-Archive is a common resource available to the post-processing systems. The information is provided through the Subscription Service and may be used for different purposes. Some examples are set out below.

a) Billing inside and outside a telecommunications operator's organizatipn

The information in the SDR may be utilized to produce accounting information and enable a service producing company to verify invoices from domestic, as well as foreign, network providers. This information may be distributed amongst the various infocom services to keep track on the amount of network capacity an infocom service has consumed. It may be broken down further to show the network capacity a single service use session has consumed.

When this is done it is possible to calculate the network cost and associate it to a specific network operator, an infocom service, or a service use session. Figure 16 illustrates the distribution of revenues, in a billing chain, both inside, and outside, a telecommunications organisation. 733

- 34 -

A service producing company may calculate the production cost to be printed on the invoice to marketing companies for providing them with infocom services

The production cost is the sum of the network cost and the service producing company's refinement cost and profit margin, which may vary from one marketing company to another. In the same way the service producing company may bill customers to the marketing companies simply by adding marketing expenses and profit margins to the service production cost. A customer may be either a user, or a provider, of infocom services. The service provider may be paid by cheque via the postal system, or by electronic money transfer.

b) Consolidated billing

Consolidated billing may reduce billing costs when multiple services are offered. It allows a full range of services to be billed together on a single bill. Bills cost money to produce in terms of hardware, software, paper and postage Each bill will, hopefully, result in a payment which needs processing and it may generate customer enquiries - yet more cost.

Opponents of consolidated billing argue that customers get a shock when they receive one large bill. But this mav not be so the-supcrmαr et industry as an analogy: Gone are the days when people shop at the grocers, the bakers and the butchers in turn, spending a small amount in each. It is now accepted that a single trip to the supermarket, enables individuals to get everything required for a week and results in a single large bill. This has not inhibited the dominance of supermarkets Customers are happy to pay the large supermarket bills for two key reasons.

- Convenience - a single place to shop, a single cheque to write, and

Cost - supermarkets are perceived to be less expensive than sma.'er specialised stores 9733

- 35 -

Figure 17 illustrates the operation of a consolidated billing system and, in particular, the way in which consolidated billing permits a full range of services to be billed on a single bill Infocom services may have their own dedicated billing systems subscribing to data elements containing information, such as price, currency and VAT, about that service. This speeds up the introduction of new services, or additions of new features, because only that particular service's billing system needs to be modified. The rest of the service production environment stays intact.

When the total amount for the stipulated period has been calculated on a per customer basis, account service information is transferred to the invoice pπntmg machine common to all services. This machine applies volume discounts and bonuses compπsmg the full range of services a customer subscribes to and prints a single bill/invoice.

c) Reports and statistics

The information present in the SDR is a valuable asset to a telecommunications operator. Figure 18 shows the way in which information contained in SDRs may be used for the production and delivery of management reports and statistics It may be used to gam knowledge of how the service production environment ι functioning, ho^' th° infocom r.crvicc-s are used, wii i revenues they generate and customer behaviour. It may, of course, . also be offered to customers in the form of reports.

The information in SDRs may be used to produce service specific revenue reports, sales reports, marketing reports and customer behaviour reports to the service provider, the marketing companies and their customers. The product manager can switch on his, or her, personal computer on arrival at the office in the morning and get fresn information about the revenues his, or her, product has generated up to the previous day This information may be analysed and trigger development of new services, service features, or refinement of existing services

Customers marketing companies and all others taking part in the service production, can order SDR-deπved information in a number of different ways and forms Ordeπng may be carried out by electronic mail, facsimile, phone, Internet, or snail mail, either as a one time delivery, or as a subscription The information content may be tailored in a variety of ways to suit a particular customer's needs, e g by type of information, the infocom service to which it relates, customer, company, and/or the time interval in which it was, or will be, produced

Delivery may be earned out by e-mail, facsimile, phone, Internet, electronic data interchange (EDI), or snail mail, containing CD-ROM, or paper The information delivered may be in a final state, or prepared for further refinement by the customer In the latter case, the information may be contained in a Microsoft

Word document, an Excel spread sheet, or Power Point pictures, that may be printed out on transparencies

α) Quality assurance

SDRs may be generated for quality assurance purposes For example, prior to marketing a new service feature it is important to verify that it has been correctly pπced and that the invoice looks all πght However, it is equally important not to put this invoice in an envelope and mail it

e) Service management

SDR's may be generated for service management purposes, for example, to obtain an early indication of suspected fraud attempts, churning, abnormal traffic loads, failure rates, or technical errors

To determine the cost for producing a service use session, information about consumed communications network capacity must be obtained This induces all network providers who have put their signalling and transport networks at the services disposal Figure 19 shows how an SDR may contain information from a variety of sources all of which is needed to calculate the cost of service provis.on signalling and communication 9733

- 37 -

In the example illustrated in Figure 19, a Swedish company, with sites in Europe, subscribes to a virtual private network service - VPN The sites share a common private numbering plan (PNP) and the service logic executes on a Service Producing Element in Sweden The signalling and exchange of information takes place within domestic and foreign network providers' networks via Signal Switching Elements (SSE)

When A calls B at the site in Spain, it is signalled to the SPE in Sweden The service finds out that A and B are connected to the same VPN and establishes a voice-channel between A and B in the Spanish operators network When A hangs up, an SDR is produced at the SPE in Sweden giving details of consumed signalling capacity between Spain and Sweden, via France and Germany, and the communication capacity used in the Spanish operators network

The invoices from the network providers may cover the total amount of network capacity consumed by various infocom services The SDR must provide sufficient information to enable the service provider to calculate the amount of capacity a specific infocom service has consumed

The structure of SDRs and data items included therein will now be described It will be noted that some data items are mandatory while others are optional SDRs, as has already been exDlained ar^p generated ^as 2 ccrccqLcr.cc of a user interacting with an infocom service The mam purpose of the SDR is to bill the user for the usage SDRs generated as a consequence of service management, quality assurance activities, or other activities are not descπbed herein

Data items in the Service Header Module are appended by the Service Production Elements All data items, mandatory, or optional, appear only once within the module The following data items belong to this module

Service Module Identifier - Identifies the service header module [MANDATORη Revision State - The version of the ASN 1 data type defining the service header module. A module in a given version must not be altered. [MANDATORY].

SDR Type - Identifies the type of SDR. The specific values are:

- Billing;

Quality Assurance;

Service Management;

Statistics;

Accounting, within telecommunications operator's own organisation; and

Accounting, other telecommunications operator.

If a service has a qualifying period and the user hangs up, upon receiving the rate information, the user will not be billed but an SDR for accounting may be issued so that th^ n t ork pr^{o ;}der gets pairl [MANDATORY]

Session Identifier - May be used to identify several SDRs associated with a session If SDRs within a session are produced by different Service Producing Elements, the Session Identifier must be communicated between the Service Producing Elements so it has the same value in all SDRs. [OPTIONAL]

Sequence Number - May be used to indicate the sequence, within a session, in which several related SDRs have been produced The Sequence Number may be useful when a service use session results in several SDRs being output, or if a service use session extends over a long time peπod as is the case with leased lines If SDRs, within a session, are produced by different Service Producing Elements, the Sequence Number must be communicated between the Service Producing Elements so it forms an unbroken sequence [OPTIONAL]

SDR Identifier - Uniquely identifies an SDR that has been produced by a particular Service Producing Element. This identifier may be used to distinguish between duplicates. The SDR Identifier may be represented as a 32 bit integer, incremented once for each SDR being produced. This gives a sequence of 4,294,967,295 unique identifiers before the sequence is repeated. [MANDATORY]

Date Of Oπgin - Specifies the date on which the SDR was produced. [MANDATORY]

Time Of Origin - Specifies the time of day when the SDR was produced. [MANDATORY]

Responsibility Trace - May be used by a system taking part in service production to indicate that it has taken responsibility for the SDR, hence it may contain a sequence of system identifiers and time stamps The Responsibility Trace may be used as follows - when a Service Producing Element delivers the SDR tn the Serv'ce ^Dr'cιng System e d the latt r r.a . secured it, the Service Pricing System may indicate this by appending a responsibility tag and the Service Producing Element may purge the SDR from its storage [MANDATORY]

Action Indicator - Indicates what kind of action the Service Pricing System is requested to perform. The specific values are:

the S3R shall be priced and forwarded to a post-processing syste--

the S3 is a request for price, or rate, information and shall be returned to the Service Producing Element, the SDR is for quality assurance and shall not be priced;

the SDR is for service management and shall not be priced. [MANDATORY]

Data items in the Network Service Module are appended by the Services Producing Element. Data items, mandatory, or optional, may appear more than once within the module, as indicated. The following data items belong to this module.

Service Module Identifier - Identifies the network service module. [MANDATORY]

Revision State - The version of the ASN.1 data type defining the network service module. A module in a given version must not be altered. [MANDATORY]

NSM/SUM Correlator - If the SDR contains more than one network service module, each module must have an identifier value that is unique within the SDR. This same value shall be present in all, one, or many, service usage modules associated with this network service module. [OPTIONAL]

The following set of data items may appear several times within the module. If they do, the whole set is repeated as an unbroken sequence.

Network Provider - Identifies the network provider having put his network to the services disposal. [MANDATORY]

Type Of Network - The type of network having been used, for example, a signalling network, IP-network, or a voice channel. [MANDATORY]

Date For Start Of Charging - Specifies the date on which the charging duration starts. [MANDATORY] 3

- 41 -

Time For Start Of Charging - Specifies the time of day at which the charging duration starts. [MANDATORY]

Chargeable Duration - Specifies the time period for which a charge has to be calculated. [MANDATORY]

Consumed Capacity - [OPTIONAL]

SSE Identifier - Uniquely identifies the service switching element. [OPTIONAL]

The following data items may be present in the static part of the TT- information produced by a telecommunications operator's VPN-service.

Record Type -

Record Size -

Cause For Output -

Record Number -

Call Id Number -

Record Sequence Number -

Fault Code -

Cail Status -

Forced Disconnection -

Call Attempt Indicator - Call Attempt State -

Cause Code -

Location Code -

Type Of Signalling -

Type Of A-subscriber -

Length Indicator A-subscriber - not present in TT-info from MSE

A-subscriber Number -

A-category -

Type Of A-number -

A-subscriber Numbering Plan -

Type Of B-subscriber -

Length Indicator B-subscriber - not present in TT-info from MSE,

B-subscriber Number -

B-category (EOS information)

Type Of B-number -

B-subscriber Numbering Plan -

Charging Case - Charged Party -

Origin For Charging -

Telecommunication Service Code -

Type Of Seizure -

Type Of Indicator -

Type Of Procedure -

Result Of Subscriber Service Procedure -

Date For Start Of Charging -

Time For Start Charging 24h -

Chargeable Duration/Time -

Time From Reg. Seizure To Start Of Charging -

Number Of Meter Pulses -

Number Of User-To-User Messages In Call Control Messages -

Number Of User-To-User Messages During Call -

End To End Access Data Indicator -

End To End Access Data Map -

End To End Access Data Counter - Leπgth Indicator X-subscriber - not present in TT-info from MSE

X-subscriber Number - not present in TT-info from MSE

Length Indicator Abbreviated Number - not present in TT-info from MSE

Abbreviated Number -

Conference Call Indicator -

Presentation Indicator (CLIR) -

Originating Code -

Destination Code -

Exchange Identity -

Outgoing Route -

Incoming Route -

Carrier Access Code -

Date Of Command - not present in TT-info from MSE

Time Of Command - not present in TT-info from MSE

Command Name - not present in TT- info from MSE

The following data items may be gathered from a CDR Message.

CDR Message Type - CDR Record Size -

Exchange Identifier AX.Id -

File Identifier -

(Sub)File Number -

Record Sequence Number -

Record Type -

Call Identification Number -

Call Status -

Cause For Output -

Partial Record Number -

A-Number -

A-Category -

A-Number Type -

A-Number Plan Indicator -

A-Subscπber Type -

B-Number -

B-Number Type - B-Number Plan Indicator -

C-Number -

Dialled Digits To IN Service -

Record Sequence Number ISTT -

VPN Call Information -

Date For Start Of Charging -

Time For Start Of Charging -

Chargeable Duration -

Interruption Time -

Fault Code (EOS) -

Abbreviated Number -

Origin Of Charging -

Type Of Seizure TOS -

Telecommunication Service Indicator Code TSC

Call Indicator Cl -

Result Of Procedure -

Subscriber Service Indicator SSI TOI - Subscπber Service Indicator SSPTOP -

Conference Call Indicator -

Midnight Line Service -

Network Conversion Facility -

User-To-User Messages Duπng Call Control (UUS1) -

User-To-User Messages Duπng The Call (UUS2 - 3) -

ISDN Subscπber Service Indicator 1 -

ISDN Subscriber Service Procedure 1 -

ISDN Subscriber Service Indicator 2 -

ISDN Subscriber Service Procedure 2-

ISDN Subscriber Service Indicator 3 -

ISDN Subscriber Service Procedure 3 -

ISDN Subscriber Service Indicator 4 -

ISDN Subscriber Service Procedure 4-

Special Information (Miscellaneous) -

Customer project -

TIMS Price - Credit Card Number -

General Account Number -

Charged Participant -

Service identifier -

Type Of Access -

VPN Call Type -

IN Call Indicator -

Function Trace x 4-

IS-TT Duplicating Sequence Number -

MRS Status -

Price 1 -

Price 2 -

Price 3 -

Pπce 4 -

Call Type 1 For Price 1 -

Call Type 2 For Price 2 -

Rate Period Identifier 1 - Rate Period Identifier 2 -

Multiple Rate Periods 1 -

Multiple Rate Periods 2-

Price Table Identifier -

VAT Identifier 1 -

VAT Identifier 2 -

Bill Service Identifier -

Purpose For Billing -

Rating Status -

Repair Status -

Service Type Indicator -

Charged Subscriber Number -

Charged Subscriber Number Plan Indicator -

Call Session Indicator -

A service usage module is specific to an infocom service in the sense that it contains data items present in all service usage modules and data items related to a particular iπfcccm service.

Data items present in all service usage modules are appended by the Services Producing Element. All data items, mandatory, or optional, appear only 09733

- 50 - once in the module. The following data items belong to the Service Usage Module

Service Module Identifier - Identifies the service usage module [MANDATORY]

Revision State - The version of the ASN 1 data type common to all service usage modules. A module in a given version must not be altered [MANDATORY]

Service Feature Code - Identifies this particular infocom service [MANDATORY]

Revision State Of Service - The version of the ASN.1 data type specific to this service module. A service module in a given version must not be altered. [MANDATORY]

User Identifier - Identifies the infocom service user The user may be identical to the provider, as is the case when a service provider changes the rates, or updates information. If an SDR contains both a User Identifier and a Calling Number, or A-subscπber Number, the User Identifier overrides them all. [OPTIONAL]

Provider Identifier - Identifies the infocom service provider. [MANDATORY]

Marketing Company - Identifies the marketing company that the customer belongs to The specific values, for Telia, are:

- Telia MegaCom,

- Telia PubliCom,

- Telia Foretag - Telia Nara;

- Telia A/S (Denmark);

- Telia Norge AS

- Telia Polen;

- Telia Estland;

- Telivo Oy (Finland);

- Netia (Poland);

- North West GSM (St Petersburg);

- Estonian telephone Company;

- Latvian Mobile Telephone;

- Telemedia AB (Lithuania). [MANDATORY]

Charged Participant - May be used to indicate that someone other than the User, Calling Number, or A-Subscriber Number, is to be charged One example is an ordinary collect call. [OPTIONAL]

Dialled Number - The dialled number used for the call connection, i e dialled digits to the infocom service. [MANDATORY]

NSM/SUM Correlator - If the SDR contains more than one network service module, each such module must have an identifier value that is unique within the SDR. This same value shall be present in this (and all other) service usage modules associated with the network service module

[OPTIONAL] 733

- 52 -

SUM/SPM Correlator - If the SDR contains more than one service usage module, each such module must have an identifier value that is unique within the SDR This same value shall be present in the network service module associated with this service usage module [OPTIONAL]

Data items specific to the Virtual Call Centre Service Usage Module are appended by the Services Producing Element Data items, mandatory, or optional, may appear several times within the module, as indicated The following data items belong to this module

Calling Number - The phone number of the calling party [MANDATORY]

Dialled Number - The Call Centre access number, i e the number dialled by the calling party to reach the service [MANDATORY]

Service Carner - The service, or call type, that carries the call to the Call Centre The specific values, for Telia, are

- Telia Fπsamtal,

- Telia Freephone,

- Telia Foretagsnummer,

- Telia Foretagsabonnemang,

- Telia Split (1 , 2, 3) [MANDATORY]

Customer Control Code - values for this data item may be defined in a future version of the VCC service

Having reached a destination number the calling party may once again be put in queue If so the following data items shall be repeated as an unbroken sequence and in chronological order within the module Each sequence of data 09733

- 53 - elements represent a service event

Destination Number - The phone number of the answering party [MANDATORY]

Event Code - The specific values are.

- The calling party was put in queue and hung up,

- The calling party was put in queue and reached a destination number,

- The calling party immediately reached a destination number. [MANDATORY]

Date For Start Of Charging- 1 - Specifies the date on which the calling party was put in a queue. [OPTIONAL]

Time For Start Of Charging-1 - Specifies the time of day at which the calling party was put in a queue. [OPTIONAL]

Chargeable Duration- 1 - Specifies the time period the calling party has spent queuing [OPTIONAL]

Date For Start Of Chargιng-2 - Specifies the date on which the calling party reached a destination number. [OPTIONAL]

Time For Start Of Chargιng-2 - Specifies the time of day at which the calling party reached a destination number. [OPTIONAL]

Chargeable Duratιon-2 - Specifies the time period the calling party has been connected to the destination number [OPTIONAL]

Data items soecific to the Virtual Private Network Service Usage Module are appended by t-e Services Producing Element Data items, mandatory, or optioπal, may appear several times within the module, as indicated The following data items belong to this module

Private Number A-subscnber - If the A-subscπber has a private number, this number is stored [OPTIONAL]

Public Number A-subscπber - If the A-subscπber has a public number, this number is stored [OPTIONAL]

Pπvate Number B-subscπber - If the private number of the B-subscπber is used to set up the call, his number is stored [OPTIONAL]

Public Number B-subscriber - If the public number of the B-subscπber is used to set up the call, this number is stored [OPTIONAL]

First Destination Number - If a routing or diversion feature is used, the destination number is wπtten here [OPTIONAL]

Second Destination Number - If the Call Forwarding feature is used on a destination number that was already output from a Call Forwarding feature, this destination number is written here [OPTIONAL]

Third Destination Number - If the Call Forwarding feature is used on a destination number that was already output from a Call Forwarding feature, this destination number is written here [OPTIONAL]

Cost Distnbution Code (CDC) - The CDC assigned to the A-subscπber, or his PABX, is written here In case of GVNS and Call Centre Access, the value of this data item is filled with zeroes [OPTIONAL]

Extra CDC 1 - The CDC assigned to the subscriber, or the PABX, of "First Destination Number" is written here [OPTIONAL]

Extra CDC 2 - The CDC assigned to the user, or the PABX, of "Second Destination Number" is written here. [OPTIONAL]

Extra CDC 3- The CDC assigned to the user, or the PABX, of "Third Destination Number" is written here. [OPTIONAL]

Account Number - [OPTIONAL]

Type Of Access - The specific values are:

- Direct;

- GVNS;

- Switched;

- Remote;

- Call Centre;

- Network Remote. [MANDATORY]

Originating Line Identity (OLID) - The OLID that is added in case of Di^rect Access. [OPTIONAL]

Terminating Line Identity (TLID) - The TLID that is added in case of direct termination, or Break-out. [OPTIONAL]

Dialled Number - The dialled number used for the call connection, i.e. dialled digits to the VPN service. [MANDATORY]

Call Type - The specific values are:

- Call terminated to On-net; - Call terminated to Off-net;

- Call terminated to Virtual On-net. [OPTIONAL]

Follow On Counter - Starts counting from the first follow-on call in a Remote Access, or Network Remote Access call, i.e. from the second destination number to which the caller is connected. In case of follow-on calls, an SDR is generated for every call. The SDR includes ID and Related ID. The first SDR has no Related ID. The next SDRs have the ID of the first as Related ID. [OPTIONAL]

Event Trace - Each time an event is executed in call handling, the specific value for that event is added. An event that is executed several times will appear several times with its value. The specific values are:

- Forced On-net;

- Privilege Override;

- Direct Termination Overflow;

- Break -Out;

- Call Diversion on Busy;

- Call Diversion on No Replay;

- Time-Dependent Routing,

- Call Screening (that is initial Number list);

- Follow-Me

- Origin-Dependent Routing, - Call Distribution,

- Leased Virtual Channels - no overflow;

- Leased Virtual Channels - overflow;

- Customer Control - PIN;

- Customer Control - Time-Dependent Routing;

- Customer Control - Advanced Forced On-net;

- Customer Control - Follow-Me, activate, own phone;

- Customer Control - Follow-Me, activate, other phone;

- Customer Control - Follow-Me, deactivate, own phone;

- Customer Control - Follow-Me, deactivate, other phone;

- Customer Control - Language Code;

- Overflow;

- Differentiated Call Screening. [OPTIONAL]

These event values shall be presented in chronological order with the latest event first.

Type of Redirection Indicator - The specific values are:

- General failure,

- General congestion, 3

- 58 -

- Congestion inside the VPN,

- Congest on outside the VPN,

- Failure inside the VPN,

- Failure outside the VPN [OPTIONAL] In case Direct Termination Overflow has been used, this data item shows whether redirection was done due to congestion, or due to failure

Authoπsation Code - In case of remote access and network remote access the user identifies himself by enteπng his authoπsation code and PIN This data item contains only the authorisation code and not the PIN [OPTIONAL]

Company Identifier - An identifier assigned to the subscπbing company This is the Company Identifier of the calling party, except in the case of GVNS and Call Centre Access, when it is the Company Identifier of the called party [OPTIONAL]

Authorisation Code Version 2 - [OPTIONAL]

IN Call Ind.cator - [OPTIONAL)

Non Dialab'e Pπvate CLI - (calling line identity) [OPTIONAL]

Non Dialac e Public CLI - [OPTIONAL]

Personal P^one Number - [OPTIONAL]

When mak ~g ^remote access calls, or network remote access calls, in the

Telia VPN service tre data item Authorisation Code contains the A-number to be charged l e the rc-e number of the calling party (The calling party enters his public phone πur-ee- as authorisation code ) The data item Public Number A- subscriber contains the A-number to be used for price calculation, i.e the number of the phone outside the VPN that has been used to make the remote access call

Data items specific to the Signalled Asynchronous Transfer Mode Service Usage Module are appended by the Services Producing Element. Data items. mandatory, or optional, may appear several times within the module, as indicated

The following data items belong to this module.

Originating Number - (format: E164 string). [MANDATORY)

Terminating Number - (format: E164 string). [MANDATORY]

Date For Start Of Charging - Specifies the date on which the charging duration starts. [MANDATORY]

Chargeable Duration - Specifies the time peπod for which charge has to be calculated. [MANDATORY]

Peak Allocated Bandwidth [MANDATORY]

Average Allocated Bandwidth - [MANDATORY]

Class Of Service - [MANDATORY]

Number Of Transmitted Cells/Frames - [MANDATORY]

Data items specific to the Broad Band Service Usage Module are appended by the Services Producing Element. Data items, mandatory, or optional, may appear several times within the module, as indicated Tne following data items belong to tnis module. ATM Service Identifier - Identifies a service within the ATM service [MANDATORY]

Chargeable Duration - Specifies the time period for which charge has to be calculated. [MANDATORY]

Session Identifier - May be used by the Service Pricing System and a post- processing system to recognize several events taking place duπng a session. [MANDATORY]

Type Of Event - Identifies the type having caused the output of this SDR, e.g. log in, log off, or change of home page on the web [MANDATORY]

Event Parameters - A set of parameters associated with the event e g http protocol, video conference, address of home page, type of information, or TCP^/|P-addresres. [MANDATORY]

This service issues an SDR every time a service event has taken place Hence, the Session Identifier may be used to associate events to a particular session This is contrary to the VCC service where associated events are output

Data items in the Service Pπcing Module are appended by the Services Pricing System Data items, mandatory, or optional, may appear several times within the module, as indicated The following data items belong to this module

Service Module Identifier - Identifies the service pπcing module [MANDATORY] 33

- 61 -

Revision State - The version of the ASN.1 data type defining the service pricing module. A module in a given version must not be altered. [MANDATORY]

SUM/SPM Correlator - If the SDR contains more than one service usage module, each such module must have an identifier value that is unique within the SDR. This same value shall be present in the network service module associated with the service usage module. [OPTIONAL]

Service Pricing Identifier - Identifies the Service Pricing System which calculated the price for the associated service usage module, or provided the requested price, or rate information. [OPTIONAL]

Date Of Pricing - The date the price information was calculated. [MANDATORY]

Time Of Pricing - The time of day the price information was calculated [MANDATORY]

Currency - The currency that has been applied to calculate the price information. [MANDATORY]

Value Added Tax - The level of VAT that shall be applied to the data items Basic Price and Individual Price. [MANDATORY]

A service usage module may contain several events. The price for each event may either be added up to a total amount, or presented as individual amounts. If the latter is the case, the following data items shall be repeated as an unbroken sequence within the module. The order within that sequence shall correspond to the sequence of events in the associated service usage module as indicated by the SUM/SPM Correlator.

Price Type - Indicates if the Price Information has been calculated on a per call basis, per function, per time-slice, or a combination of these [MANDATORY]

Basic Price - The price for the service usage, or service event in the specified currency, exclusive of VAT and any discounts [MANDATORY]

Individual Price -The basic price in the specified currency with applied discounts, but exclusive of VAT This is the pπce the user shall pay A discount may be granted if the user has an individual pricing agreement with the marketing company, or because the service was used during a low rate period [OPTIONAL]

Pπce Table Identifier - Identifies the price table used to calculate the Price Information [MANDATORY]

Revision State - The version of the price table used to calculate the Pπce Information A price table in a given version must not be altered [MANDATORY]

Bill Information - Indicates to a post-processing system what to print on the bill. What is actually printed may depend on the service, the provider and the user. [OPTIONAL]

Status Indicator - Indicates if the SDR has been pπced, or the reason why it cannot be priced. The specific values are:

- The price has been properly calculated,

- Unable to locate the Service Feature Code,

- Unable to locate the Revision State Of Feature,

- Unable to 'ocate the service user,

- Unable to locate the marketing company, 09733

- 63 -

- Unable to locate the price table;

- Unable to price due to technical error [MANDATORY]

To assist with understanding the present invention, a glossary of the terms used in this patent specification is set out below.

ASN.1: Abstract Syntax Notation One - is a syntax specifying how data types and their associated values shall be represented. Any other modern common programming language may serve the same purpose, e.g. Ada, or C. ASN.1 was developed in the early eighties and is nowadays defined in the CCITT recommendation X.208 and the ISO-standard 8824 as belonging to the presentation layer of the

OSI-model.

ATM: Asynchronous Transfer Mode

Ax: Automatic Exchange

BER: Basic Encoding Rules are a set of rules specifying how the ASN 1 data types and their associated values shall be encoded to a transfer syntax i e a seαu n ^ of oct<?tr The binary representation of these sequences of octets is called transfer code and is independent of the programming language and operational system being used. The transfer code is used when the data types and their associated values are being exchanged between open systems, i.e systems conforming to the OSI-model BER is defined in the CCITT-recommendation X.209 and the ISO-standard 8825

CAMS Customer Account Management System - in the present invention CAVS produces invoices for transmission to customers CAMS creates peπodic invoices for monthly, or quarteriy delivery, periodic charges may be priced in CAMS which can also produce one-time 33

- 64 - invoices and credit notes.

CDR: Call Detail Record is a data structure describing how a connectivity network has been used, e g. in terms of connection time and the geographical distance between the points of connection This information however, is not sufficient to bill infocom services

CSN: Connectivity Services Network - The CSN provides three kinds of services:

a signalling service, e.g. to connect users of infocom services;

a transport service to convey voice, text, picture and data between users of infocom services; and

an announcements/play messages service, this service may include other forms of outputs from intelligent peripherals

FAKT: a known and existing invoice system used in the billing chain for creating basic invoice data on priced posts

FTP: File Transfer Protocol

IN: Intelligent Network

Infocom. Infocom services are produced in the Information Services Network consisting mainly of service data points (SDP), service control points (SCP) and intelligent peripherals (IP) In this context the connectivity network provides the infra structure to the services

ISN Information Services Network - makes use of the Connectivity Services Network to provide infocom services 9733

- 65 -

MPS: When a customers makes a telephone call over the fixed network, one, or several, callposts, e.g. TT-posts are created. Files with TT- posts are gathered together by an IS-TT system. The callposts are then sent to MPS for validation.

NSM: Network Service Module

PNP: Private Numbering Plan

SCP: Service Control Point

SDP: Service Data Point

SDR: Service Detail Record - SDR is a data structure describing how an infocom service has been used. Such a use case may involve only one service, or a sequence of cooperating services ASN.1 and BER are applied to specify and encode/decode this data structure

SDR-Archive: Information in the SDR is stored in a relational data base called the

SDR-Archive. The information may be retrieved by post-processing systems, e.g. to produce bills, statistics and reports The information resides fo^r di^ffe^rent periede off time on different types of storage media with varying capacity and access times. Pricing information may be present in the SDR when it enters the SDR- Archive, or applied later on, by the post-processing Systems

SHM: Service Header Module

SPE: Service Producing Element - A SPE is part of the Information

Servces Network. The SPE may issue an SDR each time a sen ce event takes place, or wait until a service use session has been completed. The behaviour depends on the particular infocom service 733

- 66 - SPM: Service Pricing Module

SPS: Service Pricing System. The SPS provides rating and pricing information, on demand and in real-time, to infocom services. It also performs pricing of SDR's when output from the Service Producing Element. The Service Pricing System contains price and rate tables for various infocom services, marketing companies and customers. It also has the logic necessary to calculate the correct price for a service use session consisting of one, or many, cooperating services, provided by any marketing company to any customer; this includes applying the appropriate currency, VAT, together with various discounts and bonuses.

Service Switching Element

SUM: Service Usage Module

TC Transfer Code is the binary value of the octet string produced when BER is applied to an ASN.1 data type. Transfer syntax is another name for transfer code.

TT record: Toll Ticketing record

VCC: Virtual Call Centre

VPN: Virtual Private Network

Within the context of the present invention, as herein described, the following list of de^r .-.tions apply.

Bill: To ask and cc ect payment for the usage of an infocom service.

Charge: The cna-e established and collected by a service provider from its 9733

- 67 - customers for the use of an infocom service.

Customer: A customer may be the user and/or the provider of an infocom service.

Price: An amount of money independent of time. The price is calculated as the product of a given rate and the chargeable time duration.

Rate: An amount of money as a function of time.

SDR: An ASN.1 data type describing a specific service use session.

Service Event: An event taking place within a specific infocom service.

Service Usage: A service use session triggered by a human being, or an infocom service.

Service Usage Module: An ASN.1 data type describing one, or several, service events.

Service use session: May consist of one, or several, service events taking place within a single infocom service, or several interacting infocom services.

Tariff: A list of prices or rates.

Claims

/09733- 68 -CLAIMS

1 A telecommunications billing system, for use with a telecommunications system comprising

a communication services network containing

a plurality of service switching elements,

a signalling network, and

a transport network,

said telecommunications system being adapted to provide infocom services to customers and said billing system being adapted to provide flexible p╧Çcing and billing for usage of infocom services, characterised in that said billing system includes handler means for receiving SDRs generated by said service producing elements and transmitting said SDRs tn P scheduler r.-.╧Äa.╬╣s >n cndi said SDRs include Service Usage Modules, in that said service p╧Çcing scheduler means is adapted to associate a Service Usage Module with a price list appropnate thereto, and in that pricing means are provided for calculating a price associated with a Service Usage Module and inserting said price in a Service Pricing Module associated with said Service Usage Module

2 A telecommunications billing system, as claimed in claim 1 characterised in that after insertion of a p╧Çce in a Service Pricing Module said pricing scheduler means is adapted to return a priced SDR to said handler means

3 A telecommunications billing system, as claimed in claim 2 characterised in that said handler means is adapted to transmit priced SDRs to a SDR archive means adapted to store said priced SDRs until they are transmitted to a postprocessing system

4 A telecommunications billing system, as claimed in any previous claim characterised in that a service use session generates one, or more SDRs

5. A telecommunications billing system, as claimed in any previous claim, characterised in that Service Pricing Modules are added to SDRs, only after an SDR has been p╧Çced.

6. A telecommunications billing system, as claimed in any previous claim, characte╧Çsed in that each SDR is a collection of tagged data items desc╧Çbing a service use session.

7. A telecommunications billing system, as claimed in claim 6, characterised in that an SDR's size and content varies in accordance with an infocom service to which it relates.

8. A telecommunications billing system, as claimed in either claim 6, or 7, characte╧Çsed in that tagged data items in an SDR are encoded using the BER for

ASN 1

9. A telecommunications billing system, as claimed in any of claims 6 to 8, characte╧Çsed in that related tagged data items in an SDR are grouped into service modules

10. A telecommunications billing system, as claimed in claim 9, characterised in that a particular set of related tagged data items in an SDR are grouped into one of the following four types of service module

a Service Header Module, which contains tagged data items associated with a SDR as a whole,

- a Network Service Module which contains tagged data items related to consumption of network capacity by a particular service use session;

- a Service Pricing Module which contains tagged data items relating to pricing of an infocom service.

11. A telecommunications billing system, as claimed in claim 10, characterised in that an SDR contains:

- one, or more, Network Usage Modules; and

one, or more, Service Usage Modules.

12. A telecommunications billing system, as claimed in any of claims 6 to 1 1 , characterised in that an SDR contains a session identifier and a sequence number to enable a post-processing system to recover a chronological order in which SDRs were produced during a service use case.

13. A telecommunications billing system as claimed in an of claims 5 to 2, characterised in that an SDR contains at least the following tagged data items:

an identity of a customer;

an identity of a marketing company;

- an identity of a service to which the SDR relates;

and in that an SDR may contain one, or more of the following tagged data items

an access form; a time,

a date,

an identity of a user,

a connection identity;

an operator,

a service provider,

a customer price, and

a market price

14 A telecommunications billing system, as claimed in any of claims 10 to 13 characterised in that relationships between service modules within an SDR are governed by data items referred to as NSM/SUM correlators and SUM/SPM correlators, and in that these data items have unique values within an SDR

15 A telecommunicat'on^╧é hilling ystem a^ cla'mcd ╬╣r an- pr&vioub u╧îim characterised in that said billing system includes one, or more, price lists, and in that said p╧Ç╬▒ng system is adapted to implement p╧Çce list definitions, identify pnce lists to which an SDR relates and thereby produce priced SDRs

16 A telecommunications billing system, as claimed in claim 15, characterised in that said pricing scheduler means includes said pricing system and is adapted to receive SDRs, analyse SDRs and identify price lists appropriate to an SCR

17 A telecommL" cations billing system, as claimed in claim 16 characterised in that said pricing sc^heduler means is service independent and in that anything which is service, customer or market unique is incorporated in price lists 733

- 72 -

18. A telecommunications billing system, as claimed in either claim 16, or claim 17, characterised in that each infocom service has a unique pricing scheduler means associated therewith.

19. A telecommunications billing system, as claimed in any previous claim, characterised in that said pricing scheduler means is adapted to assemble a plurality of SDRs before said SDRs are priced.

20. A telecommunications billing system, as claimed in any of claims 16 to 18, characterised in that said pricing scheduler means is adapted to price individual SDRs.

21. A telecommunications billing system, as claimed in any previous claim, characterised in that customers are handled for pricing purposes, as individual customers, or as members of a customer group.

22. A telecommunications billing system, as claimed in any of claims 15 to 21 , characterised in that all price lists are based on a basic price list.

23. A telecommunications billing system, as claimed in any of claims 1 to 18. characterised in that price lists are of one of the following types:

a customer group price list, applicable to a group of customers, and

- a customer unique price list applicable to a single customer

24 A telecommunications billing system, as claimed in claim 23. characterised in that price lists are either lists of prices, or algorithms/functions for calculating prices

25 A telecommunications billing system, as claimed in any previous claim - 73 - characterised in that SDRs may be generated independently of any action performed by a customer.

26. A telecommunications billing system, as claimed in any of claims 4 to 25, characterised in that costs for a service use session are shared between different customers.

27. A telecommunications billing system, as claimed in any previous claim, characterised in that said billing system includes fault handling means adapted to process faulty SDRs.

28. A telecommunications billing system, as claimed in any previous claim, characterised in that said billing system is adapted to operate with infocom services having plural functions.

29. A telecommunications billing system, as claimed in any previous claim, characterised in that said information services network is an IN having a data server.

30. A telecommunications billing system, as claimed in any previous claim, characterised in that means are provided to label an SDR as erroneous, if a price list relating to an SDR cannot be identi ie

31. In a telecommunications system comprising: an information services network containing a plurality of service producing elements; and a communication services network containing a plurality of service switching elements, a signalling network and a transport network, said telecommunications network being adapted to provide infocom services to customers, a method of pricing usage of infocom services in a flexible manner, characterised by the steps of:

each service producing element, (SPE), generating SDRs

- collecting said SDRs at a handling means, said SDRs indue ng a

Service Usage Module; associating each Service Usage Module with a price list; and

determining a price to be associated with each Service Usage Module and adding said price to the SDR, containing said Service Usage Module, in the form of a Service Pricing Module.

32. A method, as claimed in daim 31 , characterised by returning priced SDRs to a handler means.

33. A method, as claimed in claim 32, characterised by transmitting priced SDRs to a SDR archive means and storing said priced SDRs therein until collected by a post processing system.

34 A method, as claimed in claim 33, characterised by said post processing system being an invoicing system.

35. A method, as daimed in any of claims 31 to 34, characterised by a service use session generating one, or more SDRs.

36. A method, as claimed in any of claims 31 to 34, characterised by adding Service Pricing Modules to SDRs, only after an SDR has been priced.

37. A method; as claimed in any of claims 31 to 34, characterised by each SDR being a collection of tagged data items describing a service use session.

38. A method, as claimed in claim 37, characterised by an SDR's size and content varying in accordance with an infocom service to which it relates.

39. A method, as claimed in either claim 37, or claim 38, characterised by encoding tagged data items in an SDR according to the BER for ASN.1.

40. A method, as daimed in any of claims 37 to 39, characterised by grouping related tagged data .terns in an SDR into service modules. /09733

- 75 -

41. A method, as claimed in claim 40, characterised by grouping a particular set of related tagged data items in an SDR into one of the following four types of service module

a Service Header Module, which contains tagged data items associated with SDR as a whole,

a Service Pn╬▒ng Module which contains tagged data items relating to p╧Çcing of infocom service.

42 A method, as claimed in claim 41 , characterised by an SDR containing

- one, or more, Network Usage Modules, and

one, or more, Service Usage Mrd lee.

43 A method, as claimed in any of claims 36 to 41 , characterised by an SDR containing a session identifier and a sequence number to enable a postprocessing systems to recover a chronological order in which SDRs were produced during a service usage case.

44 A method, as claimed in any of claims 36 to 42, characterised by an SDR containing at least tre following tagged data items

an ice-itity of a customer,

an identity of a marketing company, an identity of a service to which the SDR relates;;

and by an SDR containing one, or more, of the following tagged data items

an access form;

a time;

a date;

an identity of a user;

a connection identity;

an operator;

a service provider;

- a customer price; and

a market price.

45. A method, as claimed in any of claims 40 to 43, characterised by an SDR including data items referred to as NSM/SUM correlators and SUM/SPM correlators which govern relationships between service modules in the SDR, and by the values of these data items being unique within an SDR.

46. A method, as claimed in any of claims 31 to 45, characte╧Çsed by said billing system including one, or more, price lists, and by said billing system being adapted to implement price list definitions, identify price lists to which an SDR relates and thereby produce priced SDRs.

47. A method, as claimed in claim 46, characterised by a pricing scheduler means being adapted to receive SDRs, analyse SDRs and identify price lists appropriate to an SDR.

48. A method, as claimed in of claims 31 to 47, characterised by assembling a plurality of SDRs before pricing them.

49. A method, as claimed in of claims 46 to 48, characterised by basing all price lists on a basic price list.

50. A method, as claimed in claim 49, characterised by price lists being one of the following types:

a base price list which is independent of customer and time of use of service);

- a customer group price list, applicable to a group of customers: and

a customer unique price list applicable to a single customer

51. A method, as claimed in claim 50, characterised by price lists being either lists of prices, or algorithms/functions for calculating prices.

52. A telecommunications system, charac'.e.isbd in mat s┬½╬╣╬╣╬▒ telecommunications system includes a billing system, as claimed in any one of claims 1 to 30, or in that said telecommunications system is adapted to price telecommunications service and network usage using the method claimed in any one of claims 31 to 51.

53. A telecommunications system, as claimed in claim 52, characterised in that said post-processing system is an invoice system.

54. A telecommunications system, as claimed in either claim 52, or cla.m 53 characte╧Çsed in that SDRs are moved from service producing element, to o╧Çcing scheduler means, to an invoicing system. 99/09733

- 78 -

55 A telecommunications system as claimed in any of claims 52 to 54 characterised in that SDRs may be used for any of the following functions

billing, both inside and outside a telecommunication operator s own organisation,

- consolidated billing,

production of reports and statistics,

quality assurance, and

service management, including identification of fraud churning abnormal traffic loads, failure rates and technical malfunctions

56 A telecommunications system as claimed in any of claims 52 to 55 characterised in that post-processing systems, requiring access to information contained in SDRs, subscribe to said handler means

57 A telecommunications system, as claimed in any of claims 52 to 56 characterised in that said system has a single invoice printing function

58 A telecommunications system, as claimed in any of claims 52 to 57 characte╧Çsed in that said p╧Çcing scheduler means handle p╧Çcing of traffic rates and service events and in that p╧Çcing related to periodical charges subscription charges and discounts are handled by post processing systems

59 A telecommunications system, as claimed in any of claims 52 to 58 characte╧Çsed in that each post-processing system subscribes to SDRs from one or more infocom services, and/or to selected data items from within an SDR

60 A telecommunications system, as claimed in any one of c aims 52 to 59 characterised in that post-processing systems collect SDRs at predetermined intervals from a SDR archive and/or in that post-processing systems are alerted ΓÇ₧ .ΓÇ₧ΓÇ₧ΓÇ₧ΓÇ₧, PCT/SE98/01370 99/09733

- 79 - when SDRs are available for collection in a SDR archive.

61. A telecommunications system, as claimed in any one of claims 52 to 60 characterised in that at least some infocom service producing elements issue SDRs as a request for pricing information, which SDRs are passed to pricing scheduler means, priced and returned to said service producing elements

62. A telecommunications system, as claimed in any of claims 56 to 61. characterised in that SDRs without a subscribing post-processing entity are discarded while SDRs having a subscribing post-processing entity are retained for a period of time in a SDR archive.