AU2013205629B2 - Configurable charging system for a telecommunications service provider - Google Patents

Abstract

A system extension for a billing system adapted to generate customer bills associated with the delivery of telecommunications products and services, wherein the 5 billing system includes software instructions adapted to be executed on a computer server platform, a database for storing product configuration data for a plurality of product offerings and charging tariffs attached to the product offerings, and a user interface allowing a user to interact with and configure portions of the billing system, the system extension including a composite index key for accessing a unit charge rate 10 for a tariff attached to a telecommunication product offering, wherein the composite index key includes key parameters for uniquely identifying a tariff, an editable derived attributes table that identifies the unit charge rate for the tariff attached to the telecommunication product offering and that associates the unit charge rate with the composite index key, and a charge calculation function operable to assemble the 15 composite index key from the key parameters, index the editable derived attributes table with the composite index key to determine the unit charge rate, and calculate the charge amount for the tariff attached to the telecommunication product offering based on the unit charge rate located in the editable derived attributes table with the composite index key. in.g Planie har eagl Eentc I nYoe U it Ch r epC a 14~e ae Chaerge DEen te Rate Clos uHa Service iswm~i~ Char ing Paameoat End Ot. Ianstanacef 62rgn 64r65e68r70 24 Change CaeoerCie~utEtR8 [D~mCharging Tree INamie Section DaL InvZ;icek Text al

Description

AUSTRALIA Patents Act 1990 SPECIFICATION INVENTION TITLE: CONFIGURABLE CHARGING SYSTEM FOR A TELECOMMUNICATIONS SERVICE PROVIDER The following statement is a full description of the invention, including the best method for performing it known to: Lesicar Murray Trento 58 Rundle Street Kent Town SA 5067 mail lnitip.com au PH: (08) 8362 7360 2 CONFIGURABLE CHARGING SYSTEM FOR A TELECOMMUNICATIONS SERVICE PROVIDER FIELD OF THE INVENTION The present invention relates to a billing system extension for facilitating the configuration of new product offerings and billing tariffs associated with the delivery of telecommunications products and services, The present invention provides a charging framework for configuring tariffs and calculating the charges associated with internal event tariffs in order to provide charging data to the billing system for generating customer bills. BACKGROUND Generating customer bills for telecommunication services is a complicated process. Telecommunications service providers typically provide multiple services, and are adding new products and services at an ever increasing rate. Each service typically has its own peculiarities and challenges with regard to calculating service charges, Complicating the billing process further is the fact that each base product or service typically has multiple variants. For example, a base product or service may have multiple price lists depending on a customer's monthly access usage, or based on bandwidth requirements, or other criteria that distinguish different service plans. Special promotions may be provided from time to time which would again alter the price charged for various services. Each service variant must be considered individually in order to calculate the appropriate charges associated with delivering a specific product or service package to a customer. Another complicating factor in generating customer bills for delivering telecommunications services is that there are often multiple charges that contribute to the total amount charged for delivering a particular product or service variant to a customer. A particular product or service may include charges for monthly usage, recurring monthly fees for equipment rental or line charges, and the like, a one time activation fee or cancellation fee, taxes, and other charges. The amounts charged for 3 each of these components may be the same or different than the amounts charged for other service variants. In many telecommunications service billing systems, including Accenture's ACS Billing Solution based on Intec's Singl.eView For Convergent Billing (Singl.eView), a product and service offerings are configured and stored in a database. The product configuration contains all of the particulars necessary to define a product or service offering. The product configuration will include data such as, among other things, a product name and various other attributes that distinguish the product or service offering from other product or service offerings. Another significant component of the product configuration is the identification of charging tariffs attached to the product or service offering. Charging tariffs are software objects which identify the charges associated with a configured product or service offering. A product or service offering may include separate tariffs for external usage charges, taxes, and various internally generated charges such as recurring rental or other monthly service fees, one-time activation or deactivation charges, and the like. The present invention relates the configuration of internal event tariffs and the calculation of the charges associated therewith, such as recurring monthly charges and non-recurring activation fees and other charges. Such tariffs are referred to as internal tariffs because they are events generated within the billing system itself, as opposed to external tariffs such as usage tariffs which are triggered based on input from external sources such as network switches and the like. As mentioned above, there are multiple product or service attributes that influence the charges applied to a customer's bill relating to the delivery of a particular product or service. Since the total charge is merely a compilation of the charges associated with the various tariffs attached to the particular product or service, some or all of the product or service attributes influence the charge component generated by each of the various tariffs attached to the product or service offerings. Because some or all of these attributes are different for different product or 4 service offerings, the calculation of charges for tariffs will be different from one product to the next. In the past this has required different formulas and different inputs for calculating each tariff for each product variant. This requires extensive changes to the billing system environment each time a new product or service or a new product of service variant is created. In many cases new tables must be added to the database or extensive changes must be made to existing tables to in order to accommodate new product or service configurations and new tariff configurations. In the SingleView package and other billing packages, the charging logic must be configured as a hard coded logic. Expensive both in terms of the resources required to implement the new product or service offerings, as well as the amount of time necessary to implement the changes, Implementing the 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 attracting new customers and retaining existing customers, the delay and costs involved in rolling out new products and services can be very detrimental to a telecommunications service provider's performance. The present invention provides an improved mechanism for configuring new products and services and internal charge event tariffs associated therewith and for calculating the charges associated with such tariffs. SUMMARY OF THE INVENTION The present invention provides a charging framework for improving the functionality of a telecommunications service provider's billing system. A particular embodiment of the invention is configured to improve the functionality of the SingleView billing package. The charging framework facilitates the configuration of new product and service offerings and the billing tariffs associated therewith, and provides a single charging function for calculating the charges for all internally generated billing events.

-5 The charging framework provides a structured approach to configuring any kind of documented billing tariff. A great deal of time and resources is saved using this approach since all low level billing tariff objects are already created and defined within the charging framework and are immediately ready for use. Such objects 5 include a predefined derived attributes table, a charging function for calculating tariff charges attribute types, reference types, forms, variables, and so forth. When configuring a new tariff the only effort required to support a new product or service offering list to define the price applied to the tariff. No effort is expended on defining all of the hidden underlying objects. The framework may also improve 10 performance of the billing system. The entire set of tariff parameters at the charging level may be cached in memory, thereby reducing processing times and conserving database resources. In one aspect, the present invention provides a system extension for a billing 15 system adapted to generate customer bills associated with the delivery of telecommunications products and services, wherein the billing system includes software instructions adapted to be executed on a computer server platform, a database for storing product configuration data for a plurality of product offerings and charging tariffs attached to the product offerings, and a user interface allowing a 20 user to interact with and configure portions of the billing system, the system extension including an editable derived attributes table that identifies unit charge rates for tariffs attached to the plurality of product offerings through association with a plurality of offer parameters of each product offering defined by the product configuration data, composite index keys assembled from the plurality of offer 25 parameters of each product offering for accessing the unit charge rates for the tariffs attached to each product offering; and a charge calculation function operable to, for each product offering, assemble the composite index key from the respective plurality of offer parameters; access the editable derived attributes table to determine the unit charge rate identified by the assembled composite index key , and calculate the 30 charge amount for the tariff attached to that product offering based on the unit charge rate identified from the editable derived attributes table using the assembled composite index key.

-6 In another aspect, the present invention provides a method including attaching, by a processor, a tariff to a telecommunication product offering, wherein a plurality of offer parameters of the telecommunication product offering and the tariff 5 define a set of parametric attribute values, implementing, by a processor, an editable derived attributes table stored in a computer memory that stores the set of parametic attribute values and identifies a unit charge rate for the tariff attached to the telecommunication product offering through association with the set of parametric attribute values, assembling, in the computer memory by the processor, a composite 10 index key from the set of parametic attribute values for accessing the unit charge rate for the tariff attached to the telecommunication product offering, accessing, by a processor, the editable derived attributes table to determine the tariff identified by the assembled composite index key, returning the unit charge rate of the identified tariff, by the processor querying the editable derived attributes table based on the 15 identified tariff, and calculating, by the processor, a charge based on the unit charge rate. Other systems, methods and features of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and 20 detailed description that describes one or more embodiments of the invention. It is intended that all such additional systems, methods and features included within this description, be within the scope of the invention, and be protected by the claims that follow this description. 25 BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows an example of a pre-defined configurable charging tree; Fig. 2 shows a screen shot from the Singl.eView GUused to configure tariffs showing a Tariff Configuration Page with the SETTINGS tab selected; 30 Fig. 3 shows a screen shot from the Singl.eView GUIused to configure tariffs showing a Tariff Configuration Page with the CHARGES tab selected; -7 Fig. 4 shows a screen shot from the Singl.eView GUI used to configure tariffs showing a Tariff Configuration Page with the ACTIVATION tab selected; 5 Figs. 5A and 5B show separate portions of a Derived Attributes Table displayed by the Singl.eView GUI used to configure tariffs; Fig. 6 shows a workflow diagram of the charging process implemented on the charging framework of the invention; and 10 Fig. 7 shows a charging framework process flow chart.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION The present invention relates to a charging framework for calculating charges associated with the delivery of telecommunications services. The charging framework serves as an extension of a telecommunications service provider's billing system and provides a thin easy to use configuration platform designed to reduce the amount of time required to configure new product and service offerings. The charging framework provides a uniform method of defining and calculating charges associated with charging tariffs attached. An embodiment of the invention is specially adapted for use with Accenture's ACS for billing solution which is based on Intec's Singi.eView for convergent billing. Singl.eView is a sophisticated billing system configured to run on a Unix based application server in conjunction with an Oracle database. The charging framework of the present invention is a software layer that sits above Singl.eView Billing system. It should be noted, however, that the charging framework of the present invention is not limited to extending only the Singl.eView billing system only. The advantages and novel features of the charging framework are adaptable for use with other billing systems based on the same or other hardware platforms. The charging framework of the present invention provides a standardized structured approach to configuring the charging tariffs associated with product and service offerings. The structured approach significantly reduces the time necessary to configure new tariffs and new product and service offerings because all of the low level tariff objects such as a common charging function, attribute types, reference types, forms, variables, and a unique derived attributes table, are already complete and ready to be drawn upon when new tariffs are created. When configuring a new tariff the only substantial effort required to support a new product offering is to define the price associated wilh the tariff. Furthermore, the structured approach to configuring tariffs allows a single common charging function to be applied to calculate the charges associated with the various tariffs attached to different product and service offerings. The single common charging function simplifies the process of configuring 9 new product and service offerings and reduces the complexity of the processes necessary to calculate the charges associated with specific product and service nstances. The charging framework calculates charges for internally generated events such as recurring monthly charges, activation fees, deactivation fees, and the like. Internal events are those that arise within the billing system itself. Charges associated with external events, such as usage charges, which require input from external source such as external network switches are calculated separately. The charging framework calculates the price of recurring and non-recurring events on the basis of specific product and service attributes according to a predefined configurable charging tree, The predefined charging tree according to an embodiment of the invention is shown in Fig. 1. The charging 10 shows the parameters that contribute to the calculation of a charge amount associated with a tariff attached to a particular product or service. The higher level inputs include a charging plan 12, a product or service instance 14, and a charge period 16. The charging plan 12 includes data regarding both the product and the tariff attached to the product. The charging plan 12 provides the product name 18, a charge event type 20, and if necessary a charge event sub-type 22. For example, a product name might be "DSL High Speed Access." A tariff attached to the DSL high speed access product might be a recurring monthly service fee, The charge event type associated with the tariff therefore might be "recurring" and the charge event sub-type "DSL High Speed Access Recurring." The product or service instance 14 relates to a specific product or service offering that is sold to a customer, The product or service instance provides at least one charging parameter that defines various attributes of the specific product or service instance. The charging parameters associated a product or service instance contribute to the calculation of the charge amount associated with the tariff. Charging parameters associated with a specific product or service instance might include things such as the price list applied to the product or service instance e.g., gold or silver, or the bandwidth allocated to the product or service instance, or other product attributes.

10 According to an embodiment of the invention a product or service instance may include up to six charging parameters 24, 26, 28, 30, 32 and 34. However, in some cases product or service instances may be configured without any charging parameters. The product name 18, charge event type 20, charge event sub-type 22, and charging parameters 24, 26, 28, 30, 32, and 34 form a composite index key for locating a unit charge rate 36. The charge period 16 is a quantifying factor that is generated by the billing system and identifies the number of base time units for which a charge is to be calculated. For example, a tariff associated with a particular product may require a recurring monthly fee. The service, however, may only be billed on a bi-monthly basis. In this case, when the bill is prepared the charge for the recurring monthly fee must be doubled to account for the two month billing period, Accordingly, the charge period would be set to 2. The final charged amount 38 is calculated by multiplying the identified unit charge rate 36 by the charge period 16. As mentioned above, the charging framework forms an extension of a telecommunications service provider's billing system. The charging framework provides a single charging function for calculating the charges associated billing tariffs according to the predefined charging tree described above, and a unique charging function that accesses an editable derived attributes table for determining the unit charge rate to be applied when calculating charges for specific tariffs. The derived attributes table is accessed according to a composite index key that includes the product name, the event type and sub-type, and up to six charging parameters, as outlined in the charging tree of Fig. 1. All product and tariff configurations must be represented in the derived attributes table, so that when a charge associated with a tariff is to be calculated the corresponding unit charge rate can be found. The derived attributes table may be stored in the database associated with the billing system, however, the whole set of tariff parameters used at the charging level may be cached in memory in order to support the maximum flexibility in the way new product offerings are configured while also providing the best performance.

Product and service offerings are configured within the billing system with the aid of a graphical user interface (GUI). The product or service configuration establishes the product name, identifies the tariffs associated with the product or service, and defines the charging parameters that are available to define individual product or service offering. Preferably the charging parameter values selected for a particular product or service offering are selected from a predefined list of available parameter values in order to facilitate the configuration of new product and service offerings and the tariffs associated therewith. When a product or service is sold to a customer, the charging parameters that form the complete offering define the specific product or service instance associated with the customer. The tariffs attached to the various products and services are configured in the charging framework using the billing system GUI. Figs. 2, 3, and 4 show various screen shots frorn the Singl.eView billing system GUI related to tariff configuration. It should be noted that the tariff configuration screens of the billing system GUI are adapted to configure tariffs in the presence or absence of the charging framework of the present invention. Configuring a tariff without the aid of the charging framework is a much more complicated task. Accordingly, the tariff configuration pages of the billing system GUI contain many fields which are unnecessary when configuring tariffs in the charging framework. The description that follows is limited to those aspects of the tariff configuration GUI pages that are relevant to configuring a tariff within the context of the charging framework. Configuring a tariff within the charging framework includes, among other things, identifying the product name of the product or service to which the tariff is attached, and defining the charge event type and charge event sub-type associated with the tariff. Each of the screen shots in Figs. 2, 3, and 4 includes a tariff definition section 50. The tariff definition portion 50 includes a name field 52 for entering a Name for the tariff being configured. A Description field 54 is provided for entering a brief description of the tariff. Start Date and End Date fields 56, 58 are provided for specifying the time period during which the tariff will be in effect. If no date is specified in the end date field 58, the tariff may be in effect indefinitely. Finally, a 12 Version field 60 allows the user configuring the tariff to define or assign a version designation to the tariff. A series of selectable tabs 62, 64, 66, 68, and 70 control the fields displayed on the remainder of the tariff configuration page. Fig. 2 is a screen shot of the Singl.eView GUI display with the Settings tab 62 selected. From the tariff settings tab a user configuring a new tariff may select a tariff class, and enter a number of functional settings for the tariff. A tariff class may be defined by selecting one of the selectable tariff classes listed in a tariff class definition area 72. In the example shown, a tariff may be classified a standard; recurring; activation; or cancellation tariffs. Settings include the tariff type 74, status 76, priority 78; data type 80, application 82, context 84, and charge category 86. The tariff type 74 may be selected from list of pre-defined tariff types provided in a drop down menu associated with the tariff type field 72. The tariff type is limited to only those types that have been previously defined and are listed in the drop down menu. Examples of the selections that may be made for the tariff type field 74 include: Usage; recurring; one-off; discount; on-time discount; early payment discount; tax; or commission. The tariff status is entered in the status filed 74. Again, the status that may 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 maybe entered in the status field include: Active (the tariff is in use); or trial (the tariff is being tested). The type of data associated with the tariff is defined in the Data Type field 78, again selections are limited to the predefined data types listed in the corresponding drop down menu. Examples of data types include: Real; Real Array; or Real Hash. The application for which the tariff is intended is identified in the application field 78. Application entries are also limited to predefined applications listed in the drop down menu accompanying the application field 82. A typical list of applications include: Rating; 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; Customer Node; or Service. Tariffs based on the tariff type "usage" would generally be assigned to the application environment "Rating," and the context "Normalized Event." Tariffs based 13 on other tariff types will generally be assigned to the application environment "Billing" and one of the contexts "Customer," "Customer Node," or "Service." A charge category may be defined in the charge category field 84 where again the selection of possible charge categories is limited to pre-defined charge categories found in the accompanying drop down menu. Examples include: ACS Default EUR, CLEC Default. The currency in which a tariff charge is calculated may be entered in the currency field 84. An invoice section code may be entered in the invoice section field 86 to define where charges associate with the tariff will appear on a bill, and text describing the source of the charge may be entered in the default invoice text field 88. Fig. 3 shows the Singl.eView GUI tariff configuration page with the Charges Tab 66 selected. This page allows the user to enter charging expression to define the manner in which the charge associated with the tariff is calculated. However, within charging framework all internal tariff charges are calculated using a single charging function. Thus, a single function call is entered in the Default Charge Expression field 92. The, the function call identifies the function being called and the product name to which the tariff is to be attached. Thus, in the example shown in Fig. 3 the Default Charging Expression 92 includes the charging function name ACSChargingframeworkallservices V2.2, and the product name ACS DSL Lite Access Activation (Gold) to which the tariff being configures is attached. Fig. 4 shows the Singl.eView GUI tariff configuration page with the activation tab 94 selected. A normalized event type associated with the tariff is defined in the normalized event type field 96. A normalized event is an object created by the billing system whenever a charge associated with the tariff must be calculated, The normalized event type specifies the type of recurring charge to be generated when the tariff is invoked. The specified normalized event type determines the manner in which the normalized event is formatted. Normalized event types are configurable and may be selected from a list of pre-configured normalized event types contained in a drop down menu associated with the normalized event type field 96. Examples of 14 predefined normalized event types include: CLEC (Competitive Local Exchange Carrier), MRC (Monthly Recurring Charge) and NRC (Non-Recurring Charge), and so forth. Moreover it should be noted that these are merely labels that have been defined when configuring normalized event types. The tariff event type and event sub-type are defined in the Event Type and Event Sub-Type fields 98, 100 respectively. Again, the event type and event sub-type maybe selected from predefined lists of event types and event sub-types contained in drop down menus associated with each field. Examples of predefined event types include: CLEC Non Recurring; and CLEC Recurring. Examples of predefined event sub-types include: ACS ADSL Modem Activation; and ACS ADSL Recurring. An adjustment event type and an adjustment event sub-type may be defined in the adjustment event type and adjustment event sub-type fields 102, 104. Again, selections are limited to predefined adjustnient event types and adjustment event sub-types contained in the corresponding drop down menus. Finally, an entity type may be selected by making a selection from among the various entity types listed in the entity type selection block 106. The entity type defines the type of entity with which the tariff will be attached, such as it a product, a service, equipment or other. A final component of configuring products and tariffs in the charging framework is updating the derived attributes table. As mentioned above, the derived attributes table defines the unit charge rate to be applied for every configured tariff attached to every configured product. Accordingly, if a new tariff is configured the derived attributes table must be updated to reflect the change. Figs. 5A and 53 show a portion of a derived attributes table 200 according to an embodiment of the invention. The derived attributes table includes a plurality of columns defining the data variables necessary to distinctly identify every tariff associated with every product offering configured in the billing system, the unit charge rate associated with each tariff, and anyadditional charging information relevant to calculating the charges associated with each tariff. Thus, the column headings for the derived attributes table include the product name 202, the event type 204, the event sub-type 206, General 5 Charging Parameter (tariff ID) 208; General 6 Charging Parameters 210; General 7 Charging Parameter (not shown); General 8 charging parameter (not shown); General 15 9 charging parameter (not shown); General 10 Charging Parameter 212, Unit Rate 214, Charge Description 216; Charge info. 1 218; and Charge Info 2, Charge Info 8 (not shown). Each row of the derived attributes table represents a tariff attached to a particular product or service offering. The derived attributes table is accessed based on a composite index key comprising the product name, event type, event sub-type, and charging parameters 1-6 (General 5 - General 10) and returns corresponding charging information including the unit charge rate the charge description and charge info 1-8. When a unit charge or other charging information for a particular tariff must be retrieved, the row of the derived attributes table that stores the same and the unit charge rate and other charging parameters stored in that row are returned as results. Thus, the derived attributes table functions as a large look up table for identifying the unit charge rate and other charging information for every tariff configures in the billing system. The advantages of storing unit charge rates and other charging information in the derived attributes table will become apparent when one considers the processes involved producing a bill and calculating the charges associated with internally generated billing events. Fig. 6 is a workflow diagram illustrating the charging process implemented at the tariff level by the charging framework of the present invention. Fig. 6 shows processing steps 220, the corresponding processing parameters 222, and a simplified derived attributes 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 having a recurring monthly charge, the amount of the monthly charge must be calculated each month when the customer's bill is generated. The recurring monthly tariff generates an internal event that must be priced. The processing parameters 228 associated with the generation of internal normalized events include the input parameters Charge Event Type; Charge Event Sub-Type; And Product/Service 16 Charging Parameters 1-6. The output result of the internal normalized events generation is the internal normalized event itself. The internal normalized event is represented as a row of an oracle database table normalized event. Table created and updated 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 has been generated, the next general processing step is to calculate the unit charge rate associated with the event. The input parameters to the unit charge rate calculation step are the product name, charge event type, charge event sub-type, and product/service charging parameters 1-6. These input parameters are used as the composite index key to access the derived attributes table to identify the appropriate row corresponding to the generated event and return the corresponding unit charge rate. For example, suppose a normalized internal event is generated with the product name Fast Access DSL Lite having a charge event type "recurring," event sub-type Fast Access DSL Lite Recurring, and wherein the charging parameter 1 (internal normalized event general 5 parameter) is Gold. A query of the simplified derived attributes table 224 with the specified composite index key would identify the first row 238 of the simplified table 224, and return a unit charge rate of ISE. Similarly, suppose a second internal normalized event has a product name Fast Access DSL Lite, a charge event type "Recurring," a charge event sub-type Fast Access DSL Lite Recurring, and a charging parameter I (internal normalized event general 5 parameter) Silver. A query of the derived attributes table 224 with the specified composite index key of this second internal normalized event would identify the second row 240 of the simplified derived attributes table, and return a unit charge rate of 226. Once the unit charge rate has been calculated the final processing step is calculating the charge amount 234. The input parameters 236 associated with this step are the charge period and the unit charge rate. As mentioned above, the charge period is generated by the billing system itself. The unit chart rate is returned 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 17 may be used by the billing system to generate an invoice or bill to charge the customer for the particular product or service that generated the normalized event. Fig. 7 is flow chart 300 showing the operation of the charging framework in the context of generating a customer bill, The billing process begins when a billing run is initiated at 302. During the course of a billing run the products associated with each customer are identified and the relevant charges associated with each product are calculated to generate bills that may be sent to the customers. The billing system pulls 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 of the charging parameters associated with the product or service offering, comprises a product or service instance, A rental generation process (RGP) is triggered at 304 by each internally generated tariff, such as tariffs for recurring charges, one-time activation fee, and the like, The ROP process is the trigger that indicates a charge must be calculated. Tariffs attached to the products owned by a customer generate normalized internal events at 306. Generating a normalized internal event comprises adding a row to an Internal NormaliLed Events Table within the billing system. The normalized events table includes a number of general data fields, in particular normalized event general 5 through normalized event general 10 fields which can be used to store charging parameter data at 308. The normalized event is guided to the product configuration data of the particular product or service instance for which a charge is to be calculated based on the product name defined in the tariff that initiated the internal normalized event. The internal normalized event is enriched with the charging parameters of the particular product or service instance. Specifically the charging parameters from the product configuration of the product or service instance are written to the normalized event general 5 - normalized event general 10 fields of the internal normalized event. The product, product name, event type and event sub-type are received from the configuration of the tariff itself.

Next, the tariffs are filtered at 310 based on factors such as the application, environment, context, priority and eligibility. Eligibility is a parameter that may be defined when a tariff is configured. A tariff's eligibility is used to set-up a list of expressions that must be satisfied for the tariff to be applied. In particular, using the eligibility expression list, it is possible to filter out tariffs that are not eligible for specific normalized events. Within the charging framework, eligibility is used to ensure that the correct tariffs are applied, by setting up the eligibility expression list in order to filter the tariffs based on the event type and event sub-type, present in the normalized event that is being processed. Once the tariffs have been filtered, the tariff is applied by invoking the standardized charging function at 312. All internal tariff events are processed in the same manner by the ACS charging function, Internal normalized events are scanned at 314 to generate the composite key for accessing the charging framework Derived Attributes Table. Thus, the composite index key includes the product name, event type, event sub-type and any charging parameters stored in the normalized event general fields 5-10. The Derived Attribute Table is accessed at 316 and returns results that include the unit charge rate and any relevant charge information. The charge amount is calculated at 318 by multiplying the returned unit charge rate by the duration. As mentioned earlier, the duration is a parameter supplied by the billing system and indicates how many billing units apply, for example, a monthly fee billed every other month would have a duration of 2 so that the total charge would be twice the unit charge rate, At 320 the final charge amount and any additional charge data returned from the derived attribute table are passed to a billing process that applies the calculated charge to the bill that is being processed. Finally, the billing process ends at 322 with the generation of the billing data.

19 For completeness of disclosure the source code for the charging framework charging function according to an embodiment of the invention is presented below. #NAME: # faces_ TP ChargingFramework## # DESCRIPTION. # This function delonnines the 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/product name # 2/ Event Type (from event) 3/ Event Sub Type (from event) # general 5 (Tariff ld) (from NORMALIZED EVENT GENERAL 5 field) # general 6 (from NORMALIZED EVENT GENERAL 6 field) # general 7 (from NORMALIZED EVENT GENERAL 7 fiefd) 7/ general 8 (from NORMALIZED EVENT GENERAL 6 field) # general 9 (from NORMALIZED EVENT GENERAL 9 field) general 10 (from NORMALIZED EVENT GENERAL 10 field) # PARAMETERS # product namne # RETURNS # Charge

#---------------------------------------------

20 fAC$_ChargingFramework-AllServices)12.2#(const ProductameS) var I-Charge# 0.00: var l-Results?[]; var I -MRCJ ndex?[l; coflst IMRCDA$ : 'dACSChargngFrameworkV2. 0'; var I Pro ductF ieldValuesf]; # Define index for lockup lMRClndex$(0J = ProductName$s; IMRC-lndex&f1j= EventTypeCode&; IMRCjndex&(2]: Even tSu bTypeCod e&; # 'Any* If (General5$ then ()MRCIndex$[3] 'N UL L';) else (rMRClndex$[31 GeneraI5$sj; If (General6$ - " then (IM!RCndex$(41 'NULL';) else (I-MRCIndex$[41 General6$;); If (General7$= ) then {IMRClndex$15] 'NULL';) else {IMRCeIndex$[5J Generat7S;);. If (General8$ =" then (IMRCIndexS[6] 'NULL';) else (lMRCIndex$[6J General8$; If (Genera9$ then (IMRClndex$[7] := 'NULL';) else {IMRClndex$[7] Genera9$}, If (General 10$ = " then (IMRCjndexS[8] 'NULL';) else (IMRCjndex$[8] : GenerailO$:);. If DerivedTableLookupByDatex&(MRC_DA$, ChargetartDate-, IMRC-lndex?[], ]_Results?[)) 21 then lCharge# := I|Results#[o)*Duration#; # assign return values to DA vairbales dACSChgFrarnework_Genera1$ := to.string(I_Results?[O)); dACS-ChgFrameworkGenera2$ := to-string(lResults?[11); dACSChgFrameworkGenera13$ := to -string(lResults?[2]); dACSChgFrameworkGeneral4$:= to-string(IResults?[3]); dACSChgFrameworkGeneral5$ := tostring(lResuts?[4J); dACSChgFrameworkGenera6$ to-string(IResults?(5]); dACSChgFramework-Genera17$ to-string(IResults?[6]); dACSjChgFrarmeworkGenera8$ tostring(IResults?7) } return ICharge#; The standard charging function and the derived attribute table allow tariffs to be configured and implemented much more easily and allows the charges associated with internal tariff events to be calculated in a much more efficient manner than in traditional billing systems. While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents. Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

22 The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form or suggestion that the prior art forms part of the common general knowledge in Australia.

Claims (26)

1. A system extension for a billing system adapted to generate customer bills associated with the delivery of telecommunications products and services, wherein 5 the billing system includes software instructions adapted to be executed on a computer server platform, a database for storing product configuration data for a plurality of product offerings and charging tariffs attached to the product offerings, and a user interface allowing a user to interact with and configure portions of the billing system, the system extension including: 10 an editable derived attributes table that identifies unit charge rates for tariffs attached to the plurality of product offerings through association with a plurality of offer parameters of each product offering defined by the product configuration data; composite index keys assembled from the plurality of offer parameters of each product offering for accessing the unit charge rates for the tariffs attached to 15 each product offering; and a charge calculation function operable to, for each product offering: assemble the composite index key from the respective plurality of offer parameters; access the editable derived attributes table to determine the unit 20 charge rate identified by the assembled composite index key; and calculate the charge amount for the tariff attached to that product offering based on the unit charge rate identified from the editable derived attributes table using the assembled composite index key. 25

2. A system extension according to claim 1 wherein the key parameters include: an event type entry that identifies a recurring charge type to be generated when the tariff attached to the telecommunication product offering is invoked; an event sub-type entry that identifies a sub-type of the recurring charge type; and 30 a charging parameter that distinguishes telecommunication product instances. 24

3. A system extension according to either claim 1 or claim 2 wherein the derived attributes table is adapted to store configuration parameter values for a plurality of configured tariffs. 5

4. A system extension according to claim 3 wherein the configuration parameters relate to input composite key parameters and at least one output results parameter.

5. A system extension according to claim 4 wherein the input composite key 10 parameters further include a product name entry that identifies the telecommunication product offering.

6. A system extension according to either claim 4 or claim 5 wherein at least one output results parameter includes the unit charge rate. 15

7. A system extension according to claim 6 wherein the charging function includes multiplying a unit rate charge returned from the derived attributes table by a quantifying value. 20

8. A system extension according to any one of claims 1 to 7 wherein the derived attributes table stores a product name, an event type, a first charging parameter, and a unit charge rate for a plurality of configured tariffs, and the charge calculation function identifies the product name, event type, and a first charging parameter for a tariff for which a charge must be calculated, accesses the derived attributes table to 25 extract the unit charge rate value associated with a tariff configured in the derived attributes table having same product name, event type, and first charging parameters as the product name, event type and first charging parameter identified by the charging function for the tariff for which a charge must be calculated. 30

9. A method including: attaching, by a processor, a tariff to a telecommunication product offering, 25 wherein a plurality of offer parameters of the telecommunication product offering and the tariff define a set of parametric attribute values; implementing, by a processor, an editable derived attributes table stored in a computer memory that stores the set of parametric attribute values and identifies a 5 unit charge rate for the tariff attached to the telecommunication product offering through association with the set of parametric attribute values; assembling, in the computer memory, by the processor, a composite index key from the set of parametric attribute values for accessing the unit charge rate for the tariff attached to the telecommunication product offering; 10 accessing, by the processor, the editable derived attributes table to determine the tariff identified by the assembled composite index key; returning the unit charge rate of the identified tariff, by the processor querying the editable derived attributes table based on the identified tariff; and, calculating, by the processor, a charge based on the unit charge rate. 15

10. A method according to claim 9 wherein the set of parametric values includes: an event type parameter that identifies a recurring charge type to be generated when the tariff attached to the telecommunication product offering is invoked; 20 an event type sub-type parameter that identifies a sub-type of the recurring charge type; and a charging parameter that distinguishes telecommunication product instances.

11. A method according to claim 10, wherein the set of parametric attribute 25 values further includes a product name parameter that identifies the telecommunication product.

12. A method according to claim 11, wherein the set parametric attribute values for identifying the tariff includes values for a plurality of charging parameters, and 30 configuration data for the telecommunication product offering includes defined values for the same plurality of charging parameters. 26

13. A method according to either claims 11 or claim 12 further including creating an event record based on execution of the tariff, wherein the event record receives and stores values for the product name, and the event type from the configured tariff. 5

14. A method according to claim 13 further including enriching the event record with the defined parametric attributes value for the charging parameter.

15. A method according to any one of claims 9 to 14 further including: 10 creating, in a memory by the processor, a normalized event record in response to the tariff, the normalized event storing data regarding the tariff and the telecommunication product offering.

16. A method according to claim 15 wherein: 15 the normalized event record receives and stores the product name value and the event value from the tariff and the charging parameter value from the telecommunication product offering.

17. A method according to claim 16 wherein: 20 assembling the composite index key includes assembling the composite index key based on the product name value, event type value, and the charging parameter value stored in the normalized event record.

18. A method according to any one of claims 9 to 17 wherein calculating the 25 charge includes multiplying the base charge by a quantifying factor.

19. A method according to any one of claims 9 to 18 further including: configuring, by the processor, the telecommunication product offering, wherein the telecommunication product offering includes a product name parameter, 30 a tariff parameter, and a telecommunication charging parameter; wherein the tariff identifies an event type, wherein the tariff is identified by 27 the tariff parameter of the telecommunication product offering: generating, in the memory by the processor, a normalized internal event based on the tariff; enriching, by the processor, the normalized internal event with a charging 5 parameter value from the telecommunication charging parameter of the telecommunication product offering; and invoking, by the processor, a charging function configured to: assemble the composite index key, the composite index key stored in a computer memory including key parameters for uniquely identifying a 10 tariff; identify the normalized internal event, by the processor comparing a set of values to values of the key parameters from the composite index key; obtain the unit charge rate from the normalized internal event; and calculate, by the processor, the charge from the obtained unit charge 15 rate and a quantifying factor.

20. A method according to claim 19, wherein the key parameters include: a product name entry that identifies the telecommunication product offering; 20 an event type entry that identifies a recurring charge type to be generated when the configured tariff is invoked; and a charging parameter that distinguishes telecommunication product instances. 25

21. A method according to claim 20 wherein the derived attributes table includes a plurality of rows and columns, the rows corresponding to configured tariffs and the columns corresponding to attribute parameters and a unit charge rate associated with each of the tariffs and the products with which they are associated, each tariff in the table being identifiable by a unique set of attribute parameter values stored in the row 30 corresponding to the particular tariff. 28

22. A method according to claim 21 wherein obtaining the unit charge rate for a tariff includes identifying a row in the derived attributes table storing attribute parameter values corresponding to the product name, event type, and charging parameter of the tariff and the product with which it is associated, and returning the 5 unit charge rate value stored in the identified row.

23. A method according to any one of claims 19 to 22 wherein generating a normalized event includes creating a normalized event record adapted to store attribute parameter values associated with the tariff and the product that includes the 10 tariff.

24. A method according to any one of claims 19 to 23 further including: accessing, by the processor, the derived attributes table with the composite index key; and 15 returning, by querying the editable derived attributes table using the processor, the unit charge rate associated with the tariff identified by the composite index key.

25. A system extension according to claim 1, or a method according to claim 9, 20 substantially as hereinbefore described with reference to the accompanying figures.

26. A computer readable medium including instructions which when executed by a billing system, cause the billing system to perform the method of any one of claims 9 to 24.