SE512479C2 - Improvements in, or in connection with, telecommunications systems - Google Patents

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

di » 10 15 20 25 30 35 512 479 2 after two days that the billing system can start trade the information in the call records.

In short, the shortcoming of today's debiting system following. limitation to conventional base telephony (time and distance); - limited national numbering plans; - loss of important information; - inability to charge for service functions; and inability to provide pricing details in real time.

In modern IN-based telecommunication systems, introduction of customer data through a large number of system that administers the various organizational units in telecommunications systems. This results in some overlap of information and introduces a very significant risk of errors and inconsistencies. In order to enable a customer to use a telecommunications cation service, three types of customer data need to be entered: a description of the customer's network, i.e. business growth telephones, modems and faxes, which forms part of the customer's network; - number plans, speed dial numbers, functions and reply messages selected by the customer; and - billing information that reflects the customer's organization structure so that he can be invoiced needs.

Ideally, customer information should be entered via a system that distributes information to the administrative administrative systems and the service-producing elements such as used to produce the service. It is, however important that the customer himself should have the opportunity to influence and be affected by their own services, i.e. via Inter- net. Customer data should therefore be handled by a central customer care systems such as: 10 15 20 25 30 35 512 479 3 achieves a uniform entry of customer data to a single place in the telecommunications system duction apparatus; - allows the rapid introduction of new services; - allows a rapid extension and modification of advisory services; - provides monitoring services; and provides customer care tools.

The billing system of the present invention creates the ability to generate new types of price lists for the provision of telecommunications services_ This in turn makes it possible to develop completely new ones services with completely new service structures. Thus it can price systems used today are replaced by price lists in it the flexible charging concept according to the present invention ning.

According to the present invention, pricing is divided of a service in a number of steps, namely: - the service provides information on what it has made, to an SDR (Service Detail Record, service detail item); - a billing system manager, or SDR subscriber service, receives an SDR and sends it to one service pricing planners; - service pricing planner picks out a service tean usage module (SUM), described later in this description, from said SDR and, depending on the customer identification specified in the specific module, associates the module with a price list take as the customer has approved; - the price list system unpacks service usage hidden and analyzes what is to be priced; - the price is calculated and entered into a service pricing module (SPM); H * \ || u um x w nu u u | u w fm w w vw 10 15 20 25 30 35 512 479 4 - the service pricing module is linked to the usage module and returned to the pricing the planning planner; - the pricing planner associates all the services use modules with their service pricing modules and returns the priced SDR to the debit system manager; and - the debit system manager sends priced SDRs to an SDR archive, or storage, for caching until a finishing system, e.g. an invoicing system, it retrieves.

The pricing planner is unique. A pricing planners can price each individual SDR individually, where another can put together a number of SDRs, for one session, before the price is calculated. This is entirely due to the way in which the service produces SDR and how the service priced.

Some pricing planners can put together, in and of themselves themselves, a number of SDRs, before the information is sent to pricing system.

A customer can be handled either as an individual customer, or as a customer belonging to a customer group. All customers belongs to a sales company. A service can sell by one or more sales companies.

A defined basic price list forms the basis for everyone price lists in the service. It does not specify prices, however represents a skeleton on the basis of which all other lists are based.

Each sales company has its own price lists.

These are of the following types: - basic price list; - customer group rice list; and - customer price list.

The basic price list contains the underlying basic price the price list for the service in a specific market. Basic- 10 15 20 25 30 35 512 479 b the price list is independent of the customer and the time when the service is used. The basic price list can be the price list to which the large mass of customers are connected. The there is only one basic price list.

The customer group price list is a type of price list that includes pours a special pricing for a specific customer group. The number of customer group rice lists depends on the customer groups as defined. Customer grouping is a way to achieve offer, to the large mass of customers, unique prices without being overwhelmed by a variety of prices lists.

The customer-specific price list is a type of price list that created for a specific customer. This price list is thus the actual customization. It is available for important customers, or customers who, for any reason, can not be linked to any customer group.

Some price lists are in fact a list of prices while others are based on algorithms, or functions, from which actual prices are calculated. The simple load form of price list is only a table of prices.

A complex price list system puts them all together SDR relating to a session before calculating a number of pri- looks.

The customer is involved in all pricing cases.

This does not mean that a user is always involved because services can act autonomously.

The costs of a session can be shared by different there. A- and B-sides have different forms of access.

Consider some basic pricing cases: 1. "A" communicates with "B", e.g. connection via PSTN.

"A" accesses a service and, through this service, indicates with "B", e.g. calls from GSM to VCC, which in a queuing system makes a forward-looking connection PSTN. "A" accesses a service, e.g. listens to their mobile response system via the PSTN.

\ \ \ HHI IIIM \ IW H w-w | ' Hlwn n l 10 15 20 25 30 35 512 479 6 4. The service communicates with "B", e.g. achieves one output signal from a Multi-Fax service. 5. The service performs a function that does not involve anyone communication, e.g. stores faxes that do not retrieved during an extended storage period. 6. The service communicates with it another service, e.g.

VCC uses the answering service.

The present invention can easily handle all of them these pricing cases, and is flexible enough for to also cope with many other pricing cases.

According to a first aspect of the present invention provides a telecommunications billing system, for use in conjunction with a telecommunications system, comprising: an information service network containing a number service-producing elements; and - a communication network containing: - a number of service switching elements; - a signaling network; and - a transport network; wherein the telecommunication system is arranged to provide information access services to customers and system is arranged to provide flexible pricing and billing for the use of information services, characterized in that the billing system includes handling means for receiving SDR generated of the service-producing elements and the transmission of said SDR to a service pricing planner, that said SDR includes service usage modules, that the service pricing planner body is arranged to create a service usage module with one suitable for it price list, and that pricing bodies are provided for calculation of a price associated with a service turning module and entry of the price in a service price module associated with the said service turning module. d: 10 15 20 25 30 35 512 479 7 After entering a price in a service pricing said pricing scheduler means may be used. arranged to return a priced SDR to the management ganet.

Said handling means may be arranged to transfer priced SDRs to an SDR archiving device arranged to store said priced SDRs until they are transferred to a finishing system.

A service usage session can generate one or several SDRs.

Service pricing modules can be added to the SDR only after an SDR has been priced.

Each SDR can be a collection of tagged data objects such as describes a service usage session.

The size and content of an SDR may vary accordingly with an information access service to which it relates.

Marked data objects in an SDR can be coded using BER for ASN.l.

Linked, labeled data objects in an SDR can be grouped in service modules.

A specific set of linked, labeled data objects projects in an SDR can be grouped into one of the following four service module types. - a service main module that contains labeled data objects projects associated with an SDR as a whole; - a network service module, which contains labeled data projects linked to the consumption of network capacity citation of a special service use session; a service use module, which contains labeled data objects linked to service use; and - a service pricing module, which contains labeling take data objects relating to the pricing of an info- comet service.

An SDR can contain: - one, or more, network usage modules; and one or more service usage modules. 1 f H 'I IIIII_II \ _I \ IE I H mliii n u || in: | 10 l5 20 25 30 35 512 479 An SDR can contain a session identifier and a sequence number to enable a follow-up treatment system to restore a chronological order according to which several SDRs were produced during a use cases.

An SDR may contain at least the following labeled data object: - a customer identity, - an identity of a sales company; - an identity for a service to which the SDR relates; and an SDR may contain one, or more, of the following marked data objects: - and access type; - a time; - a date; - a user identity; - a connection identity; - an operator; - a service provider; - a customer price; and a market price.

Relationships between service modules inside an SDR can controlled by means of data objects called NSM / SUM relations and SUM / SPM correlators, and these data objects may have unique values inside an SDR.

The billing system may include one, or more, price lists, and the pricing system can be arranged to implement price list definitions, identify price lists to which an SDR is linked and thereby produced cera priced SDR.

Said pricing planner means may include pricing system and may be arranged to receive SDR, analyze SDR and identify price lists that are suitable for an SDR. 10 15 20 25 30 35 512 479 9 Said pricing planning body may be a service independent, and any service, customer or service market uniqueness can be included in price lists.

Each info access service can have a unique pricing planning body associated with it.

Said pricing planner means may be provided to assemble a plurality of SDRs before said SDR pricing set.

Said pricing planner means may be provided to price individual SDRs.

Customers can be managed, for pricing purposes, such as individual customers, or as members of a customer group.

All price lists can be based on a basic price list take. Price lists can be of one of the following types: a basic price list, which is independent of customer and time of use of an information access service; a customer group price list, which is applicable to one group of customers; and - a customer-specific price list, which is applicable to a divorced customer.

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

SDR can be created independently of any action performed by a customer.

Costs for a service usage session can be shared between different customers.

Billing systems may include error handling means which are arranged to process incorrect SDRs.

The billing system may be arranged to operate together with information access services with several functions.

Said information service network may be an IN with one server.

Means may be provided to label an SDR such as incorrect, if it is not possible to identify a price list to which an SDR is connected. llu- l ll l ll 'l' lll l 1 ll ll l ' 10 l5 20 25 30 35 512 479 10 According to a second aspect of the present invention a pricing procedure is used information services in a flexible way in a telecommunications communication systems comprising: an information service network containing a number of service-producing elements; and a communication service network that contains a number service switching elements, a signaling network and a transport network, wherein the telecommunication network is arranged to provide information access services to customers, drawn by the steps: - that each service-producing element (SPE) generates rerar SDR; - said SDR being collected in a handling means, wherein said SDR includes a service user module; to associate each service use module with a price list; and to set a price to be associated with each service usage module and to add pri- set to the said SDR, which contains service users module, in the form of a service pricing dul.

Priced SDRs can be returned to a management device gan.

Priced SDRs can be transferred to an SDR archive body and stored in it until they are collected by an treatment system.

The finishing system can be an invoicing system.

A service usage session can generate one or several SDRs.

Service pricing modules can be added to the SDR only after an SDR has been priced.

Each SDR can be a collection of tagged data objects such as describes a service usage session. 10 15 20 25 30 35 512 479 ll The size and content of an SDR may vary accordingly with an information access service to which it relates.

Marked data objects in an SDR can be coded according to BER for ASN.l.

Linked, labeled data objects in an SDR can be grouped in service modules.

A specific set of linked, labeled data objects in an SDR can be grouped into one of the following four dulty type: - a service head module, which contains labeled data objects associated with an SDR as a whole; - a network service module, which contains labeled data project relating to the consumption of network capacity of a special service use session; a service use module, which contains labeled data objects relating to service use; and a service pricing module that contains labeled data objects relating to the pricing of information service.

An SDR can contain: - one, or more, network usage modules; and one or more service usage modules.

An SDR can contain one session identifier and one sequence number to enable a subsequent system of action to restore a chronological order which SDR was produced during a service use ningsfall.

An SDR may contain at least the following, labeled data object: - a customer identity; - an identity of a sales company; - an identity for a service to which the SDR relates; and an SDR may contain one, or more, of the following marked data objects: - and access type; I íl 'M HW ' 10 15 20 25 30 35 512 479 12 - a time; - a date; - a user identity; - a connection identity; - an operator; - a service provider; - a customer price; and a market price.

An SDR can include data objects called NSM / SUM correlators and SUM / SPM correlators which control the countries between service modules in the said SDR, and these data object values can be unique within an SDR.

The billing system may include one, or more, price lists, and the billing system may be arranged to implement price list definitions, identify price lists to which an SDR is connected and thereby produce priced SDR.

A pricing planner may be provided to receive SDRs, analyze SDRs and identify price lists as are suitable for an SDR.

A number of SDRs can be put together before pricing.

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

Price lists can be of one of the following types: a basic price list that is independent of customer and time of use of a service; a customer group price list, which is applicable to one customer group; and - unique price list, which is applicable to a single divorced customer.

Price lists can either be price lists or algorithms / functions for calculating prices.

According to a third aspect of the present invention provides a telecommunications system, characterized by that the telecommunications system includes a 10 15 20 25 30 35 512 479 13 systems, as described in the preceding paragraph, or by the fact that the telecommunication system is arranged to price telecommunications services and network use by means of a procedure as described in any going piece.

The finishing system can be an invoicing system.

SDR can be moved from service-producing elements to pricing planning bodies for an invoicing system stem.

SDR can be used for any of the following features: - debiting, both inside and outside a telecommunications cation operator's own organization; - consolidated debit; - creation of reports and statistics; - quality assurance; and - service management, which includes identification call of fraud, so-called "churning", abnormal traffic loads, fault frequencies and technical malfunctions.

Finishing system, which requires access to information contained in the SDR may subscribe to the said handling means.

The system may have a single billing print function tion.

Said pricing planner body can handle pricing setting of tariffs and service events, and pricing setting relating to periodic charges, subscriber charges and discounts can be handled by finishing systems.

Each finishing system subscribes to SDR from one or more info access services and / or on selected data jekt from inside and SDR.

Finishing systems can collect SDRs, in the event of tamed intervals from an SDR archive, and / or subsequent | MM mn u WW F.

'W ~ v' w u w ' "Il \ '|" \ H 10 15 20 25 30 35 512 479 14 action systems can be alerted when SDRs are available for collection to an SDR archive. At least some infocom service producing elements may issue SDRs as a request for pricing information which SDRs are sent to pricing planning bodies, priced and returned to the service-producing elements menten.

SDR that lacks a subscriber finisher can be abandoned while SDR with a subscriber finisher unit can be retained for a period of time in an SDR file.

Embodiments of the invention will now be described. written, -as an example, with reference to the attached the drawings, in which: Figure 1 illustrates, in schematic form, an overview over a flexible billing system in accordance with the present invention.

Figure 2 illustrates, in schematic form, the architecture of a flexible debit system in accordance with the present invention.

Figure 3 illustrates in schematic form, the development of a service using the flexible billing system according to the present invention.

Figure 4 illustrates the relationship between price lists according to the present invention.

Figure 5 illustrates the basic structure of labeled data object.

Figure 6 illustrates an SDR's service module structure.

Figure 7 illustrates the structure within service use module according to Figure 6.

Figure 8 illustrates the structure inside the service module according to Figure 6.

Figure 9 illustrates the relationship between service modu- laughs in SDR.

Figure 10 illustrates that a service usage session can include events within an individual service or 10 15 20 25 30 35 512 479 15 within several services that interact in sequence or parallel lellt.

Figure 11 illustrates how the number of SDRs created by a service usage session depends on the type of service cooperating services.

Figure 12 illustrates how a service usage module may contain one or more linked service events.

Figure 13 illustrates why certain information is needed communicated between different SPEs.

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

Figure 15 illustrates, in schematic form, a way of which a subscription service offers SDR information as a common resource for finishing systems.

Figure 16 illustrates the billing chain within, and outside, the organization of a telecommunications operator.

Figure 17 illustrates the way in which consolidated billing enables a full range of services can be debited together on a single invoice.

Figure 18 illustrates the ways in which SDR information tion can be achieved in a number of different forms.

Figure 19 illustrates the use of SDR, and it information contained therein, for the calculation of costs the provision of services, signaling and communication.

A glossary of terms and a set of formulas definitions can be found at the end of this description to facilitate an understanding of the same.

Referring now to Figures 1-4, an overview is given of a debit system in accordance with the present finding.

The core functions of the flexible debit system The methods of the present invention are: - data collection; - debit; - creation of invoices; .u .Al 10 15 20 25 30 35 512 479 16 - payment; - payment confirmation; and follow-up.

The debiting chain of the present invention alises a process that involves several steps. Compatible The present invention solves, inter alia, the problems which are associated with pricing and billing. Requires however, more of a billing system - SDRs must be collected and invoices must be created.

It is therefore necessary to: - ensure that SDRs that can be priced are collected, but no others; - prepare the correct price list on the basis of formation in SDR; - price SDR according to the price list; - ensure that the priced SDRs can be reached by MPS; and - ensure that incorrect SDRs are handled incorrectly.

The flexible debiting system according to the present invention includes a number of useful features, for example pricing planner and SDR error handler. This illustrated in Figure 1. Within the total service product module there is a register of service use, a module for compiling pricing information and a module for creating SDRs. These devices output data to the billing system, as shown in Figure 1.

In addition, data can be output from service usage data register to a module for defining price lists as are located in a service development element. Data from mo- the dule that compiles pricing information is fed to a module that identifies price lists, which again is located in the service development element_ Data is fed also from the service development element to the billing system system, as shown in Figure 1, which contains units 10 15 20 25 30 35 512 479 17 for pricing of service use, analysis of pricing settlement information and collection of SDRs.

The service and the pricing planner are interconnected. those through the price list and SDR. The price list defines what to be priced and what this costs. SDR refers to what is to be priced in each individual case.

When considering an individual pricing case, form an SDR pricing planner about what can priced for service use. The price list gives price the planning planner the data about the service it needs said that it can price an SDR correctly.

The system architecture used to implement The debit system is shown in Figure 2. The IN service is provided to a client, possibly via a server l. The client is linked, directly or indirectly, to the billing system which includes a pricing planner and price list system stem, as shown. The billing system sends priced SDR on to other subsystems in telecommunications systems system, such as the subsystems named MPS, FACTS and CAMS, via a server 2. As shown in Figure 2 three basic processes of the system, namely: - definition of price lists; - identification of price lists; and production of priced SDRs.

SDR is moved from within a service production subsidy stem, d v.s. a service-producing element in the network, nom the pricing planner in the billing system to the billing train. The SDR has an information field which consistently meets the requirements through the chain.

The operation of the billing system is not affected in this way on which SDR is entered into the database, is also not affected that of where and how SDRs are created. The only requirement is that SDR eventually ends up in the database. The client collects all of them SDR to be priced. This is important because it there are SDRs that do not contain pricing information_ The responsibility for the billing system begins with the client. r \ | '“' \ r MIn \\ '| 1 ll! 'Y w l u ir x n 'w iii 10 15 20 25 30 35 512 479 18 The SDR includes the interface between service and pricing planner.

The pricing planner receives and analyzes each individual SDR. The analysis results in a defined price list take if everything works correctly.

The price list system reads SDR and picks out correctly price or prices. Some manipulation may be required to obtain the correct price for a given customer.

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

The process of developing a service, as referred to with the billing system of the present invention, is illustrated in Figure 3. This process essentially persists of three steps: - the very development of services; - service production; and adaptation.

In the first stage of service development, it is necessary to develop the service functions, define price lists for the service, define SDR and create SDR. In the case of the tea production stage must be product unique, and ka, price lists are produced. At the last step in this process must produce unique customer price lists.

A service will have a number of features, which can be priced separately, when using the billing the system of the present invention. The exact the poison system is determined by the service. The billing system according to the present invention places no limitation on the possibilities of charging.

The price list defines what can be priced within the service. If something is to be priced, one must also SDR is created. 10 15 20 25 30 35 512 479 19 SDR defines the basis for pricing. About an SDR to be created, the content must be defined.

In the service production step, the price list is defined for the product with regard to the sales company which shall sell the service. Every sales company can have their own pricing and, consequently, their own pricing take. However, it is only possible to price it defined by the service.

At the adaptation step, the price list for it is defined individual customer. Unique customer agreements can lead to unique pricing lists. Individual customer service provider contracts can mean that a customer has their own pricing and actually its own price list.

The pricing planner is a universal feature within the billing system, i.e. it is complete transparent for the service. Everything that is unique to the service, customer uniqueness or market uniqueness must be included in the tan.

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

A price list should be changed at pre-determined times points. The old price list can be overwritten. A price- list must have a validity scheme.

It is also possible to cancel price lists.

In order for the pricing planner to be able to price take an SDR must this be identified. It is therefore necessary search the database where SDR is stored and that the ra any SDR that is not priced as not priced.

In order to be able to price, most pricing planners clean find the correct price list. An SDR contains information tion that identifies the correct price list. For example. can an SDR contain: - customer's identity - this must always be included; HI! \\ '\ I' H \ 'l- R IN | l \ | ll || hrs 10 15 20 25 30 35 512 479 20 the identity of the sales company ~ this must always included; the identity of the service to which it relates - this must be available for service use pricing; access type - this must be available for access arrival pricing; time - this must always be included; date - this must always be included; user identity; 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 price list is available.

Not all optional terms need be specified to identify a price list. The correct price list identified by the fact that all specified requirements are fulfilled. Otherwise, no guarantee can be given that it correct price list will be identified.

A general price list, i.e. one that is market-coupled loaded or customized, identified by the parameters: customer; sales companies; service; access forms; time; and - date.

Example: l. customer: 123456-7 2 sales companies: Telia Company 3rd position: Faxbox 4 Internet access types 5 10 15 20 25 30 35 512 479 21 5th time: Date 6: 14:33:15 30.ll.96 These parameters will provide a general price list for a Telia service known as Faxbox.

Example: l. customer: 123456-7 2. sales company: Telia Company 3rd position: Faxbox 4. Internet access type 5th time; 14 33 15 6. date: 30.ll.96 7. market price: YES These parameters will generate a market .unique price list for Faxbox.

If the price list cannot be identified, the said is marked SDR as incorrect and the cause is noted.

The pricing process is illustrated in Figure 4. Mentioned SDRs contain labels for the number of services used expected during a session.

The price lists can largely consist of a conventional one list of prices running from top to bottom, or it may have analysis and calculation functions to do so possible to arrive at the correct price.

The price list system sets the price and pricing the operator is thereby satisfied. In connection with price the price list system marks the said SDR as the price Sat.

Due to settlement with the Internet and other networks this type of access has its own marking and price list.

Priced SDRs must be marked as already priced.

It may happen that an SDR cannot be priced. Mentioned SDRs must be appropriately labeled as follows: - incorrect; - cause of error; and or - field detector.

I ”Hnnll www v -w ä .. | üwli | liml l 10 15 20 25 30 512 479 22 Said SDR consists of a general part and a number markings. The general part identifies the customer, and the labels report on services and access types.

Example: Customer- Access type A- Service Service Access type B- identification ab Message Box Message Box ab Customer PSTN Function: Function: Email Sales A-no Create Send E-mail address company Time Time Time Size Time Date Date Date Time Date Day Day Day Date Weekday Connection time Day An SDR must have space for the information needed for: - identification of non-priced SDRs; - identification of the correct price list; - price marking; - specification of the time for pricing; marking of priced SDRs (signing, i.e. the price list that has set the price); and marking of incorrect SDRs.

An SDR, as explained above, contains an essential amount of information, which is needed to identify correct price list. SDR is loaded with customer information and contains all the data needed.

As explained above, traditional telephony can network is considered to be part of an information service networks containing cooperating service-producing elements and a communications service network containing service connection elements. The latter consists of a signal network and a transport network. The signaling network carries commands to the service connection elements, for example, to establish a connection between two geographical gene in the transport network. This network then transmits it 10 15 20 25 30 35 512 479 23 information to be exchanged between these two modes, as voice, text, image or data.

Services created by this combination of information tion and communication are called information services. Communal cation service network issues call details that are provides information on the geographical distance between lan the two places that are connected and for how long time this connection has lasted. This information is not sufficient for information access service providers; consequently issues the communication service network service detail records (SDR). The purpose of said SDR is to provide it information necessary for the correct debiting of the turnaround and production of information access services. SDR can also provide information to support service management, quality assurance activities and production of statistics and reports on service use one.

A user, i.e. an individual, can participate in of an SDR. However, it is not necessarily essential for an individual to be directly involved in the creation of an SDR. An SDR can be created as a consequence of: that a user makes a telephone call with a colleague; - that a fax in use fax box is retained for an additional period of time. riod; quality assurance activities prior to the introduction of a new information service; or - that a service-producing element reports that no call attempts have been made during the tea 30 minutes.

In the first two cases, a user interacts directly and indirectly with an information access service. A service usage session is produced and an SDR is issued to charge the user. In the latter two cases, SDR is produced for I l I! IIWHN 'H || \ ||| lr Hml iii HH 10 15 20 25 30 35 512 479 24 quality assurance and service management reasons and not for billing. The present invention primarily relates to generation of SDR as a result of a user cooperates with an information access service where the main purpose is to bite the user for using the info service.

An SDR is a collection of tagged data objects that are writes a session for using info access services.

The basic structure of a labeled data object is illustrated in Figure 5. The size and content of SDRs may vary in in accordance with the information access services used and the manner on which they have been used. It must be possible to add to new data objects to SDR because, and when, new info- comet services with different requirements appear. To achieve this, the SDR data structure must be flexible and of which follows the concept of using labeled data taobjekt.

As shown in Figure 5, labeled data objects have three basic components: a label identifier, a length identifier and the actual data value. Label identification describes how the associated data value should be interpreted. The length indicator gives the length of the data value, in the form of a number of octets, without the label identifier and the length of the length indicator itself. For example, if the identification identifier says ‘price to pay’, the association the data value to be interpreted as a sum of money. Since the data value may contain other tagged data objects, created nested structures, much like a set of Chinese askar.

Labeled data objects are placed in sequence, one after the other the other, without any space being inserted between them and without any space being reserved for unused fields. One labeled data object is recognized by the label identifier value associated with it and may occur in any output signal from a service producer element. Consequently, additional, labeled data objects can added to this, e.g. through service pricing systems mêt. 10 15 20 25 30 35 512 479 25 Labeled data objects are coded in accordance with BER according to ASN.1, as specified in the Joint ISOICCITT the set of international standards / recommendations tioner. An information access service provider may take responsibility for that assign tag identifiers to the different data objects ten in SDR.

Linked, tagged data objects are grouped in service smiles. There are four different types of service modules within SDR. The structure of a service module is illustrated in Figure 6.

The service main module contains data objects that are associated with an SDR as a whole. There is always such a and module in SDR.

The network service module contains data objects that are associated related to the service's consumption of network capacity. It can there is one or more network service modules in SDR. Within mo- information regarding several network jumps can be registered.

The service usage module contains data objects such as are associated with the use of an information access service. One service structure module structure is shown in Figure 7. It there may be one or more such modules in the SDR. The in- contains data objects that are present in all service turn modules and data objects specific to one special service.

The service pricing module contains data objects associated with the pricing of an information service. There may be one or more such modules in SDR.

The structure of a service module is shown in greater detail in Figure 8. Each service module has its own set of modules specific labels, i.e. labels that are unique within the importance of that service module. The data objects' service covert identifiers and audit status are mandatory in all service modules. When these data objects are combined with the module-specific markings, the data objects become within the service module is globally unique, i.e. unique even outside for the limits of that service module. To make data objects in a service usage module globally unique, a third-party ww-wwww m 'w | v m “W I H1 v -v 10 15 20 25 30 35 512 479 26 je data object, the service feature code (the Service Feature Code).

An ASN 1 encoder / decoder can be implemented as one state-of-the-art machine executing the BER and having reference tables containing the labeling tifier values for different service modules. The decoding of a SDR begins with the state machine containing the service the module identifier and the audit permit. About this performed correctly, the correct reference table for that service module is loaded and its data values are interpreted on a correct way. This logic applies to everyone else service modules in SDR. In the case of service use modu- the service function code must also be retrieved to set which info access service has produced the data object in the service use module.

The relationship between service modules is illustrated in SDR contains, service-producing elements, when given as an output from one (SHM), or gur 9. a service main module network service modules (NSM) and a, (SUM). When the service price one or more, several, service usage modules the pricing system has produced the price information, SDR also holds a service pricing module (SPM), which is connected to each service usage module (SUM).

A service pricing module is always connected a service usage module. One or more SUM / SPM pairs can be connected to a network service module that forms one NSM / SUM / SPM triplet. To determine the service module structure is part of the design of an information access service.

The relationship between the service modules within an SDR is controlled by two optional data elements, the NSM / SUM correlator and SUM / SPM correlator. No correlators are needed if SDR is dast contains a service module of each type. If it contains holding multiple network service modules requires an NSM / SUM correlator shared between the network service module and the associated user (s) the service usage module / service usage modules_ With regard to the network service module, there is a one-to-one 10 15 20 25 30 35 512 479 27 relationship, or one-to-many relationship, between these module types.

A service pricing module and a service user module shares a SUM / SPM correlator. It is a one- to-one relationship between these module types. The two cor- the value series of the relation types must be unique within the said SDR.

The use of an information access service is called a service usage session. It starts at a given date and one given time, has a limited duration and ends eventually at a different date, sometimes, and another time. During a service usage session occurs one, or a number of, service events. Several info- services can cooperate, either in sequence or in parallel lellt, in time to achieve a more refined service.

Consequently, a service usage session may include events from several information access services, see Figure 10.

Events within the same info access services are grouped into a service module. The chronological order of events occurs maintained in SDR. A service usage session can generate a single SDR - which contains all the services events within a single service or within several effective services. It can also result in several, cup- added SDR, each of which contains events within a single service, or an SDR for each service event, see Figure ll. For example. the VCC service produces an SDR which contains all events, one or more, in a service usage session, while the Broadband service (the Broad Band service) generates an SDR for each event recorded. hits.

Whether a service usage session results in one, or more, SDR or not, is irrelevant to the service the pricing system that handles each SDR as a single separate unit. SDR contains two optional data elements, one session identifier and a sequence number to do it is possible for a finishing system to recreate the chronological order according to which several, linked rm w Mr. W '| \ H! '| a '. 10 15 20 25 30 35 512 479 28 SDR was produced during a service usage session. In- in the said SDR, events from an info com- service in a service usage module. Such a module is specific to an information access service and may include a separate service event or a chronological sequence of linked service events, see Figure 12.

The service pricing system adds data objects base price and individual price at the service price setting module. These data objects may contain the price for an individual service event or the total amount for all service events in the associated service the turning module.

Service-producing elements are part of the information the service network. Customer data can, for an individual customer, be allocated to his home location SPE. The service logic of an info com- service can be executed on an assigned SPE, or distributed race among several collaborating SPEs.

If more than one service-producing element participates in a service usage session and, if more than one SDR is provided as an output signal, they must coordinate the values of the data objects session identifier and sequence number that occurs in the head of the said SDR, see Figure 13, which shows the need of communicating certain information between SPEs.

Info access services can be offered by several sales companies with differences in pricing, payment terms, debiting, etc. Thus, it must be possible to price provide and use of information services according to price lists that are unique to each companies. It must also be possible to provide services suppliers and service users individual tariffs, either in the form of absolute tariffs or a basic tariff with varying discounts and bonuses at a later stage.

The service pricing system is illustrated in Figure 14, showing the interaction between the pricing planner, customer management data, service-specific pricing logic and market / customer-specific price tables in the production of 10 15 20 25 30 35 512 479 29 priced SDRs, as indicated by $ SDRs in Figure 14, from non-priced SDRs.

Some services require tariff information, or pricing information, on request, more or less in real time, on different languages and in different currencies before, during and immediately only after the service has been used. It must be possible for the service provider to be able to instantly change the rates and prices of an information access service. This applies regardless of who provides the service and to whom the service is provided. The supplier may be a communications network operator or a customer of telecommunications cation network operator.

The service pricing system handles pricing of traffic tariffs and service incidents. Periodic fees, such as subscription fees, various discounts and bonuses calculated by the finishing systems_ A service-producing element is supplied by SDR a subscription service with an intermediate storage option, SDR archive, see Figure 15. Due to the large amount of formation produced, only the said SDR is retained in this archive for a limited period of time. Finishing systems can subscribe to SDRs from several information services, or on selected data objects within the SDR from a specific information access service, e.g. only the data objects that are associated with billing. SDRs that do not have any subscriptions are immediately abandoned upon receipt of the subscription the service.

The SDRs that have subscribers are retained in the SDR archive there a specified period. The finishing system can ask the subscription service for information on which they (ef- treatment systems) subscribes at recurring times intervals, or they may be alerted by the subscription service when they have information to gather. The SDR is cleared away from the archive when all subscribers have collected the formation to which they subscribe.

Some information access services may issue an SDR as a the price information, or tariff information. And so on w-wn w | Hnv \ l P lm I w | M ~ | hrs 10 15 20 25 30 35 j_512 A79 30 SDR is also sent to the subscription service and collected by the service pricing system_ When the price, or the tariff, has been calculated and added to SDR, it is returned to the subscription service and is eventually retrieved by the service tea-producing elements that issued the request.

The information in the SDR archive is a common resource available for the finishing systems_Information provided through the subscription service and can be used for different purposes. Some examples are given below. (a) Charging inside and outside a telecommunications operator's organization The information in SDR can be used to produce accounting information and enable one service-producing companies to verify invoices from domestic, as well as from foreign, network providers.

This information can be distributed among the various information services to keep track of the amount of network the capacity that an info access service has consumed. It can further broken down to show the network capacity that an individual service usage session has consumed. When this has been done, it is possible to calculate the network cost and associate it with a specific network operator, an info- com service, or a service usage session_ Figure 16 illustrates the distribution of income, in a debit chain, both inside and outside a telecommunications organisation.

A service-producing company can calculate a production cost to be written on the invoice to the sales companies to provide information services to them.

The production cost is the sum of the network cost and the processing costs of the service-producing company and profit margin, which may vary from a sales to another. In the same way, it can serve the tea-producing company charges customers for sales companies by simply adding sales 10 15 20 25 30 35 512 479 32 such as price, currency and VAT, about that service. This is fast the introduction of new services, or the addition of new ones functions, since only the debit of the specific service systems need to be modified. The rest of the service the production environment is kept intact. in When the total sum for the determined period has been calculated on the basis of each customer, the service information to an invoice printing machine common to all services. This machine suitable quantity discounts and bonuses that include the full the number of different services that a customer subscribes to and issue a single invoice. c) Reports and statistics The information contained in the SDR is valuable access for a telecommunications operator_ Figure 18 vi- sar the way in which information that SDR contains can be used for the production and delivery of reports and statistics. It can be used to obtain knowledge of how the service production environment works, how the information services are used, what revenue they generate nice as well as customer behavior. It can of course also be offered customers in the form of reports.

The information in SDR can be used to produce service-specific revenue reports, sales reports, market reports and customer behavior reports for service the operator, the sales companies and their customers. Pro- the product manager can switch on his / her PC when he / she arrives office in the morning and get fresh information on income generated by his / her product previous day. This information can be analyzed and provided origin of new services, service functions or refinement of existing services.

Customers, sales companies and all others who takes in service production can order information such as obtained from SDR in a number of different ways and in a number different shapes. Ordering can be done via electronic mail, IHM \ * IH || Mwl l 'IH H IH I IH! \ lll! 10 15 20 25 30 35 512 479 33 fax, telephone, Internet or regular mail, either as a one-time delivery or as a subscription. Information the content can be customized in a number of different ways for to suit a specific customer's needs, e.g. through information type of information service to which it relates, customer, company and / or the time interval during which it was produced or will be produced.

Delivery can be made by e-mail, fax, telephone, In- ternet, EDI (electronic data interchange) or regular mail, which contains CD-ROM or paper. The information delivered can be in a final state or be prepared for further refinement by the customer. In the se- In this case, the information may be contained in a Microsoft Word document, an Excel spreadsheet or in the PowerPoint images that can be printed on transparencies. d) Quality assurance SDR can be generated for quality assurance purposes. Ex- For example, it is important that before selling a new one service function verify that it has been priced correctly and that the invoice looks real. However, it is the same important not to place this invoice in an envelope and post it. e) Service management SDR can be generated for service management purposes, for example to obtain an early indication of suspects attempted fraud, so-called "churning", abnormal traffic loads, error rates or technical errors.

To determine the cost of production of a service usage session must information about consumed communication network capacity is obtained. This includes all network providers that have set their networks and transport networks available to the service. Figure 19 shows how an SDR can contain information from one number of different sources, all of which are needed to 10 15 20 25 30 35 512 479 34 calculate the cost of service delivery, signaling and communication.

In the example illustrated in Figure 19, subscribe a Swedish company, with placements in Europe, on one virtual private network service - VPN. The sites share a common sam private number plan (PNP) and the service logic executes on a service-producing element in Sweden. Signal the exchange and exchange of information takes place within domestic and networks of foreign network providers via service connection element (SSE).

When A calls B at the location in Spain, it is signaled this to the said SPE in Sweden. The service finds out that A and B are connected to the same VPN and establish a voice channel between A and B in the Spanish operator's network. Close puts on, an SDR is produced at the said SPE in Sweden as provides details on consumed signaling capacity between Spain and Sweden, via France and Germany, and communication capacity used in the Spanish operation törens net.

The invoices from the network providers may cover the talk about the amount of network capacity consumed by different municipal services. SDRs must provide sufficient information to enable the service provider to calculate the amount of capacity a specific info service have consumed.

The structure of SDR and data objects included therein will now be described. It will be noted that some data objects are mandatory while others are optional. SDR generated as a consequence of a user interacting with an information access service, as already explained. Head- the purpose of the SDR is to charge the user for the ningen. SDRs generated as a consequence of service management, quality assurance activities or other activities are not described here.

Data objects in the service main module are added by it the service-producing element. All data objects, obli- i j 'H IH \ * HH ll * * HW 10 15 20 25 30 35 512 479 35 gatoric or optional, there is only one gang within the module. The following data objects belong to this module.

Service module identifier - Identifies the service module vudmodulen. [Compulsory] Audit permission - the version of the data type ASN.l which defines the service master module. A module in a given version may not be changed. [Compulsory] SDR Type - Identifies the type of SDR. The specifics the values are: - Debit; - Quality assurance; - Service management; - Statistics; - Accounting, within a telecommunications operator own organization; and Accounting, other telecommunications operators.

If a post has a qualifying period and uses the applicant hangs up after receiving information on the an, the user will not be charged, but an SDR for Accounting will be issued said the network provider get paid. [Compulsory] Session Identifier - Can be used to identify Multiple SDRs associated with a session. About SDR within a session is produced by different service producers element, the session identifier must be communicated between lan the service-producing elements so that it has the same [Optional] Sequence number - Can be used to indicate the value in all SDRs. frequency, within a session, according to which several connected SDR has been produced. The sequence number may be useful when a service usage session results in multiple SDR is provided as an output signal, or if a service usage extends over a long period of time, such as let with leased lines. About SDR, certified by various service-producing elements, within a session, produced the number is communicated between the service producers the elements so that they form an unbroken sequence. [OptionalL 10 15 20 25 30 35 512 479 36 SDR Identifier - Uniquely identifies an SDR as has been produced by a specific service-producing element ment. This identifier can be used to distinguish duplicates. The SDR identifier can be represented as one 32-bit integer that is incremented once for each SDR produced. This gives a sequence of 4,294,967,295 unique identifier before repeating the sequence. [Compulsory] Creation Date - Specifies the date at which the SDR was produced. [Compulsory] Arrival Time - Specifies the time when the SDR was produced. [Compulsory] Liability tracking - Can be used for a system that participates in service production to indicate that it has taken responsibility for SDR, it may consequently contain one sequence of system identifiers and time markers.

The liability track can be used as follows: - when one service-producing elements, SDR delivers to service the pricing system and the latter has secured it, the service pricing system can indicate this by add a responsibility label and the service provider the element can clear the SDR from its storage.

[Compulsory] Action Indicator - Indicates the type of action the pricing system has been requested to perform. The specific values are: SDRs will be priced and forwarded to one finishing system; - SDR is a request for price information, or tax information, and shall be returned to the the tea-producing element; - SDR is for quality assurance and should not priced; - SDR is for service management and should not priced. [Compulsory] Data objects in the network service module are added by it the service-producing element. Data objects, mandatory HN \ HH | \ Hu- IHH H | HHH - | H n Hun H m » 'HH [III HH! III HH \ [IIHH HHHI w w * Hmu 'f fl H 10 15 20 25 30 35 512 479 37 or optional, there may be more than one gang within the module, as indicated. The following data objects belong to this dul.

Service module identifier - Identifies the network service the module. [Compulsory] Audit Permit - The version of the data type of pen ASN.l which defines the network service module. A module in one given version may not be changed. [Compulsory] NSM / SUM correlator - If SDR contains more than one network service module, each module must have an identifier value which is unique within said SDR. The same value must occur in all, one or more, service use modules that are associated with this network service module. [Optional] The following set of data objects can occur several times within the module. If they do, the whole thing is repeated the setting as an unbroken sequence.

Network Provider - Identifies the network provider that has made its network available to the services. [Compulsory risk] _ Network type - The network type that has been used, e.g. a sign networks, IP networks or a voice channel. [Compulsory] Billing Start Date - Specifies the date at which the billing period starts. [Compulsory] Charge start time - Specifies the time the point on the day at which the billing period starts.

[Compulsory] Chargeable Duration - Specifies the time period the one for which a fee must be calculated. [Compulsory] Consumed capacity - [Optional] SSE Identifier - Identifies unique service connection element. [Optional] The following data objects may appear in the static data of the TT information produced by a telecommunications network operator's VPN service.

Post Type - 10 15 20 25 30 35 512 479 38 Mail Size - Cause of output signal - Zip code - Call identification number - Postal Sequence Number - Error code - Call Status - Forced disconnection - Call Attempt Indicator - Call Attendance - Reason code - Location code - Signaling type - A subscriber type - Length indicator A-subscriber - not present in TT- info from MSE A subscriber number - Category A - A-number type - A subscriber number plan - B Subscriber Type - Length indicator B-subscriber - not present in TT- info from MSE B subscriber number - Category B (EOS information) B-number type - B Subscriber Number Plan - Billing Case - Billed party - Source of charge - Telecommunication Services Code - Coating type - Indicator type - Procedure Type - Results of Subscriber Service Procedure - Date of debit start - Time to start charging 24h - . \ lll m 10 15 20 25 30 35 512 479 39 Chargeable duration / time - Time from registered occupancy to debit start - Number of meter pulses - Number of user-to-user messages in the voice control messages - Number of user-to-user messages below call - Direct access data indicator - Data Access for Direct Access - Data calculator for direct access - Length indicator X-subscriber - not present in TT- info from MSE X subscriber number - not found in TT-info from MSE Length indicator card number - not used in TT- info from MSE Card Number - Conference call indicator - Presentation indicator (CLIR) - Source code - Destination Code - Station identity - Outbound road - Incoming road - Carrier Access Code - Command date - not present in TT-info from MSE Command time - not applicable in TT-info from MSE Command name - not found in TT-info from MSE The following data objects can be collected from a CDR member sharing.

CDR message type - CDR record size - Station identifier AX.Id - File Identifier - 512 479 40 (Sub-) File number - Postal Sequence Number - Post Type - Call identification number - Call Status - Cause of output signal - Part Postcode - A-number - Category A - A-number type - A-number plan indicator - A subscriber type - B-number - B-number type - B-number plan indicator - C-number - Dialed numbers for IN service - Postal sequence number IS / TT - VPN call information - Date of debit start - Debit start time - Chargeable duration - Break time - Error Code (EOS) " Card Number - Billing Source - Coating type TOS - Indicator code for telecommunication service TSC - CI call indicator - Procedure Result - Subscriber service indicator SSI / TOI - Subscriber service indicator SSP / TOP - Conference call indicator - Midnight Line Service - Web Conversion Options - User-to-user messages during call control (UUSl) - .Jm ¿Jï 10 15 20 25 30 35 512 479 41 User-to-user messages below (UUS2-3) - ISDN Subscriber Service Indicator l 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 - Access type - VPN call type - IN call indicator - Function saving x 4 - IS-TT Duplicate Sequence Number - MRS status - Price 1 - Price 2 - Price 3 - Price 4 - Call type l for price 1 - Call type 2 for price 2 Tax Period Identifier l - Tax Period Identifier 2 - Multiple tax periods l - Multiple tax periods 2 - Price Table Identifier - VAT identifier 1 - VAT identifier 2 - Billing Service Identifier - the conversation 10 15 20 25 30 35 512 479 42 Billing Purpose - Valuation Status - Repair Status - Service type indicator - Charged subscriber number - Number plan indicator for charged subscriber - Call Session Indicator - A service usage module is specific to an info- com service in the sense that it contains data objects such as occurs in all service usage modules and data objects that are linked to a specific info service.

Data objects that occur in all service users modules are added by the service-producing element meant. All data objects, mandatory or optional, occurs only once in the module. The following data objects belongs to the service usage module_ Service module identifier - identifies the service module the turning module. [Compulsory] Audit Permit - The version of the data type of type ASN.l which is common to all service use modalities you're smiling. A module in a given version must not be changed. [Ob- ligatory] Service Feature Code - Identifies this specific info service. [Compulsory] Service Audit Permit - The data type version of type ASN.l specific to this service module. One service module in a given version may not be changed. [Obligatory toric] User Identifier - Identifies the user of the information access service. the user may be identical to the provider, as is the case when a service provider changes tariffs or updating information. If an SDR contains both a user identifier and a call number, or A-subscriber number, the user identifier dominates over all of these. [Optional] in) 5 lO 15 20 25 30 35 512 479 43 Vendor Identifier - Identifies info com- the service provider. [Compulsory] Sales Company - Identifies sales companies taken to which the customer belongs. The specific values are for Te- lia: - Telia MegaCom; - Telia PubliCom; - Telia-Företag; - Telia Nära; - Telia A / S (Denmark); - Telia Norge AS; - Telia Poland; - Telia Estonia; - Telivo Oy (Finland); - Netia (Poland); - North West GSM (St. Petersburg); - Estonian Telephone Company; - Latvian Mobile Telephone; - Telemedia AB (Lithuania). [Compulsory] Paid participant - Can be used to indicate someone other than the user, the call number or the A- the subscriber number must be charged. An example is a received call or BA call. [Optional] Dialed number - The dialed number is used for the voice connection, i.e. beaten figures for information the service. [Compulsory] NSM / SUM correlator - If SDR contains more than one network service module, each such module must have an identification unique value within said SDR. The same value shall occur in these (and all other) service use modalities modules associated with the network service module. [Optional] SUM / SPM correlator - If SDR contains more than one service use module, each such module must have one identifier value as unique within SDR. The same value shall appear in the service module associated with it service usage module. [Optional] 10 15 20 25 30 35 512 479 44 Data objects specific to VCC service users module is added by the service-producing element meant. Data objects, mandatory or optional, can be recommend several times within the module, as indicated. Foal- data objects belong to this module.

Call number - The calling party's phone number.

[Compulsory] Dial number - The call center access number rum, i.e. the number dialed by the called party to reach the service. [Compulsory] Service carrier - The service, or call type, that carries the call to the call center. The specific values are for Telia: - Telia Free Call; - Telia Freephone; - Telia Company Number; - Telia Business Subscriptions; - Telia Split (l, 2,3). [Compulsory] Customer Management Code - Values for this data object can defined in a future version of the VCC service.

When the calling party has reached a destination number, this party may again be placed in a queue. Om sà In this case, the following data object shall be repeated as an unused sequence and in chronological order within the module. Each data sequence elements present a service event.

Destination number - Phone of the responding party number. [Compulsory] Event code - The specific values are: - The calling party was placed in a queue and placed On; - The calling party was placed in a queue and they a destination number; - The calling party reached a destination number immediately. [Compulsory] i'll l l ll ll | I ll »l lll llllllll lll »I fi ilil "Objectives [ÜVIM., 10 15 20 25 30 35 512 479 45 Charge Start Date-1 - Specifies the date inches on which the calling party was placed in a queue. [Choice- free] Charge Start Time-1 - Specifies the time the point on the day at which the calling party places the des i queue. [Optional] Chargeable Duration-1 - Specifies the time period period spent by the calling party in the queue. [Choice- free] Charge Start Date-2 - Specifies the date inches on which the calling party reached a destination [Optional] Charge Start Time-2 - Specifies it time of day at which the calling party reached a destination number. [Optional] Chargeable Duration-1 - Specifies the time period period to which the calling party has been connected the destination number. [Optional] Data objects specific to VPN service users module is added by the service-producing element meant. Data objects, mandatory or optional, can be recommend several times within the module, as indicated. Foal- data objects belong to this module.

Private number A-subscriber - If the A-subscriber has one private number, this number is stored. [Optional] General number A-subscriber - If the A-subscriber has one public number, this number is stored. [Optional] Private number B-subscriber - About the B-subscriber's private numbers are used to establish the call, this is stored number. [Optional] Public number B-subscriber - About the B-subscriber's audience numbers are used to establish the call, this is stored number. [Optional] First destination number - If a routing function or redirect function is used, the destination tion number here. [Optional] 10 15 20 25 30 35 512 479 46 Other destination numbers - If the call divert function is used on a destination number that is given as an output signal from a call forwarding function, this destination number is written here. [Optional] Third destination number - About call divert function is used on a destination number that is received as an output signal from a call forwarding function, this destination number is written here. [Optional] Cost Allocation Code (CDC) - The CDC that is the shared A-subscriber, or his PABX, is written here. In the fall with GVNS and call center access, this data jekt value with zeros. [Optional] Extra CDC l - The CDC assigned to the subscriber, or PABX, is written by the “First Destination Number” here. [Optional] Extra CDC 2 - The CDC assigned to the user, or PABX, of the "Second destination number", is written here. [Optional] Extra CDC 3 - -Deb CDC assigned to the user, or PABX, of the "Third destination number", is written here [Optional] Account Number - [Optional] Access type - The specific values are: - Immediately; - GVNS; - Connected; - Remote; - Call center; - Remote network. [Compulsory] Source Line Identity (OLID) - The OLID added in the case of direct access. [Optional] End Line Identity (TLID) - The TLID added in the case of direct termination or Break-out. [Optional] Dialed number - The dialed number used for call connection, i.e. dialed numbers for VPN the service. [Compulsory] Call type - The specific values are: n * [H w * | w ' lr * MI Hllww] I lHl HUIIIIIII llll * llllllllll 'll IM' 10 15 20 25 30 35 512 479 47 - Call terminated to On-net; - Calls terminated to Off-net; - Call terminated to virtual On-net. free] Follow-up Counter - Starts counting from the first subsequent call in a remote access call or a network remote access call, i.e. from the other destination the connection number to which the caller is connected. When it For follow-up calls, one SDR is generated for each Call. The SDR includes ID and linked ID. The pre- sta SDR has no associated ID. The subsequent SDRs have [Optional] Event Tracking - Each time an event is executed the first ID as the linked ID. in call handling, the specific value for it is added the event. An event that is executed multiple times comes to occur several times with its value. The specifics the values are: - Forced On-net; - Privilege representation; - Directly terminating flooding; - Break-Out; - Call divert when busy; - Call redirection in case of no answer; - Time-dependent routing; - Call control (which belongs to the original number list); - Follow me; - Source-dependent routing; Call distribution; Leased virtual channels - no overcurrent- ning; - Leased virtual channels - flooding; - Customer management - PIN; - Customer management - Time-dependent routing; - Customer Management - Advanced, Forced On-net; - Customer management - Follow-me, activate, own fOn; 10 15 20 25 30 35 512 479 48 - Customer management - Follow-me, activate, other lefon; - Customer management - Follow-me, deactivate, own lefon; - Customer management - Follow-me, deactivate, other phone; - Customer management - language code; - Flooding; - Differentiated Call Control [Optional] These event values must be presented in chronological order order with the most recent event first.

Type of redirection indicator - The specific values are: - General error; - General blocking; - Blocking within VPN; - Blocking outside VPN; - Error within VPN; - Error outside VPN. [Optional] In cases where direct termination overflow has used, this item shows if redirection occurred on due to blocking or due to error.

Authorization code - In case of remote access and network remote access, the user identifies himself by enter their authorization code and PIN. This data object contains only the authorization code and not the PIN. [Choice- free] Business Identifier - An identifier that is assigned to the subscribing company. This is corporate the identifier of the calling party, except in cases GVNS and call center access, as it is corporate identity the party calling the party. [Optional] Authorization code version 2 - [Optional] IN call indicator - [Optional] Non-dialable private CLI - [Optional] Non-dialable public CLI - [Optional] (call line identification- tet) lO 15 20 25 30 35 512 479 49 Personal telephone number - [OptionalL When making remote access calls, or network remote access calls, Telia's VPN service contains data objects Authorization code the A-number to be debited, i.e. the home number of the calling party. (The caller the partner enters his public telephone number as an auto- risk code). The data object Public number A subscriber in- contains the A-number to be used for price calculation ning, i.e. the number of the telephone outside the VPN that has used to conduct the remote access call.

Data objects specific to the signaled ATM the service usage module is added by the service provider cerande element. Data objects, mandatory or optional free, there may be several times within the module, such as dictated. The following data objects belong to this module.

Source number - (format: El64 string). [Compulsory] End number - (format: El64 string). [Compulsory] Billing Start Date - Specifies the date on which the billing duration starts. [Mandatory] Charge start time - Specifies it time of day at which the billing duration starts. [Compulsory] Chargeable Duration - Specifies the time period for which fee is to be calculated. [Compulsory] Maximum allocated bandwidth - [Required] Average Allocated Bandwidth - [Required] Service class - [Mandatory] Number of cells / frames transferred - [Required] Data objects that are specific to the usage module for broadband services is added by the service provider edge element. Data objects, mandatory or optional, may occur several times within the module, as indicated rats. The following data objects belong to this module.

ATM Service Identifier - Identifies a service within the ATM service. [Compulsory] 10 15 20 25 30 35 512 479 50 Billing Start Date - Specifies the date on which the charge duration starts [Mandatory] Charge start time - Specifies it time of day at which the billing duration starts. [Compulsory] Chargeable Duration - Specifies the time period for which fee is to be calculated. [Compulsory] Session Identifier - Can be used by service price the settling system and a finishing system to recognize several events that occur during a session Zion. [Compulsory] Event Type - Identifies the type that caused it for example login, [Compulsory] Event Parameters - A set of parameters such as output of this SDR, logout or changing website online. are associated with the event, e.g. http protocol, vi- deoconference, website address, or TCP / IP addresses. [Compulsory] information type, This service issues an SDR each time a service event occurs. Consequently, service identification can be used to associate events with a specific session. This is in contrast to the VCC service where events are given as output signals in the same SDR.

Data objects in the service pricing module are added of the service pricing system. Data object, mandatory or optional, there may be several threads within the len, as indicated. The following data objects belong to this module.

Service module identifier - Identifies the service price setting module. [Compulsory] Audit Permit - The version of the data type of type ASN.l which defines the service pricing module_ A model dul in a given version may not be changed. [Compulsory] SUM / SPM correlator. If the SDR contains more than a service use module, each such module must have one identifier value that is unique within said SDR. Same náåi] : J 10 l5 20 25 30 35 512 479 51 value shall appear in the network service module that is with the service usage module. [Optional] Service Pricing Identifier - Identifies it service pricing system that calculated the price for it associated service use module or as a provider contains the requested price information or tariff information tion. [Optional] Pricing Date - The date the price information is was counted. [Compulsory] Pricing time - The time of day then pricing information was calculated. [Compulsory] Currency - The currency that has been used to calculate the price information. [Compulsory] VAT - The VAT level to be applied to data project base price and individual price. [Compulsory] A service usage module can contain several parts. The price for each event can either be added to a total sum, or presented as single sums.

If the latter is the case, the following data objects must be pass as an unbroken sequence within the module. The order within that sequence shall correspond to the sequence of events in the associated service use module, as indicated by SUM / SPM correlator. [Compulsory] Price type - Indicates whether the price information has been nats on the basis of per call, per function, per time sheet, or a combination of these. [Compulsory] Basic price - The price for using the service or service events in the specified currency, excluding VAT and other discounts. [Mandatory] Individual price - The basic price in the specified the currency with applied discounts, but excluding VAT. The- take is the price the user has to pay. A discount can is given if the user has an individual pricing agreement with the sales company, or due to the service used during a low-tax period. [Optional] 10 15 20 25 30 35 512 479 52 Price Table Identifier - Identifies the price table bell used to calculate price information. [Obli- gatorisk] Audit Permit - The revision of the price table used to calculate the price information. A pristine bell in a given version may not be changed. [Compulsory] Invoice Information - Indicates a follow-up action system what this should write on the bill. What which is actually written may depend on the service, the provider and the user. [Optional] Status indicator - Indicates whether SDR has been priced smiles the reason why it can not be priced. The specific values are: - The price has been calculated correctly; - Cannot locate the service function code; - Cannot locate the functional audit condition; - Can not locate the service user; - Can not locate the sales company; - Can not locate the price table; - Can not price due to technical error. [Obli- gatorisk] To help with the understanding of the present invention is presented below a glossary of the terms that used in this patent specification.

ASN.l: Abstract Syntax Notation One - is a syntax that specifies how data types and their associated the values are to be represented. What other mo- dernt, common programming language at any time can serve the same purpose, e.g. Ada or C. ASN.l developed in the early 1980s and defined now in CCITT Recommendation X.208 and ISO standard 8824 as associated with the OSI model presentation layer.

ATM: Asynchronous Transfer Mode.

Ax: Automatic Station.

[H11 H1 !! 10 15 20 25 30 35 BER: CAMS: CDR: CSN: 512 479 53 Basic Encoding Rules Rules) - BER is a set of rules that specify how the data types according to ASN.l and their associated values shall be coded to a transfer ring syntax, i.e. a sequence of octets. The binary representation of these octet sequences is called a transmission code and is independent of the programming language and operating system that used. The transfer code is used when data type and their associated values are linked between lan open systems, i.e. systems that conforms to the OSI model. BER is defined in CCITT recommendation X.209 and the ISO standard 8825.

System for managing customer accounts (Customer Account Management System) - According to the the invention produces CAMS invoices which to be transferred to customers, CAMS creates invoices for monthly or quarterly delivery, periodic charges can be priced in CAMS which can also produce one-off invoices and credit receipts.

Call Detail Record - CDR is a data structure that describes how a connection sub-networks have been used, e.g. in the form of and the geographical distance between connection points. This information is however, not sufficient to charge for info access services.

Connectivity Services Net- work) - CSN provides three types of services ter: a signaling service, for example to stop users of information access services; - a voice transmission service, text, image and data between users of info- local services; and 10 15 20 25 30 35 FACTS: FTP: IN: Info: ISN: MPS: NSM: PNP: SCP: SDP: SDR: SDR archive: 479 54 512 - a service for announcing / playing back distributions, this service may include other more of output signals from intelligent peripherals devices.

A known and existing invoicing system that used in the billing chain to create basic invoice data on priced items.

(File Transfer Protocol) A file transfer protocol protocol.

Intelligent Network.

Info access services are produced in information the service network, which mainly consists of the loss points (SDP), service control points (SCP) and intelligent peripherals (IP). According to this meaning provides connectivity the network infrastructure for the services.

Information Services Network Network) - uses the switching service network for to provide information access services.

When a customer makes a phone call over it fixed network, one or more ter, e.g. TT records. Files with TT records collected using an IS-TT system. Total the records are then sent to MPS for validation.

Network Service Module.

Private Numbering Plan.

Service Control Point.

Service Data Point.

Service Detail Record - SDR is a data structure that describes how an info- com service has been used. Such a use- cases may involve only one service, or one sequence of collaborative services. ASN.1 and BER applied to specify and encode / decode this data structure.

Information in SDR is stored in a relational database called SDR archives. Informatio- lO l5 20 25 30 35 SHM: SPE: SPM: SPS: 512 479 55 can be recovered using post-processing systems, e.g. to produce invoices, statistics and reports. The information is located during different time periods on different types of storage media with varying capacities and arrival time. Pricing information can be found in SDR when it is entered in the SDR archive or added later, by means of post-treatment systems.

Service Header Module.

Service Producing Elements (Service Producing Element) - a service-producing element make part of the information service network. The the service-producing element can issue a SDR whenever a service event occurs, or wait until a service user session has been completed. The working method depends on the specific info access service.

Service Pricing Module dule).

Service Pricing System stem). The service pricing system provided maintains valuation and pricing information on request and in real time, for information services. It also performs when SDRs are given as nal from the service-producing element, pricing of SDRs. Service pricing system met contains price and valuation tables for various information services, sales companies and customers. It also has the logic required for to calculate the correct price for a service usage session, which consists of a, or many, collaborative services, which are provided by any sales company to any customer; this includes that apply the right currency, VAT, together with various discounts and bonuses. 10 15 20 25 30 35 512 479 56 SSE: Service Switching Student ment).

SUM: Service Usage Module.

TC: Transfer Code - Transfer Code it is the binary value of the octet string produced when BER is applied to a data in ASN.1 representation. Transmission syntax (trans- syntax) is another name for transmission code.

TT record: Record for call measurement (Toll Ticketing record).

VCC: Virtual Call Center.

VPN: Virtual Private Network.

Within the meaning of the present invention, such as described here, the following list of definitions applies.

Debit: To request and charge for the use of an information access service.

Fee: The fee determined and collected by a service telecommunications provider from its customers for the use of an info service.

Customer: A customer can be the user and / or supplier the operator of an information access service.

Price: A sum of money regardless of time. The price is calculated as the product of a given tariff and the bitter time.

Taxi: A sum of money as a function of time.

SDR: Data in ASN.1 representation describing a speci- specific service usage session_ Service event: An event that occurs within a specific information access service.

Service usage: A service usage session that solved by a human, or an information service.

Service usage module: Data in ASN.1 representation describing one or more service events. 5 Service usage session; Tariff: 512 479 57 May consist of one or more service events that occur within a single separate information service, or several collaborators information services.

A list of prices or tariffs.

Claims (1)

10 15 20 25 30 35 512 479 53 'PATENT REQUIREMENTS A telecommunication charging system for use with a telecommunication system, comprising: - an information service network containing a plurality of service producing elements; and - a communication service network comprising: - a plurality of service switching elements; - a signaling network; and - a transport network; wherein the telecommunication system is arranged to provide information access services to customers and wherein the billing system is arranged to provide flexible pricing and charging for the use of info access services, characterized in that the charging system comprises handling means for receiving SDR generated by the service producing elements and transmission said SDR to a service pricing planner; that the SDR includes service usage modules; that the service pricing planner is arranged to associate a service use module with a price list suitable for it; that a pricing system is provided for calculating a price associated with a service use module and entering the price in a service pricing module associated with said service use module; that said pricing planner means, after entering a price in a service pricing module, is arranged to return a priced SDR to the handling means; and that the handling means is arranged to transfer priced SDRs to an SDR archive means arranged to store said priced SDRs until they are transferred to a post-processing system. mx 10 15 20 25 30 35 512 479 5 * 7 Telecommunication charging system according to claim 1, characterized in that a service usage session generates one or more SDRs. Telecommunication charging system according to one of the preceding claims, characterized in that service pricing modules are added to SDR only after an SDR has been priced. 4. A telecommunications billing system according to any one of the preceding claims, characterized in that the size and content of an SDR varies in accordance with the information access service to which it relates. Telecommunication charging system according to any one of the preceding claims, characterized in that each SDR is a collection of labeled data objects describing a service usage session. Telecommunication billing system according to claim 5, characterized in that marked data objects in an SDR are coded by means of BER for ASN.1. Telecommunication charging system according to claim 5 or 6, characterized in that linked, marked data objects in an SDR are grouped into service modules. Telecommunication charging system according to claim 7, characterized in that a specific set of connected, labeled data objects in an SDR is grouped into one of the following four service module types: - a service master module, which contains labeled data objects associated with an SDR as a whole; - a network service module, which contains labeled data objects relating to the consumption of network capacity for a specific service usage session; - a service use module, which contains labeled data objects relating to service use; and - a service pricing module, which contains labeled data objects relating to the pricing of an infocom service. Telecommunication charging system according to claim 8, characterized in that an SDR contains: one, or more, network service modules; and - one, or more, service usage modules. A telecommunication charging system according to which an SDR contains a session identifier and a sequence number according to claims 5-9, characterized by enabling a post-processing system to restore a chronological order according to which the SDR was produced during a service use case. ll. Telecommunication charging system according to which an SDR contains at least the following marked data objects: got claims 5-10, characterized by - a customer identity; - an identity of a sales company; and - an identity for a service to which the SDR relates; and that an SDR may contain one or more of the following labeled data objects: - an access type; - a time; - a date; - a user identity; - a connection identity; - an operator; - a service provider; - a customer price; and - a market price. Telecommunication charging system according to any one of claims 8-11, characterized in that relationships between service modules within an SDR are controlled by data objects called NSM / SUM correlators and SUM / SPM correlators, that these data objects have unique values within an SDR. and Telecommunication charging system according to any one of the preceding claims, characterized in that the charging system includes one, or more, price lists; and that the pricing system is arranged to implement price list definitions, identify price lists to 10 15 20 25 30 35 512 479 to which an SDR is linked and thereby produce priced SDRs. A telecommunications billing system according to claim 13, characterized in that said pricing scheduler means includes the pricing system and is arranged to receive SDRs, analyze SDRs and identify price lists suitable for an SDRs. A telecommunication charging system according to claim 14, characterized in that said pricing scheduling means is service dependent; and that everything that is unique in terms of service, customer or market is included in price lists. A telecommunications billing system according to claim 14 or 15, the comet service has a unique pricing scheduler which is characterized in that each info is associated with it. A telecommunication charging system according to any one of the preceding claims, characterized in that said pricing scheduler means is arranged to assemble a plurality of SDRs before said SDRs are priced. Telecommunication charging system according to any one of claims 14-16, characterized in that said pricing planner means is arranged to price individual SDRs. Telecommunication charging system according to one of the preceding claims, characterized in that customers are treated for pricing purposes as individual customers or as members of a customer group. Telecommunication charging system according to one of Claims 13 to 19, characterized in that all price lists are based on a basic price list. Telecommunication charging system according to one of Claims 16 to 16, characterized in that price lists are of one of the following types: - a basic price list, which is independent of the customer and the time of use of an information access service; 10 15 20 25 30 35 512 479 ei - a customer group price list, which is applicable to a customer group and - a customer-unique price list, which is applicable to an individual customer. Telecommunication charging system according to claim 21, characterized in that price lists are either lists of prices or algorithms / functions for calculating prices. 23. Telecommunication billing system according to any one of the preceding claims, characterized in that SDR can be generated independently of any action performed by a customer. Telecommunication charging system according to any one of claims 2-23, characterized in that the costs of a service use session are shared between different customers. Telecommunication charging system according to any one of the preceding claims, characterized in that the charging system includes error handling means which are arranged to process incorrect SDRs. Telecommunication charging system according to one of the preceding claims, characterized in that the charging system is arranged to operate with information access services with several functions. A telecommunication charging system according to any one of the preceding claims, characterized in that the information service network is an IN with a server. 28. A telecommunication billing system according to any one of the preceding claims, characterized in that the means are arranged for labeling an SDR as incorrect if it is not possible to identify a price list to which an SDR is connected. A method for pricing the use of information access services in a flexible manner in a telecommunication charging system comprising: an information service network, comprising a plurality of service producing elements; and a communication service network, which comprises a plurality of service switching elements, a signaling network and a transport network, the telecommunication network being arranged to provide information access services to customers, and characterized by the steps: - that each service-producing element (SPE) generates SDR; - collecting said SDR to a handling means, said SDR including a service usage module; - associating each service usage module with a price list; - to determine a price to be associated with each service use module and to add said price to the SDR, which contains said service use module, in the form of a service pricing module; - to return priced SDRs to a handler; and - transferring priced SDRs to an SDR archiving body and storing said priced SDRs therein until they are collected by a post-processing system. A method according to claim 29, characterized in that the finishing system is an invoicing system. A method according to claim 29 or 30, characterized by a service usage session, which generates one or more SDRs. A method according to any one of claims 29-3l, 1 <äI1- n e t e c k n a t a V to add service pricing modules to SDR only after an SDR has been priced. 33. Procedure according to any one of claims 29-32, characterized in that the size and content of an SDR varies in accordance with an information access service to which it belongs. 34. A method according to any one of claims 29-33, wherein each SDR is a collection of labeled data objects describing a service usage session. 10 15 20 25 30 35 512 479 If and that an SDR contains one, or more, of the following labeled data objects: - an access type; - a time; - a date; - a user identity; - a connection identity; - an operator; - a service provider; - a customer price; and - a market price. A method according to any one of claims 36-40, wherein: an SDR includes data objects called NSM / SUM correlators and SUM / SPM correlators which control relationships between service modules in said SDR. ; and that the values of these data objects are unique within an SDR. A method according to any one of claims 29-41, characterized in that the billing system includes one or more price lists; and that the billing system is arranged to implement price list definitions, identify price lists to which an SDR is connected and thereby produce priced SDRs. A method according to claim 42, characterized in that a pricing planner is arranged to receive SDRs, analyze SDRs and identify price lists suitable for an SDRs. 44. A method according to any one of claims 29-43, characterized in that a plurality of SDRs are assembled before they are priced. 45. Procedure according to any one of claims 42-44, characterized by basing all price lists on a basic price list. 46. A method according to claim 45, characterized in that the price lists are of one of the following types: 10 15 20 25 30 35 512 479 66 - a basic price list, which is independent of the customer and time of use of service; a customer group price list, which is applicable to a customer group; and - a customer-unique price list, which is applicable to an individual customer. 47. A method according to claim 46, characterized in that price lists are either lists of prices or algorithms / functions for calculating prices. 48. Telecommunication systems, characterized in that said telecommunication system includes a charging system, according to any of claims 1-28, or that said telecommunication system is arranged to price telecommunication services and network use by means of the method according to any one of claims 29-47. 49. A telecommunication system according to claim 48, characterized in that the post-processing system is an invoicing system. A telecommunication system according to claim 48 or that the SDR is moved from the service-producing element to the pricing scheduler 49, to the billing system. A telecommunications system according to any one of the following functions: characterized in that the SDR can be used for - debiting, both within and outside a telecommunications operator's own organization; - consolidated debit; - production of reports and statistics; - quality assurance; and - service management, which includes fraud identification, churning, abnormal traffic congestion, error rates and technical errors. 52. A telecommunication system according to any one of claims 48-51, does it know that the post-processing system 10 15 20 25 30 512 479 é? stem, which requires access to information contained in SDR, subscribes to the said handling agency. 53. A telecommunication system according to any one of claims 48-52, characterized in that the system has a single invoice printing function. 54. A telecommunications system according to any one of claims 48-53, characterized in that said pricing planning body handles pricing of traffic tariffs and service events, and that pricing linked to periodic charges, subscription fees and discounts is handled by post-processing systems. 55. Telecommunication systems according to any one of claims 48-54, characterized in that each post-processing system subscribes to SDR from one or more info-com services and / or to selected data objects from within an SDR. 56. Telecommunication systems according to any one of claims 48-55, characterized in that the post-processing systems collect SDRs, at predetermined intervals from an SDR archive, and / or in that the post-processing systems are alerted when SDRs are available for collection in a SDR archive. 57. Telecommunication systems according to any one of claims 48-56, characterized in that at least certain information service producing elements issue SDRs as a request for pricing information, which SDRs are sent to pricing planning bodies, priced and returned to said service producing elements. 58. Telecommunication system according to any one of claims 52-57, characterized in that SDR is abandoned without a subscribing finishing unit while SDR with a subscribing finishing unit is retained for a period of time in an SDR archive. f 1 få! IW || \ | \ “I