ITMI20060125A1 - CONFIGURABLE CHARGE SYSTEM FOR A TELECOMMUNICATIONS SERVICE PROVIDER - Google Patents

Description

DESCRIPTION

STATE OF THE TECHNIQUE

1. TECHNICAL SECTOR

The present invention relates to an extension of a billing system to facilitate the configuration of new product offers and billing rates associated with the provision of telecommunications products and services. The present invention provides a billing framework for configuring rates and calculating the charges associated with internal event rates in order to provide billing data to the billing system for generating customer invoices.

2. STATE INFORMATION OF THE TECHNIQUE

Generating customer invoices for telecommunications services is a complicated process. Telecom service providers typically provide more services, and add new products and services at an ever-increasing rate. Each service typically has its own peculiarities and problems in terms of calculating service charges. A further complication of the billing process is the fact that each core product or service typically has multiple variations. For example, a basic product or service may have multiple price lists depending on the customer's monthly access usage, or based on bandwidth requirements, or other criteria that distinguish different service plans. Special promotions may be offered from time to time, which again would alter the price charged for various services. Each service variant must be considered individually in order to calculate the appropriate charges associated with the provision of a specific package of products or services to a customer.

Another factor that complicates the generation of customer invoices for the provision of telecommunications services is that there are often multiple charges that contribute to the total amount charged for the provision of a specific variant of product or service to a customer. A specific product or service may include monthly usage charges, recurring monthly equipment rental or line charges, and the like, a one-time activation or cancellation fee, taxes, and other charges. The amount charged for each of these components may be the same or different than the amount charged for other service variants.

In many telecom billing systems including Accenture's ACS billing solution based on Intec's Singl.eView for Converged Billing (Singl.eView), product and service offerings are configured and stored in a database. The product configuration contains all the details necessary to define an offer of products or services. Product configuration will include data such as, among others, a product name and various other attributes that distinguish the product or service offer from other product or service offerings. Another significant component of product setup is the identification of billing rates related to product or service offering.

Billing rates are software objects that identify the charges associated with a configured product or service offering. A product or service offering may include separate fees for external use charges, taxes and various internally generated charges such as rental or other monthly recurring service charges, one-time activation or deactivation charges, and the like. The present invention correlates the configuration of internal event rates and the calculation of the charges associated with them, such as for example recurring monthly charges and non-recurring activation costs, and other charges. These tariffs are indicated as internal tariffs as events generated within the billing system itself, unlike external tariffs such as usage tariffs, which are triggered on the basis of input from external sources such as network switches and similar.

As mentioned above, there are multiple product or service attributes that affect the charges applied to a customer invoice for the delivery of a specific product or service. Since the total charge is merely a compilation of the charges associated with the various tariffs linked to the specific product or service, some or all of the attributes of the products or services affect the charge component generated by each of the various tariffs linked to the product offerings or services. Since some or all of these attributes are different for different product or service offerings, the calculation of fee charges will differ from one product to another. In the past, this has required different formulas and different entries for the purpose of calculating each tariff for each product variant. This requires large changes in the billing system environment whenever a new product or service or a new product or service variant is created. In many cases, new tables need to be added to the database or large changes need to be made to existing tables in order to accommodate new product or service configurations and new rate configurations. In the Singl.e View package and other billing packages, the billing logic must be configured as coded logic on hardware, expensive both in terms of the resources necessary to implement the new product or service offerings, as well as the amount of time required to implement the variations.

Implementing changes to the billing system can significantly delay new product and service offerings. In a competitive environment where new products and services are a key factor in winning new customers and retaining existing customers, the delay and costs involved in deploying new products and services can be significantly detrimental to a provider's performance. telecommunications services. The present invention provides an improved mechanism for configuring new products and services and associated internal charge event rates and for calculating the charges associated with such rates.

BRIEF SUMMARY

The present invention makes available a billing framework for improving the functionality of the billing system of a telecommunications service provider. A specific embodiment of the invention is configured to improve the functionality of the Singl.e View billing package. The billing framework makes it easy to configure new product and service offerings and associated billing rates, and provides a single billing function to calculate charges for all internally generated billing events.

The billing framework provides a structured approach to configuring any type of documented billing rate. Using this approach saves a great deal of time and resources, since all low-level billing rate objects are already created and defined within the billing framework and are immediately ready to use. These objects include a predefined derived attribute table, a charge function to calculate tariff charge attribute types, reference types, modules and variables, and so on. When configuring a new rate, the only effort required to support a new list of product or service offerings is to define the price applied to the rate. No effort is wasted in defining all hidden underlying objects. An additional advantage of the framework is the improved performance of the billing system. The entire set of billing level pricing parameters can be cached, thereby reducing processing time and conserving database resources.

One embodiment of the invention makes available a system extension for a billing system. The billing system is designed to generate customer invoices associated with the provision of telecommunications products and services. The billing system includes software instructions to be executed on a computer server platform, a database for storing product configuration data for a plurality of product offerings and billing rates related to product offers, and a user interface that allows an operator to interact with the system and configure portions of it. The system extension provides an editable derived attributes table that identifies a unit charge rate for the rates linked to configured product offers. A charge calculation function is also provided for the purpose of calculating a charge for a rate linked to a specific product offer. The charge calculation is based on the unit charge rate identified for the rate date in the derived attributes table.

In another embodiment, a method is made available for calculating a charge associated with the provision of telecommunications services. The method includes creating a derived attribute table to store a plurality of parametric attribute values associated with the defined rates. Each defined rate can be identified by its own set of unique parametric attribute values. The derived attributes table also stores result values associated with each fare. Result values include a unit charge rate associated with each rate. Then, both a product offering and an associated rate are configured. The rate is linked to the product offering in such a way that, in combination, the configured product offering and the configured rate define the unique set of parametric attribute values corresponding to a rate stored in the derived attributes table. The corresponding rate is located in the derived attribute table based on the defined set of parametric attribute values, and the result values, including the unit charge rate value associated with the defined rate, are extracted from the derived attributes table. Finally, the charge associated with the tariff is calculated on the basis of the unit charge rate extracted.

Another embodiment also makes available a method for calculating a charge associated with the delivery of telecommunications products. This method includes creating a charge lookup table to assign base charges to rates. The charge search table includes a plurality of stored tariffs, each identifiable by a first unique set of identifiers. A tariff associated with a telecommunications product is configured. The configured tariff and the product define a second set of identifiers able to identify the tariff among a plurality of other tariffs. In the course of preparing an invoice, a debit function is performed. The charge function accesses the search table in order to locate the stored rate having a first set of identifiers corresponding to the second set of identifiers associated with the configured rate and the associated product offer so as to obtain the basic charge assigned to the rate stored. The charge function then calculates the total charge associated with the rate based on the base charge obtained.

Finally, a method is made available to calculate a billing charge. According to this embodiment, a method includes identifying a product associated with a customer. Product configuration features must include a product name, a rate, and one or more billing parameter values associated with the product configuration. The rate configuration includes an event type and an event subtype which are used to indicate normalized internal events generated by the rate during the billing process. When processing a customer invoice, the billing system generates a normalized internal event based on the rate. The normalized internal event is enriched with one or more billing parameter values associated with the product, and the billing system invokes a billing function in order to identify a unit charge rate for the tariff based on the product name, of the type event, and the one or more values of billing parameters associated with the product. Finally, the invoked function calculates the billing charge based on the unit charge rate and a quantification factor.

Other systems, methods, features and advantages of the invention will be or will be apparent to one skilled in the art once the following Figures and detailed description have been examined. It is intended that all such additional systems, methods, features and advantages are included within this disclosure, fall within the scope of the invention, and are protected by the claims which follow this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows an example of a predefined configurable charge tree;

Figure 2 shows a screenshot from the Singl.eView GUI (graphical user interface) used to configure rates, which shows a rate configuration page with the SETTINGS tab selected;

Figure 3 shows a screenshot from the Singl.eView GUI (graphical user interface) used to configure rates, which shows a rate configuration page with the CHARGES tab selected;

Figure 4 shows a screen from the GUI (graphical user interface) Singl.eView used to configure tariffs, which shows a tariff configuration page with the ACTIVATION tab selected;

Figures 5A and 5B show distinct portions of a derived attribute table displayed by the Singl.eView GUI (graphical user interface) used to configure rates;

Figure 6 shows an operational flow diagram of the billing process implemented on the billing framework of the invention; And

Figure 7 shows a process flow diagram of the charging framework.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to a charge framework for calculating charges associated with the provision of telecommunications services. The billing framework acts as an extension of a telecom service provider's billing system and provides a lean and easy-to-use configuration platform that is configured to reduce the amount of time required to set up new product and service offerings. The billing framework provides a uniform method of defining and calculating charges associated with linked billing rates.

One embodiment of the invention is particularly suitable for use with Accenture's ACS billing solution, based on Intec's Singl.eView for converged billing. Singl.eView is a sophisticated billing system configured to run on a Unix-based application server in conjunction with an Oracle database. The billing framework of the present invention is a software layer on top of the Singl.eView billing system. However, it should be noted that the billing framework of the present invention is not limited to the extension of the Singl.eView billing system only. The benefits and innovative features of the billing framework are adaptable for use with other billing systems based on the billing framework or other hardware platforms.

The charging framework of the present invention provides a standardized structured approach to configuring the charging rates associated with product and service offerings. The structured approach significantly reduces the time required to set up new rates as well as new product and service offerings as all low-level rate objects, such as a common charge function, attribute types, referral types, modules, variables and a unique derived attribute table are already complete and ready to use when creating new rates. When setting up a new rate, the only substantial effort required to support a new product offering is to define the price associated with the rate. In addition, the structured approach to pricing setup allows for the application of a single common billing function to calculate the charges associated with the various rates associated with different product and service offerings. The single common billing function simplifies the process of setting up new product and service offerings and reduces the complexity of the processes required to calculate the charges associated with specific product and service cases. The billing framework calculates charges for internally generated events such as recurring monthly charges, activation fees, deactivation fees, and the like. Internal events are those that originate within the billing system itself. Charges associated with external events, such as usage charges, which require input from an external source such as external network switches, are calculated separately. The billing framework calculates the price of recurring and non-recurring events based on specific attributes of products and services according to a predefined configurable billing tree.

The predefined charge tree according to an embodiment of the invention is shown in Figure 1. The charge 10 shows the parameters that contribute to the calculation of a charge amount associated with a tariff linked to a specific product or service. The high-level entries include a charge plan 12, a product or service case 14, and a charge period 16. The charge plan 12 includes data related to both the product and the rate linked to the product. The charge plan 12 includes the product name 18, a charge event type 20, and, where necessary, a charge event subtype 22. For example, a product name could be "DSL high-speed access". A "DSL High Speed Access" product fee may be a recurring monthly service charge. The charge event type associated with the rate could therefore be "recurring" and the charge event subtype "recurring DSL high-speed access".

The case of product or service 14 concerns a specific offer of products or services that is sold to a customer. The product or service case provides at least one charge parameter that defines various attributes of the specific product or service case. The charge parameters associated with a product or service case contribute to the calculation of the charge amount associated with the rate. Charging parameters associated with a specific product or service case could include elements such as the price list applied to the product or service case, such as gold or silver, or the bandwidth assigned to the product or service case, or others product attributes. According to an embodiment of the invention, a product or service case can include up to six charge parameters 24, 26, 28, 30, 32 and 34. However, in some circumstances, product or service cases can be configured without no charge parameters. The product name 18, the charge event type 20, the charge event subtype 22, and the charge parameters 24, 26, 28, 30, 32, and 34 form a composite index key to locate a unit charge rate 36. The charge period 16 is a quantification factor generated by the billing system and identifies the number of base time units for which a charge is to be calculated. For example, a rate associated with a specific product may require a recurring monthly expense. However, the service can only be billed on a bimonthly basis. In this case, when the invoice is prepared, the recurring monthly expense charge must be doubled to account for the bimonthly billing period. As a result, the billing period would be set to 2. The final charged amount 38 is calculated by multiplying the identified unit charge rate 36 by the billing period 16.

As mentioned above, the billing framework forms an extension of a telecom service provider's billing system. The billing framework has a simple billing function to calculate the charges associated with the billing rates according to the default billing tree described above, and a unique billing function that accesses an editable derived attribute table to determine the billing rate unit to be applied when calculating charges for specific rates. The derived attribute table is accessed according to a composite index key that includes the product name, event type and event subtype as well as up to six billing parameters, as outlined in the billing tree in Figure 1. All configurations of product and tariff must be represented in the derived attributes table, so that the corresponding unit charge rate can be found when a charge associated with a tariff is calculated. The derived attribute table can be stored in the database associated with the billing system, however, the entire set of rate parameters used at the charge level can be cached in order to support maximum flexibility in how new ones are configured product offerings, while ensuring the best performance.

Product and service offerings are configured within the billing system with the help of a graphical user interface (GUI). The product or service configuration defines the product name, identifies the rates associated with the product or service, and defines the billing parameters available to define the individual product or service offering. Preferably, the billing parameter values selected for a specific product or service offer are selected from a predefined list of available parameter values in order to facilitate the configuration of new product and service offers and associated rates. When a product or service is sold to a customer, the billing parameters that form the complete offer define the specific case of product or service associated with the customer.

The rates associated with the various products and services are configured in the billing framework using the billing system GUI. Figures 2, 3 and 4 show various screenshots from the Singl.eView billing system GUI relating to the setup of rates. It should be noted that tariff configuration screens of the billing system GUI are adapted to configure tariffs in the presence or absence of the billing framework of the present invention. Setting up a tariff without the help of the charge framework is a much more complicated task. As a result, the rate configuration pages of the billing system GUI contain many unnecessary fields when configuring rates in the billing framework. The description below is limited to the aspects of the fare configuration GUI pages that relate to configuring a fare within the context of the billing framework.

The configuration of a tariff within the charge framework includes, among other things, the identification of the product name of the product or service to which the tariff is linked, and the definition of the type of charge event and sub-type of event of charge associated with the tariff. Each of the screens in Figures 2, 3 and 4 includes a rate definition section 50. The rate definition portion 50 includes a name field 52 in order to enter a name for the configured rate. A description field 54 is provided in order to enter a brief description of the rate. Start date 56 and end date 58 fields are provided to specify the time period during which the tariff will be in effect. If no date is specified in the end date field 58, the rate may be in effect indefinitely. Finally, a version 60 field allows the user configuring the rate to define or assign a version indication to the rate.

A series of selectable tabs 62, 64, 66, 68, and 70 controls the fields displayed on the rest of the fare setup page. Figure 2 is a screenshot of the Singl.eView GUI display with the settings tab 62 selected. From the fare settings tab, a user configuring a new fare can select a fare class and enter a number of functional settings for the fare. A fare class can be defined by selecting one of the selectable fare classes, listed in a fare class definition area 72. In the example shown, a fare can be classified as standard fares; recurring; activation; or deactivation. Settings include rate type 74, status 76, priority 78, data type 80, application 82, context 84 and charge category 86. Rate type 74 can be selected from the list of types of predefined fare provided in a drop-down menu associated with the tariff class field 72. The fare type is limited only to the types previously defined and listed in the drop-down menu. Examples of selections that can be made for the rate type 74 field include: use; recurring; on specific request; Discount; one-time discount; discount for prompt payment; fee; or commission. The tariff status is entered in the status field 74. Again, the status that can be entered in the status field 76 is limited to a list of predefined status values listed in the corresponding drop-down menu. Examples of selections that can be entered in the status field include: active (rate in use); o test (tariff in the testing phase). The data type associated with the rate is defined in the data type field 78, and again the selections are limited to the predefined data types listed in the corresponding drop-down menu. Examples of data types include; real; royal host; or real hash. The application for which the rate is intended is identified in application field 78. Application entries are also limited to predefined applications listed in the drop-down menu accompanying application field 82. A typical list of applications includes: pricing or billing. The context is defined in the context field 82. Again entries are limited to predefined contexts identified in the drop-down menu associated with the context field 82. Examples include: normalized event; customer; client node; or service. Rates based on the "use" rate type would generally be assigned to the "Quoting" application environment and the "Normalized event" context. Rates based on other rate types will generally be assigned to the "Billing" application environment and to one of the "Customer", "Customer Node" or "Service" contexts. A charge category can be defined in the charge category field 84, where again the selection of possible charge categories is limited to predefined charge categories present in the associated drop-down menu. Examples include: ACS Default EUR, CLEC Default.

The currency in which a tariff charge is to be calculated can be entered in the currency field 84. An invoice section code can be entered in the invoice section field 86 in order to define where charges associated with the tariff will appear on an invoice, and text describing the source of the charge can be entered in the default invoice text field 88.

Figure 3 shows the Singl.eView GUI rate configuration page with the charge tab 66 selected. This page allows the user to enter charge expressions in order to define how the charge associated with the rate is calculated. However, within the billing framework, all internal rate charges are calculated using a single charge function. Therefore, a single function invocation is entered in the default charge expression field 92. The function invocation identifies the function invoked and the product name to which the rate is to be linked. Hence, in the example shown in Figure 3, the default charge expression 92 includes the charge function name ACS_Chargingframework_allservices-V2.2, and the product name ACS DSL Lite Access Activation (Gold) to which the tariff is linked. configured.

Figure 4 shows the tariff configuration page of the Singl.eView GUI with the activation tab 94 selected. A normalized event type associated with the rate is defined in the normalized event type 96 field. A normalized event is an object created by the billing system whenever a charge associated with the rate must be calculated. The normalized event type specifies the type of recurring charge to be generated when the rate is invoked. The specified normalized event type determines how the normalized event is formatted. Normalized event types are configurable and can be selected from a list of preconfigured normalized event types contained in a drop-down menu associated with the 96 normalized event type field. Examples of predefined normalized event types include: CLEC (exchange charge competitive location), MRC (monthly recurring charge), and NRC (non-recurring charge), and so on. Also, note that these are merely labels defined in the configuration of normalized event types. The event type and the tariff event subtype are defined respectively in the event type 98 and event subtype 100 fields. Again, the event type and the event subtype can be selected from predefined lists of event types and subtypes. of events contained in the drop-down menu associated with each field. Examples of predefined event types include: non-recurring CLEC; and recurring CLEC. Examples of predefined event subtypes include ADSL ACS modem activation and ADSL ACS recurring. A correction event type and a correction event subtype can be defined in the correction event type 102 and correction event subtype 104 fields. Again, selections are limited to predefined correction event types and correction event subtypes contained in the corresponding drop-down menus . Finally, an entity type can be selected by making a selection from the various entity types listed in the entity type selection block 106. The entity type defines the entity type to which the tariff will be linked, such as a product, a service, equipment or other.

A final component of configuring products and rates in the billing framework is updating the derived attributes table. As previously mentioned, the derived attributes table defines the unit charge rate to be applied for each configured tariff linked to each configured product. Consequently, if a new rate is configured, the derived attribute table must be updated to reflect the change. Figures 5A and 5B show a portion of a derived attribute table 200 according to an embodiment of the invention. The derived attributes table includes a plurality of columns that define the data variables necessary to distinctly identify each rate associated with each product offer configured in the billing system, the unit charge rate associated with each rate and any high charge information relating to the calculation of the charges associated with each tariff. Thus, the column headings for the derived attributes table include product name 202, event type 204, event subtype 206, general charge parameter 5 (rate ID) 208; the general charge parameter 6 210; the general charge parameter 7 (not shown); the general charge parameter 8 (not shown); the general charge parameter 9 (not shown); the general charge parameter 10 212, the unit rate 214, the charge description 216; the debit information 1 218; and charge information 2 charge information 8 (not shown).

Each row of the derived attributes table represents a tariff linked to a specific offer of products or services. The derived attributes table is accessed on the basis of a composite index key comprising the product name, the event type, the event subtype and the charge parameters 1-6 (general 5 - general 10), and it gives the corresponding response billing information including the unit charge rate, billing description and billing information 1-8. When a unit charge or other charge information is to be retrieved for a specific rate, the row of the derived attribute table that stores it and the unit charge rate as well as other charge parameters stored in that row are given as results. Thus, the derived attributes table functions as a large lookup table to identify the unit charge rate and other charge information for each rate configured in the billing system.

The benefits of storing unit charge rates and other loading information in the derived attribute table will become apparent when you consider the processes involved in producing an invoice and calculating the charges associated with internally generated billing events. Figure 6 is an operational flow diagram illustrating the charging process implemented at the tariff level by the charging framework of the present invention. Figure 6 shows the processing steps 220, the corresponding processing parameters 222 and a simplified derived attribute table 224 for calculating charges.

The first processing step is the generation of internal normalized events 226. Internal normalized events are events generated within the billing system and which require the calculation of a charge. For example, when a customer subscribes to a service that has a recurring monthly charge, the amount of the monthly charge must be calculated each month when the customer invoice is generated. The recurring monthly rate generates an internal event that must be priced. The processing parameters 228 associated with the generation of normalized internal events include the entry parameters Type of charge event; Charge event subtype; e Product / Service Charge Parameters 1-6. The result emitted by the generation of internal normalized events is the internal normalized event itself. The internal normalized event is represented as a row of an Oracle database normalized_event Table created and normalized by the billing system. The normalized events table includes columns corresponding to the input parameters associated with the generated event.

Once the internal normalized event is generated, the next general processing step is the calculation of the unit charge rate associated with the event. The entry parameters in the unit charge rate calculation step are the product name, the charge event type, the charge event subtype, and the product / service charge parameters 1-6. These input parameters are used as a composite index key to access the derived attributes table so as to identify the appropriate row corresponding to the event generated and give the corresponding unit charge rate as a response. For example, suppose a normalized internal event is generated with the name Fast Access DSL Lite, having a "recurring" charge event type, a recurring Fast Access DSL Lite event subtype, and where the charge parameter 1 (parameter general 5 of the internal normalized event) is "Gold". A search of the simplified derived attribute table 224 with the specified composite index key would identify the first row 238 of the derived attribute table 224, and would return a unit charge rate of € 18. Similarly, suppose a second normalized internal event has a Fast Access DSL Lite product name, a "recurring" charge event type, a recurring Fast Access DSL Lite charge event subtype, and a charge parameter 1 (general parameter 5 of the internal normalized event) "Silver". A search of the derived attribute table 224 with the specified composite index key of this second normalized internal event would identify the second row 240 of the simplified derived attribute table, and would return a unit charge rate of € 22.

Once the unit charge rate has been calculated, the final processing step is to calculate the charge amount 234. The 236 entry parameters associated with this phase are the charge period and the unit charge rate. As mentioned above, the billing period is generated by the billing system itself. The unit charge rate is given as an answer from the derived attributes table. The final charge amount is calculated by simply multiplying the unit charge rate by the charge period. The calculated charge amount can be used by the billing system to generate an invoice in order to charge the customer for the specific product or service that generated the normalized event.

Figure 7 is a flowchart 300 showing how the charge framework works in the context of generating a customer invoice. The billing process begins when a billing session is initiated in 302. During a billing session, the products associated with each customer are identified and the related charges associated with each product are calculated to generate invoices that can be sent to customers . The billing system draws the product configuration, for each product or service purchased by a customer, from the billing system database. The specific product or service offering sold to a customer, including all billing parameters associated with the product or service offering, includes a product or service case.

A rental generation (RGP) process is triggered in 304 by each internally generated rate, such as recurring charge rates, one-time activation fee, and the like. The RGP process is the trigger that indicates the need to calculate a charge. Rates linked to products owned by a customer generate internal normalized events in 306. Generating a normalized internal event involves adding a row to a normalized internal events table within the billing system. The normalized event table includes a number of general data fields, in particular normalized event general 5 - normalized event general 10 fields that can be used to store charge parameter data in 308. The normalized event is driven to the data configuration of products of the specific case of product or service for which a charge must be calculated on the basis of the product name defined in the tariff that initiated the normalized internal event. The normalized internal event is enriched with the charge parameters of the specific product or service case. Specifically, the charge parameters from the configuration of products on the product or service case are written in the normalized event general 5 - normalized event general 10 fields of the internal normalized event. The product, the product name, the type of event and the sub-type of event are received by the configuration of the rate itself.

Then, the rates are filtered into 310 based on factors such as application, environment, context, priority and eligibility for selection. Eligibility for selection is a definable parameter when configuring a fare. Eligibility to select a rate is used to fine-tune a list of expressions that must be satisfied in order for the rate to be applied. In particular, using the list of eligibility expressions for selection, it is possible to filter rates that cannot be chosen for specific normalized events. Within the charge framework, eligibility to select is used to ensure correct rates are applied by fine-tuning the list of eligibility expressions to filter rates based on event type and event subtype , present in the normalized event being processed. Once the rates are filtered, the rate is applied by invoking the standardized charge function in 312. All internal rate events are processed the same way by the ACS charge function. Normalized internal events are scanned in 314 to generate the composite index key to access the charge framework derived attribute table. Therefore, the composite index key includes the product name, the event type, the event subtype and any billing parameters stored in the general normalized event fields 5-10.

The derivative attributes table is accessed in 316, and it returns results that include the unit charge rate and any relevant charge information. The charge amount is calculated at 318 by multiplying the unit charge rate, given as an answer, by the duration. As mentioned above, the duration is a parameter provided by the billing system and indicates how many billing units apply, for example a monthly expense billed every two months would have a duration of 2, so that the total amount would be double the rate of unit charge. In 320, the final charge amount and any additional charge data given as a response from the derived attributes table are forwarded to a billing process that applies the calculated amount to the invoice being processed. Finally, the billing process ends in 322 with the generation of billing data.

For the sake of completeness of disclosure, the source code for the charging function of the charging framework according to an embodiment of the invention is presented in the following.

# NAME:

# fACS_TP_ChargingFramework ##

#

# DESCRIPTION:

# This function determines t he unist charge for recurring / activation tariff and additional charging Information.

# The lookup to determine the rate and additional charging parameters is based on the following composite index:

# 1 / produce name

# 2 / Event Type (from event)

# 3 / Event Sub Type (from event)

# 4 / generai 5 (Tariff Id) (from NORMALIZED EVENT GENERAL 5 field)

# 5 / generai 6 (from NORMALIZED EVENT GENERAL 6 field)

# 6 / generai 7 (from NORMALIZED EVENT GENERAL 7 field)

# 7 / generai 8 (from NORMALIZED EVENT GENERAL 8 field)

# 8 / generai 9 (from NORMALIZED EVENT GENERAL 9 field)

# 9 / generai 10 (from NORMALIZED EVENT GENERAL 10 field)

#

#

# PARAMETERS:

# produce name

#

# RETURNS:

# Charge

#

#

#

fACS_ChargingFramework_AllServices_V2 .2 # (const ProductName $) = {

ver l_Charge #: = 0.00;

ver l_Results? [];

var l_MRC_Index? [];

const 1_MRC_DA $: = 'dACS_ChargingFramework_V2.0';

var lProductFieldValues? [];

# De fine index for lookup

l_MRC_Index $ [0]: = ProductName $;

l_MRC_Index & [1]: = EventTypeCodeS; l_MRC_Index & [2]: = EventSut> TypeCode &;#-L;# * Any *

if (General5 $ = <11>)

then {l_MRC_Index $ [3]: = 'NULL';} else {l_MRC_Index $ [3]: = General5 $;}; if (General6 $ = <1> ')

then {l_MRC_Index $ [4]: = <1> NULL <1>;}

else {l_MRC_Index $ [4] General6 $;}; if (General7 $ = '')

then {l_MRC_Index $ [5] 'NULL';} else {l_MRC_Index $ [5] General 7 $;}; if (General8 $ = '')

then {l_MRC_Index $ [6] 'NULL';} else {l_MRC_Index $ [6] General 8 $;}; if (General9 $ = 11)

then {l_MRC_Index $ [7] 'NULL';} else {l_MRC_Index $ [7] General 9 $;}; if (GenerallO $ = '')

then {l_MRC_Index $ [8] 'NULL';} else {l_MRC_Index $ [8] General 10 $;};

if DerivedTableLookupByDatex & (1_MRC_DA $,

ChargeStartDate ~, l_MRC_Index? [], 1 Results? []) Then

{

l_Charge #: = l_Results # [0] * Duration #;

#assign return values to DA vairbales dACS_ChgFramework_General 1 $: = to_string (l_Results? [0]);

dACS_ChgFramework_General2 $: =

to_string (l_Results? [1]);

dACS_ChgFramework_General 3 $: =

to_string (l_Results? [2]);

dACS_ChgFramework_General4 $: =

to_string (l_Results? [3]);

dACS_ChgFramework_General 5 $: =

to_string (l_Results? [4]);

dACS__ChgFramework_General6 $: =

to_string (l_Results? [5]);

dACS_ChgFramework_General7 $: =

to_string (l_Results? [6]);

dACS_ChgFramework_General 8 $: =

to_string (l_Results? [7]);

}

return l_Charge #;

}

The standard charge function and the derived attributes table allow the configuration and implementation of tariffs in a much easier way and allow the calculation of the charges associated with internal tariff events in a much more effective way than with traditional billing systems.

While embodiments of the invention have been described, it will be apparent to those skilled in the art that many other embodiments and implementations are possible within the scope of the invention. Consequently, the invention is not to be limited except in the light of the appended claims and their equivalents.

Claims (30)

CLAIMS 1. A system extension for a billing system to generate customer invoices associated with the provision of telecommunications products and services, where the billing system includes software instructions to be executed on a computer server platform, a database to store product configuration data for a plurality of product offers and charge rates linked to product offers, and a user interface that allows a user to interact with the system and configure portions, 1 system extension including: an editable derivative attributes table that identifies a unit charge rate for tariffs linked to product offers; And a charge calculation function to calculate a charge for a tariff linked to a specific product offer based on the unit charge rate identified in the derived attributes table for the tariff. 2 . The system extension according to claim 1 wherein the derived attribute table is adapted to store configured parameter values for a plurality of configured tariffs. The system extension of claim 2 wherein the configured parameters relate to input composite key parameters and at least one output result parameter. The system extension according to claim 3 wherein the composite entry key parameters include a product name, an event type and a first charge parameter. The system extension according to claim 3 wherein at least one output result parameter includes the unit charge rate. The system extension of claim 1 wherein the charge calculation function comprises assembling a line of plurality of composite index key parameter values to access the derived attribute table. The system extension of claim 6 wherein the charge function comprises multiplying a unit charge rate, given as a response from the derived attribute table, by a quantification value. 8. The system extension according to claim 1 wherein the derived attribute table stores a product name, an event type, a primb charge parameter and a unit charge rate for a plurality of configured tariffs, and the charge calculation function identifies the product name, the type of event and a first charge parameter for a rate for which a charge must be calculated, accesses the derived attributes table to extract the unitary charge rate value associated with a rate configured in the derived attributes table having the same product name, type of event and first charge parameter with respect to product name, type of event and first charge parameter identified by the charge function for the rate for which a charge is to be calculated. 9. A method for calculating a charge associated with the provision of telecommunications services, the method comprising: the creation of a derived attribute table which generates a plurality of parametric attribute values associated with defined rates, each defined rate being identifiable by a set of parametric attribute values, the table of derived attributes also storing result values associated with each rate, the result values including a unit charge rate; the configuration of a product offering; the configuration of a tariff; linking the tariff to the product offer, so that, in combination, the configured product offer and the configured tariff define the unique set of parameter attribute values corresponding to a defined tariff stored in the derived attributes table, the localization of the tariff defined in the derived attributes table having the unique set of parametric attribute values corresponding to the configured product offer and the configured tariff, and the preparation, as a response, of the values of results associated with the defined tariff, including the value of unit charge rate; And the calculation of the charge base on the basis of the unit charge rate given as an answer. The method for calculating a charge associated with the provision of telecommunications services according to claim 9 wherein the set of parametric attribute values for identifying each tariff in the derived attribute table includes values for a product name, an event type and a parameter of debit. The method for calculating a charge associated with the provision of telecommunications services according to claim 10, in which the configured product offering includes defined parameter attribute values for a product name and a charge parameter, and in which the configured tariff includes a parametric attribute value defined for an event type. The method for calculating a charge associated with the provision of telecommunications services according to claim 11 wherein the set of parametric attribute values for identifying each tariff in the derived attribute table further includes an event subtype, and the configured tariff further includes a parametric value defined for an event subtype. The method for calculating a charge associated with the provision of telecommunications services according to claim 11, wherein the set of parametric attribute values for identifying each tariff in the derived attribute table includes values for a plurality of charge parameters, and the configuration for the configured product offering include values defined for the same plurality of charge parameters. 14. The method of calculating a charge associated with the provision of telecommunications services whence claim 11 further comprising the ction of an event report based on the configured rate execution, in which the event report receives and stores values for the product name and type of event from the configured rate. The method for calculating a charge associated with the provision of telecommunications services according to claim 14 further comprising enriching the event report with the parametric attribute value defined for the charge parameter. The method for calculating a charge associated with the provision of telecommunications services according to claim 15 further comprising invoking a charge calculation function based on the execution of the configured tariff, the charge function by filling in a composite index key starting from the product name, event type and charge parameter values stored in the event report, accessing the derived attribute table based on the compiled composite index key, identifying a tariff defined in the derived attribute table having a set of parametric attribute values corresponding to the product name, event type and charge parameter values of the composite index key, the preparation, as a response, of the unit charge rate from the defined defined rate, and the calculation of the charge based on the unit charge rate given as an answer. 17. A method of calculating a charge associated with the provision of telecommunications products, the method comprising: the creation of a charge search table to assign basic charges to rates, the charge search table including a plurality of stored rates, each identifiable by a first set of unique identifiers; the configuration of a tariff associated with a telecommunications product, the configured tariff and the product by defining a second set of identifiers suitable for identifying the tariff among a plurality of other tariffs; accessing the search table and locating a stored tariff having a first set of identifiers corresponding to the second set of identifiers of the configured tariff so as to obtain the basic charge assigned to the memorized tariff; And the calculation of the charge associated with the provision of the telecommunications product with which the configured tariff is associated on the basis of the basic charge obtained. The method for calculating a charge associated with the provision of telecommunications products according to claim 17 wherein the identifiers include a product name, an event type and a charge parameter. The method of calculating a charge associated with the provision of telecommunications products according to claim 18 wherein the identifiers further include an event subtype. The method for calculating a charge associated with the delivery of telecommunications products according to claim 18 wherein the identifiers further include a plurality of charge parameters. The method for calculating a charge associated with the provision of telecommunications products according to claim 18 further comprising creating a normalized event report in response to the tariff, the normalized event by storing data relating to the tariff and the product. The method of calculating a charge associated with the provision of telecommunications products according to claim 21 wherein the normalized event report receives and stores the product name and event from the tariff setup and the charge parameter from the product setup. 23. The method for calculating a charge associated with the provision of telecommunications products according to claim 22 further comprising the compilation of a composite index key to access the charge lookup table based on the values of product name, event type and parameter charges stored in the normalized event report. 24. The method for calculating a charge associated with the provision of telecommunications products 17 where the calculation of the charge involves multiplying the base charge by a quantification factor. 25. A method of calculating a billing charge, the method comprising: the identification of a product associated with a customer, the product having a product name, a rate and one or more values of charge parameters associated with it, the rate by identifying a type of event; the generation of a normalized internal event on the basis of the tariff; enrichment of the normalized internal event with one or more values of charge parameters associated with the product; And the invocation of a charge function to identify a unit charge rate for the tariff based on the product name, the type of event and the one or more values of the charge parameters associated with the product and calculate the billing charge from the unit charge rate and a quantification factor. The method for calculating a billing charge according to claim 25 further comprising creating a derived attribute table for assigning a unit charge rate to billing rates. The method for calculating a billing charge according to claim 25 wherein the derived attribute table comprises a plurality of rows and columns, the rows corresponding to configured rates and the columns corresponding to attribute parameters and an associated unit charge rate to tariffs and products to which they are associated, each tariff in the table being identifiable by means of a unique set of parametric attribute values stored in the row corresponding to the specific tariff. The method for calculating a billing charge according to claim 27 wherein identifying a unit charge rate for a tariff comprises identifying a row in the derived attribute table that stores parametric attribute values corresponding to the product name, type of event and charge parameter of the tariff and of the product to which it is associated, and the preparation, as a response, of the unit charge rate value stored in the identified row. The method of calculating a billing charge according to claim 25 wherein the generation of a normalized event comprises the creation of a normalized event report adapted to store parametric attribute values associated with the rate and the product including the rate. 30. The method for calculating a billing charge according to claim 26 wherein the charge function is adapted to compile a composite index key to access the derived attribute table and give as a response the unit charge rate associated with the rate identified by the key .