NZ523955A - Flexible consolidated billing and charges allocation for accounts processing applications - Google Patents

Abstract

A method and apparatus direct to accounts processing applications, which enable redirecting of charges between accounts without adversely affecting the performance of the application. A repository stores the individual requirements of customers of a service provider in relation to the redirection of specific types of charges between accounts, as well as service usage and charges information. Before processing account charges for a set of accounts assigned to a billing cycle, a snapshot is taken of the charges-redirection requirements of the set of accounts. This snapshot is then used when processing account charges, to enable redirection without locking the charges database or the front end processes for updating relationships between accounts.

Description

1 JP920020226 METHODS. APPARATUS AND COMPUTER PROGRAMS FOR FLEXIBLE CONSOLIDATED BILLING AND CHARGES ALLOCATION FOR ACCOUNTS PROCESSING APPLICATIONS Field of Invention The present invention relates to methods, apparatus and computer programs for billing or other account processing applications which enable redirecting of charges between different accounts.

Background Service provider companies have recognized for many years that each of their business and personal customers have different requirements and use their services in different ways. For example, an Internet Service Provider (ISP) will have a range of customers from occasional home users who go for days without use to large corporate users with heavy demands every hour of the working day. The ISP provides a range of billing options to cater for the different types of usage, and to compete with the charges of competitive ISPs. Requirements for flexible billing solutions can be expected to increase in line with increased availability of services and content accessed via a network, such as Web Services and Grid Services, and the increasing convergence between communications and content service provision.

Customer Care and Billing applications in the telecommunications and media service industries cater for billing customer accounts periodically for a variety of charges. These charges can be usage related - for example, local calls, international calls, CATV 'Pay Per View' charges, etc - or may relate to services & equipment provided to the customer such as, for example, line rentals, equipment rentals etc.

There is a need within industries such as the telecommunication industry to redirect selected types of charges owned by a customer account to another account's invoice in 523955 2 JP920020226 order to provide flexible payment options. For example, a business customer may wish to pay for local call charges and telephone line rental charges incurred by all its employees.

Known software solutions to charges redirection do not provide sufficient flexibility to meet the needs of businesses. Known solutions typically only allow entire charges of an account to be redirected to another account. Even if selection of charges is allowed, this selection is restricted to only specific service & equipment charges.

For example, CSG Systems' Kenan™/BP is a billing product that caters for redirecting charges to another account, at the level of either (i) all charges to one payer, or (ii) line rental to one payer and call charges to a second payer. This solution does not provide the flexibility that will be required for future business needs.

IBM Corporation's ICMS™ customer management and billing system and Portal Software, Inc's Infranet™ customer management and billing product are further examples of known products in this area. Information regarding these products can be obtained from IBM Corporation's and Portal Software's respective Websites.

US Patent No. 6,240,402 describes charge allocation in a multi-user network including support for different charging schemes (sender pays, receiver pays, charges are shared, or third party pays). Source and destination identifier fields are monitored by a central monitoring point to determine which charging scheme is required. The network operator associates charging schemes with recipient identifiers, with the usual default that the call initiator pays.

US Patent No. 6,092,055 describes real-time billing systems and a solution to the problem of ensuring a clean cut-off between executions of the billing process. The solution involves locking accounts while they are being billed.

US Patent No. 5,822,411 describes changing the party by whom telecommunications charges are to be borne in response to approved change variation request signals. 3 JP920020226 CSS Hotel Systems utilize a Group Management Module to group hotel reservations in a number of classifications. Group accounting within the CSS System includes a transaction routing routine to redirect specific charges from folios for group members to a billing folio; redirected charges reflect which account they came from. This routing of charges may be set to occur as the charges are posted or at check-out time.

US Patent Application No. 2001/0056362 describes a customer care and billing system which is capable of providing billing related information to customers for all of a customers electronic transmissions and, more particularly, a system of functionally complete components that can stand alone or be integrated together and which aggregates all of the telecommunication services, of a customer into a single genus of electronic transmissions having species associated with the type of electronic transmission, such as wireless.

US Patent No. 5,815,560 describes a communication service control apparatus which can flexibly control a charging method for each connection of call by concentrically controlling and managing the charging information. This publication describes the flexible charging control which selects the charging system for each call or decides the charging objects depending on a request from subscribers in view of recording a communication service tariff such as communication tariff in various manners.

US Patent No. 5,646,984 describes a payer-variable exchange system, more specifically an exchange system which connects two or more communicators to provide them with communication services in which a communicator can change the payer of the communication fee during the communication to charge the communication fee to a single or a plurality of communicators. 523955 4 JP920020226 Summary According to a first aspect of the invention, there is provided a method for redirecting charges between accounts for an accounts processing application. The method includes the steps of: storing account information in a repository for each of a plurality of accounts, including storing charges information against accounts within the plurality and storing requirements for redirecting of specific types of charges between accounts; retrieving from the repository the requirements for redirecting of specific types of charges between accounts within a first set of accounts, and storing the retrieved requirements; and performing the steps of (a) for a first account within the first set of accounts, using the retrieved requirements to identify charges stored against the first account which require redirection to a different account; (b) processing the charges information stored against the first account except for identified charges stored against the first account which require redirection to a different account; (c) for each account within the first set of accounts other than the first account, processing any charges stored against any one of the other accounts which charges require redirecting to the first account, as determined by the retrieved requirements; and repeating steps (a) to (c) for each account within the set.

A second aspect of the invention provides a data processing apparatus including: an interface for specifying requirements for redirecting of specific types of charges between accounts; a repository for storing account charges for each of a plurality of accounts and for storing the requirements for redirecting charges between accounts; a data retriever for accessing the repository to retrieve the requirements for redirecting charges between accounts for a first set of accounts, and for storing the retrieved requirements; and program code for controlling processing of charges information for the first set of accounts with reference to the stored retrieved redirection requirements - as described in the method steps above.

The retrieval from the repository of a subset of redirection requirements information relevant to the set of accounts to be billed in a billing cycle is advantageous for enabling faster accounts processing than if a full charges database were to be scanned to determine 523 JP920020226 an appropriate billing account during processing of the charges. A particular operational sequence of preferred embodiments of the invention, in which steps (b) and (c) are performed separately following step (a), is also advantageous for efficient charges processing.

Preferred embodiments of the invention provide solutions for redirecting selected types of charges from a first account to another account, for account processing purposes such as billing or accounting, without adversely affecting the performance of the billing or accounting process. Charges within an account processing system are associated with a charge type, and charges redirection requirements are input to the system for specific charge types and specific accounts. A snapshot is taken of the current charges redirection requirements for an account or set of accounts to enable billing or accounting to be processed for that account or set of accounts. Execution of the billing or accounting processes is then carried out, redirecting charges as required by referring to the stored snapshot of account-specific information. This solution can be implemented to enable execution of a billing process without closing or locking the requirements-specification functions or the database of charges. The snapshot of requirements for charge-type-specific redirecting of charges between accounts is referred to hereafter as a snapshot of "relationships" between accounts.

In preferred embodiments, methods and computer programs implementing the invention are sufficiently flexible to allow selection from a range of different types of customer's charges to be redirected to another account's invoice. The target invoice account may be another account within the same customer or may belong to a different customer.

In particular, preferred embodiments enable grouping of charges to a customer-specified category and redirecting the charges belonging to the category to another account's invoice statement.

The solution design, according to preferred embodiments, caters for a large volume of usage related data that is processed when billing accounts, such as the large data volumes 523955 6 JP920020226 which are common in the telecommunication industry. The solution design is consistent with providing support 24 hours a day and 7 days per week (24x7), such as is required for telecommunication applications, and avoids the need to close front-end systems during billing.

To provide a flexible method of grouping charges, preferred solutions allow assigning of a Charge Type and a Sub-Charge Type to charge items in the system. A business customer can determine the Charge Types and Sub Charge Types that will be used to govern the grouping of charges for redirection. As listed in the example payment options below, a consolidated billing relationship can be set up to redirect a specific charge item (line rental for example) or a group of charges belonging to a Charge Type (for example, all Telephony Calls) or a group of charges belonging to a Sub Charge Type (for example, all Telephony Direct Dial calls).

Preferred embodiments allow specification of only charges belonging to one or more services within an account to be redirected. Thus a business customer may choose to pay only for all local calls relating to the first telephone line that an employee owns. If the employee has two services (two telephone lines), then only one service will be involved in a consolidated billing relationship to redirect the charges generated to the employer's account.

According to one embodiment, an interactive Customer Service Representative (CSR) function is provided for a billing application to capture consolidated billing relationships that a customer would like to set up. The system provides a number of options for the customer to set up flexible payment options via consolidated billing relationships, such as: • Option to bill all the charges of one or more accounts to another account (for Account Level Consolidation); • Option to bill one or more account level charges of a specific type to another account (Account Level Charge Type Consolidation); 7 JP920020226 • Option to bill one or more account level sub-charges to another account (Account Level Sub Charge Type Consolidation); • Option to bill all the charges of one or more services within an account to another account (Service Level Consolidation); • Option to bill one or more service level charges of a specific type to another account (Service Level Charge Type Consolidation); • Option to bill one or more service level sub-charges to another account (Service Level Sub Charge Type Consolidation); • Option to bill any specific charge item in the system for an account to another account (Account Level Code Type Consolidation); and • Option to bill any specific charge item in the system for a service within an account to another account (Service Level Code Type Consolidation).

An account billing process is preferably implemented as a batch function that bills a selection of accounts within a billing cycle and produces invoice data for all the billed accounts. At the commencement of the Account Billing process, a snapshot of consolidated billing relationship details is taken and used for redirecting the charges during billing of individual accounts. This information is captured in a repository that is used subsequently by the billing process. The repository contains information for all accounts that have one or more of its charges set up to be redirected elsewhere. The repository also contains information for all accounts that have been designated to receive charges redirected from other accounts. This technique of obtaining a snapshot of consolidated billing information removes the need for shutting down the front-end interactive functions during the billing process, and allows support for 24x7 operation such as is required for Customer Care and Billing applications in the telecommunications and media service industries.

When the Account Billing process is billing individual charges for an account in this preferred embodiment, the process checks the repository to determine if the charge has to be billed elsewhere. If the charge is to be billed elsewhere, it is omitted from the current stage of processing. After attempting to bill all charges owned by an account, the 8 JP920020226 Account Billing process then attempts to bill any charges that have been redirected to the current account being billed. When redirecting charges from one account to another, the system writes appropriate reconciliation entries for the cycle being billed. Reconciliation entries help the business in ensuring that the billing process had processed all charges and billed them appropriately. Out of cycle reconciliation entries are also written by the current Account Billing process if charges belonging to accounts in other cycles had been used for billing.

Preferably, consolidated billing relationships can be created and discarded at any point in time. Only the relationship details that exist at the time of billing are considered and charges redirected accordingly.

Solutions according to the preferred embodiment provide the flexibility to group charges and redirect groups of charges from one account to another account's invoice, and support different levels of consolidation, allowing an account's charges or groups of charges to be consolidated and billed to another account's invoice. Preferred solutions provide flexibility in allowing the target invoice account to be within the same customer as the source account or a different customer. Also, the 'from account' and 'to account' in consolidated billing relationships can belong to same billing cycle or two different billing cycles. Thus, a business customer can support flexible payment options whereby one account's charges can be paid by another account, irrespective of whether the accounts belong to the same customer or the same billing cycle. In particular, the management of billing independently of the service provision itself enables customers to decide what billing structure they want independently of their service structure.

Solutions according to the invention can be used by service provider companies (or an entity providing a billing service) to provide flexible consolidated billing for a range of different customers and their individual requirements. The invention may be implemented in computer program code, recorded on a recording medium, for controlling the operation of a data processing system on which it runs to provide an accounts 9 JP920020226 processing application with the capability to redirect selected types of charges between accounts. 52^9 55 JP920020226 Brief Description of Drawings Preferred embodiments of the invention are described below in more detail, by way of example, with reference to the accompanying drawings in which: Figure 1 shows a communications network including a billing system running on a computer connected to the network; Figure 2 shows a sequence of steps of a method of account processing including redirecting of charges between accounts according to an embodiment of the invention.

Figure 3 shows the creation of files for efficiently accessing relationship data in a repository; Figure 4 shows the mechanism for accessing relationship data during execution of a billing cycle; Figures 5 to 10 show example relationships between customers, their accounts and service entities.

Detailed Description of Preferred Embodiments Figure 1 shows a communications network 10 in which a software-implemented customer management and billing system 20 is running on a server computer 30 connected to the network. The customer management and billing system 20 is referred to hereafter as the 'billing system'. The steps of a method for controlling charges redirection are shown in overview within Figure 2.

The billing system 20 uses database management software 40 to access a database of customer information within a data storage repository 50, and the server computer 30 receives usage information for updating 210 the database from one or more nodes 70 of 11 JP920020226 the communications network to which other network nodes 80,90,100,110 send usage information for their respective locally-connected users 120. Charge Types including Service Codes are assigned 200,210 to each of the charges received by the billing system 20, and the Service Codes are stored 210 with the charges information in a database of charges information in repository 50.

An Account Billing process 60 of the billing system 20 is a batch function that bills a selection of accounts within a billing cycle and produces invoice data for all billed accounts. The billing cycle comprises a set of process executions, and parameters including the period between each billing cycle run and the account identifiers for accounts to be billed in the particular billing cycle, which are required to generate invoice data for the relevant set of accounts.

Each account or customer is allocated to a particular billing cycle when the customer or account is defined to the billing system. Consolidated Billing relationships are captured 200 using a front-end interactive Customer Service Representative (CSR) function 130. This CSR function allows customers to select from predefined relationships and to specify desired relationships between accounts (as described later), indicating the charges or charge groups that the customer wishes to be redirected.

When a billing cycle is to be executed, a sequence of initialisation steps are performed. The Account Billing process takes 220 a snapshot of consolidated billing relationship details for the set of accounts which are assigned to the particular billing cycle. The snapshot includes, for each account in the billing cycle, an identification of all accounts to which specific types of charges are to be redirected ('bill to' information). The snapshot is obtained by scanning the charges database within the repository 50 using the relevant account identifiers for the current billing cycle accounts, to retrieve all billing relationship details for these accounts. The snapshot of relationship details is then stored as a temporary work file or set of work files in the repository 50. This information is then used during the billing process to determine 230 the billing accounts for redirecting charges. ®f f% ff c ^9 55 12 JP920020226 Since each billing cycle has its own specific set of accounts, and since different billing cycles have different billing times and possibly different billing periods, a new snapshot is taken for each billing cycle. Many separate instances of the Account Billing process 60, corresponding to separate billing cycles, can be executing simultaneously in the billing system.

When the Account Billing process is billing individual charges for an account, the Account Billing process retrieves usage charges information from the repository 50 and checks the snapshot details within the repository 50 to determine 230 whether each charge has to be billed elsewhere. The determination of which account a particular charge is to be allocated to could be performed by reference only to the work files referred to earlier, but in the present embodiment the work files are used as pointers to the relevant parts of the repository 50 and the relevant information within the repository 50 is used to check the latest billing redirection requirements. If the charge is to be billed elsewhere, the charge is omitted from the current account billing.

After attempting to bill 240 all charges owned by an account, the Account Billing process then attempts to bill 250 any charges that have been redirected from other accounts to the account which is being billed. Depending on whether all accounts for the billing cycle have been processed (as determined at 260), the account billing process either steps 270 to the next account within the billing cycle or ends 280.

The billing system provides flexible consolidated billing capability, enabling an account to pay for charges that were not generated by the account owner/user. An example of this would be a business customer who wishes to pay the telephone charges (either all or some) for a senior member of their organization. Another example would be a corporate customer who wishes to centralize charging, and therefore payment, of particular charges to a nominated department. 5fe-i £ i 13 JP920020226 Thus, the Account Billing functions allow the charges associated with one account to be paid partly or fully by another account belonging to either the same or a different customer.

Figure 5 shows, by way of example, a set of relationships between a customer, the customer's accounts and service entities used in the billing system 20. A customer can have one or more accounts. Each account is billed during execution of the Account Billing process and an invoice is produced for every account. There may be one or more services within the account to represent the services that the business is offering to the customer. For example, each telephone line of a telephony billing solution is treated as a separate service associated with a different system-generated Service Number. Individual charges are stored in association with two-character Service Codes which determine the type of service. For example, TL indicates telephony service and CT indicates CATV service.

The billing system provides the following options for a customer to set up flexible payment options via consolidated billing relationships: 1. Option to bill all the charges of one or more accounts to another account - Account Level Consolidation 2. Option to bill one or more account level charges of a specific type to another account - Account Level Charge Type Consolidation 3. Option to bill one or more account level sub-charges to another account - Account Level Sub Charge Type Consolidation 4. Option to bill all the charges of one or more services within an account to another account - Service Level Consolidation 5239 14 JP920020226 . Option to bill one or more service level charges of a specific type to another account -Service Level Charge Type Consolidation 6. Option to bill one or more service level sub-charges to another account - Service Level Sub Charge Type Consolidation 7. Option to bill any specific charge item in the system for an account to another account - Account Level Code Type Consolidation 8. Option to bill any specific charge item in the system for a service within an account to another account - Service Level Code Type Consolidation.

Consolidated Billing gives customers the flexibility to decide their preferred billing structure independently of their service structure. A business can set up as many accounts as they require to represent the services provisioned in the organization, but receive only one bill for the entire organization. For example, customer "ABC Systems" can be set up as two customers to represent their North Division and South Division. Within each customer they have three accounts to represent their Sales, Marketing and Finance departments. Business can choose to receive six billing statements, one for each account (department). Alternately, the business can choose to have only one bill for all the six accounts by using the Consolidated Billing functions. This allows the business to receive one invoice but maintain the same account structure, as it provides more control in terms of managing their individual services from each department.

Consolidated Billing provides additional flexibility to allow selection of services or charges or sub charges to be billed to another account (see description of grouping charges below). For instance, "ABC Systems" can decide to have three bills representing the Marketing, Sales and Finance departments and then the services from both divisions can be consolidated billed to these three accounts. Or "ABC Systems" can have six bills, one for each account in each division and get a group of charges like toll calls or rental charges paid by one account.

JP920020226 To support redirection of charges between accounts and between customers, a flexible method of grouping charges is provided within the billing system. The charge grouping allows assigning of a Charge Type and a Sub-Charge Type to every charge item and sub-charge item in the system. A business customer can determine the Charge Types and Sub Charge Types that will be used to govern the grouping of charges for redirection.

For example, a business customer may choose to group the charges into the following Charge Types and Sub Charge Types: A. Recurring Charges, which may be separated into Sub Charge Types: • Telephony Rentals • Equipment Rentals • Wiring Related Charges B. Non-Recurring Charges • Installation Fees • Item Purchase Charges C. International Usage Charges • Direct Dial Calls for Carrier ABC • Direct Dial Calls for Carrier DEF (for example calls from mobile telephone) D. Pay Viewing Charges • Sports Channel • Movie Channel E. Specific Service and Equipment Charges • Installation cost for residential model GR450 telephone • 4 pin socket 16 JP920020226 F. Usage Charges Per Jurisdiction and Usage Type • National direct dial call • International Calling Card call In the above example, the business customer may define four Charge Types: Recurring Charges; Non-Recurring Charges; International Usage Charges and Pay Viewing Charges. Under each of the Charge Types, the business may define appropriate Sub Charge Types like Telephony Rentals, Equipment Rentals, Installation Fees, Direct Dial Calls, Sports Channel, etc.

Code Type consolidations (using the Service Codes assigned to each charge, as described earlier) allow the flexibility to redirect charges that have not been classified into any specific Charge Type or Charge Category.

A system level control parameter controls the availability of consolidated billing functionality in the billing system. This functionality is available only if the system process flag ALWCONBILL is set to 'Y'.

A telecommunication company or other service provider's consolidated billing requirements are defined by Consolidated Billing Global parameters. These parameters determine the level of granularity of Consolidated Billing which the service provider intends to support. The highest level is 'Account Level', then 'Service', 'Charge' and 'Sub-Charge' levels. The selection of a particular level automatically allows Consolidated Billing for higher levels. The Global parameters also determine whether Consolidated Billing is allowed across Customers and can be used to determine how to treat existing account level discount entities (such as Packages, Schedule of Charges (SOCs), active or pending ECAs (Extended Credit Arrangements) and Deposits for the 'from account'). 523955 17 JP920020226 Customers of the service provider are able to create and maintain Charge Type, Sub Charge Type, and Charge Type/Sub Charge Type combinations - selecting from among the billing parameters that the service provider has decided to permit.

Consolidated Billing relationships can be set up via a front-end CSR (Customer Service Representative) function. Access to the Consolidated Bill set up functions are controlled by authority checks within the billing system 20. Individual customers' authorities to define billing relationships are set by the service provider, and individual users within one customer may also be permitted to specify billing relationships subject to both the authority checks imposed by the service provider and those imposed by the customer. In particular, users only have access to the Consolidated Billing functionality if they have Create, Update or Enquiry authority to the function. The step of setting up relationships, service codes and charges types, and defining user authorization are represented as step 200 in Figure 2. Numerical references within the description of the billing process execution (below) are references to method steps shown in Figure 2.

From the Setup screen, and depending on the Global Parameter for the level of Consolidated Billing allowed, an authorized user is able to create a Consolidation Billing Relationship by selecting a 'From Account' and/or 'Services' and/or 'Charges' and/or 'Sub-Charges' for consolidation to a selected 'To Account'. Details of the Relationship are stored in the database and are also written to an Audit Trail file. Authorized users are able to remove a Consolidation Billing Relationship, and the details of this action are also written to the Audit Trail file. All Audit Trail details for an account can be reported on.

As noted earlier, a billing cycle comprises a set of process executions used to allow the billing of a set of subscribers within a billing period. Multiple cycles allow the billing workload to be spread over the month. An identification code is used to break the subscriber base into a plurality of groups for billing purposes.

Billing processing revolves around billing cycle executions. A customer is allocated to a cycle when account details for the customer are set up within the billing system. After 18 JP920020226 some initialization steps, the billing cycle executes as a batch process that processes all the account details and generates the statements (or invoices) that are sent to customers. An 'Amount Due' on the statement is the amount that customer owes to the service provider company.

There are two possible scenarios that are catered for in billing processing for supporting consolidated billing: 1) A consolidated 'bill to' relationship where the 'from' and 'to' accounts are in different cycles 2) A consolidated 'bill to' relationship where the 'from' and 'to' accounts are in the same cycle.

An account may be both a 'bill to' and a 'bill from' account. In either case, prior to commencing billing of an account, a list is generated 220 of the consolidated billing relationships that apply at the time of billing, as described in more detail below. The instance of the Account Billing process 60 corresponding to a billing cycle receives a single account number at a time and processes 240 transactions for that account -referring to the list of billing relationships to ensure that all charges are billed to the required account. Thus, account numbers are processed one after the other.

With consolidated billing, charges on the current account and which are intended to be billed to the current account are processed first. Then charges/transactions from other accounts which are listed as having a redirection relationship with the current account are processed 250 (after determining whether those charges should be billed by the account currently being billed, or should remain with the 'from* account). The list of consolidated billing relationships is used to drive the additional processing requirements for 'from' and 'to' accounts associated with the account currently being billed. 19 ' %f J JP920020226 Additionally, taxation charges can be billed to an account that neither owns nor generates the charge. When the account that has agreed to pay these charges is billed, a tax profile of the owning customer, account or service is used to calculate the taxes.

Specific data structures and method steps performed within a system implementing the invention are described hereafter in more detail.

Prior to commencing billing of an account, a number of initialization steps are performed. Referring to Figure 3, the consolidated billing relationship details for a set of accounts allocated to the current billing cycle are retrieved 220 from a consolidated relationships file BLCBLR00 forming part of the charges database 300 in the repository 50 and are stored in a temporary work file 310, also within the repository 50. This work file 310 (BLCBSE00) contains a list of all accounts ('from account' numbers) that potentially have charges to be paid for by the billing account, and always contains at least one record - for the billing account itself.

The work file BLCBSE00 (310) has three fields: From Account, To Account and Consolidated Billing Relation Flag. The Billing Relation flag indicates whether the 'To Account' belongs to the same cycle as the 'From Account' or is an 'out of cycle' relationship. If the 'To Account' belongs to a different cycle, then reconciliation entries are written by the billing function in order to reconcile both the cycles, as described hereafter. If the two accounts are within the same cycle, charges can be redirected without reconciliation between cycles.

BLCBSE00 (310) is populated at the beginning of a billing run using data extracted from a consolidated relationship file, or 'master file', BLCBLR00 within database 300. The file BLCBLR00 is updated when billing relationships are changed, but preferably periodically (for example on a once-daily basis) rather than instantaneously for every update so as to avoid potential problems if updates occur part way through execution of a billing cycle. BLCBLR00 is not used as the initial source of billing relationship information during execution of a billing cycle. There would be considerable processing JP920020226 delays if it were necessary at billing cycle execution to retrieve billing relationship information by repeatedly scanning through all of the hierarchically organized data within the master file BLCBLR00. Instead, a snapshot of information from BLCBLR00 at a particular point in time is extracted and used to populate BLCBSEOO, which file is then used during execution of the billing cycle. The snapshot includes the billing relationship information for the specific set of accounts of the current billing cycle.

A further file 320 (BLCBSE01) contains a logical view of the relationships between accounts, and has 'To Account' as a primary key. As shown schematically in Figure 4, BLCBSE01 (320) provides a fast index into the data within file BLCBSEOO (310), which itself provides an index into relevant data within the master file BLCBLR00 within the database 300. When billing an account, BLCBSE01 (320) is used as a form of index to identify all the 'From Accounts' that have charges redirected to the current account being billed (the 'To Account'). The work file BLCBSEOO (310) is used to retrieve redirection information to determine which account to allocate charges to during the billing cycle run.

The following step is involved in populating file BLCBSEOO with a list of all the 'from accounts', ie all those accounts that have charges that are to be paid for by the account about to be billed. For each account that has contributing charges, a determination is performed of which cycle the 'From Account' would normally be billed in. If the 'From Account' would be billed in the same cycle as the billing account then the consolidated billing relationship flag in file BLCBSEOO is set to '1'. Where the 'From account' is in a different cycle to the billing account, the consolidated billing relationship flag is set to '2'.

In addition, a second work file (BRACCT00 - not shown in the Figures) is populated to contain details of services for the billing account including details of services for 'from' accounts. The two work files BLCBSEOO and BRACCT00 together comprise the 'snapshot' information referred to earlier. 5239 A J fca y&r 21 JP920020226 BRACCTOO is used for billing usage charges relating to services connected to an account. The logical view of this file has 'Account Number' as its primary key and has one record for every service that the account owns. If the account is a 'To Account' in a consolidated billing relationship, then the services belonging to those 'From Accounts' is also loaded into the file BRACCTOO.

The list of service numbers for a 'From Account' are written into file BRACCTOO. The list is created as though the numbers are associated with the billing account ('To account'). A field in file BRACCTOO stores the 'From Account' number. A consolidated billing relationship flag is also added to this file and the file is populated in the same manner as file BLCBSEOO.

Note that all the services for a 'From Account' are written to file BRACCTOO unless there are specific service level consolidations set up for the "From Account" to the "To Account". However, if one or more service level consolidated relationships are set up for the "From Account" which is to be consolidated billed to the current "To Account", then only those specified services of the "From Account" are written to BRACCTOO.

When writing BRACCTOO records for 'From Account' services, a tax profile field in BRACCTOO can be updated with the service tax profile of the 'From Account'. This enables the billing programs to use a service tax profile of the 'From Account' when calculating tax.

Where a billing account has charges to bill for an account which is not in the same cycle, the billing system generates reconciliation entries. These reconciliation entries are created as transfers either in or out of the cycle. As each account is billed, details are stored of charges that have been billed from accounts that exist in different cycles to the account being currently billed. These details are stored in a table called BRCBUSOO. This table stores the details of the 'from' and 'to' accounts and the amounts of these charges are used in adjusting the totals for the appropriate billing cycle. The amounts in file 22 JP920020226 BRCBUSOO are totalled at the end of the complete billing run, after all accounts in the cycle have been billed, and are then used to adjust the appropriate billing totals.

As described above, a consolidated billing relationship may be used in order to redirect charges to bill to an account other than that which generated the charge. When this occurs, the billing cycle is able to refer to one or more 'index' files to determine where those charges can be found and also any requirement for reconciliation.

When usage is processed by the bill cycle, additional validations are performed for consolidated billing. A check is made to see if the usage transaction is to bill to the account being processed or to some other account. This is performed by referring back to file BLCBRLOO. Therefore, the master file BLCBRLOO is the final source of relationship information which is used in the actual billing cycle execution, but additional files are provided to simplify access to this information at execution time.

Processing of most charges in the bill cycle is based on the account that the cycle is currently billing. With consolidated billing, the billing function also processes charges for accounts other than the current billing account. The new billing work file (BLCBSEOO) contains details of all accounts that may have contributing charges. The billing account charges are processed first and this is followed by charge items belonging to any 'from accounts' consolidated billed to the current account that is being billed. That is, once processing of usage for an account is complete, any usage for accounts that have a consolidated 'bill to' relationship is done. This usage may or may not be for an account in the same bill cycle. When processing usage for an account that is to be billed in a different cycle, the value of the usage is accumulated. This value is treated as a 'transfer out' amount in the current cycle for purposes of reconciliation between cycles.

At the time transactions are added to the billing system (for example: payment post, call load, Service Order post, etc), a reconciliation database is updated with 'expected to bill' values. These 'expected to bill' values are posted to the cycle of the owning account.

With the introduction of consolidated billing, the billing of transactions in a cycle that is 23 JP920020226 different to that of the account or service which generates the charge becomes possible. In such cases the charge is deemed to be an external charge. These external charges are included in the reconciliation process as a 'transfer out' amount when the account that has generated the charge is being billed. When the account that is to pay the charges generated by a different account is billed, then these charges are included in the reconciliation process as a 'transfer in' amount. Where the 'from' and 'to' accounts in a consolidated billing relationship bill in the same cycle, no adjustment for reconciliation is required.

A process within the billing system is used to select a billing account. The billing system design supports multiple consolidated billing relationships to be set up for the same account. Thus, a customer may have requested for 'Pay per View' charges from account 123 to be redirected to account 456 and for all other charges of Account 123 to be redirected to another account 789. The Account Billing process performs an iterative process to determine the billing account for a charge - to determine whether the charge is to be billed to another account. This iterative process is implemented by a sub-process of the Account Billing process 60 (implementing a "Check Consolidated Bill Relationship" function). If a relationship exists in Consolidated Billing Relationship file (BLCBLR00) for the input account and transaction type, this sub-process returns the 'Consolidated Bill To Account'.

This sub-process is a significant component of the Consolidated Billing functionality and adopts the following iterative process (corresponding to step 230 of Figure 2) to determine the 'To Account' number that the charge has to be billed to, irrespective of which account generated the charge: 1. Check for Service Level Code Type consolidation relationships.

For instance, there may be a request to redirect a specific charge (for example, Caller Display) for a specific service (first telephone line) of a first account to another account. The check uses an input Account Number, as well as a Service Code (SC) or Service Number (SN) and any relevant Charge Type identifier and/or Sub-Charge 5239 55 24 JP920020226 Type to access the Consolidated Bill Relationship file (BLCBLROO). For every record found, a check is performed for a code match for the Code Type. If such a relationship exists for the current charge being processed and if the billing account in the relationship is same as the account being billed, then the charge is billed under the current account being billed. For example, if the Code Type is SC, then check if the input Service Code matches the code value in the Consolidated Billing Relationship file (BLCBLROO). If a match is found, then return to the caller the 'To Account' as specified in the Consolidated Billing Relationship file (BLCBLROO). Otherwise, the iterative process proceeds to the next step. 2. Check for Account Level Code Type consolidation relationships - using input Account number as key and blank Service Code (SC), Service Number (SN), Charge Type, Sub-Charge Type to access the Consolidated Billing Relationship File. For every record found, a check is performed for a code match for the Code Type. If a match is found, then the 'To Account' as specified in the Consolidated Billing Relationship file is returned. For instance, there may be a request to redirect a specific charge (such as Caller Display) of an account to another account. If the account has two telephone lines, then the charges relating to the Caller Display facility in both the telephone lines are redirected to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is the same as the account being billed, then the charge is billed under the account currently being billed. If no records are found, the iterative process proceeds to the next step. 3. Check for Service Level Sub Charge Type consolidation relationships. For instance, there may be a request to redirect all charges belonging to a specific charge type / sub charge type (such as Recurring Charges / Telephony Rental) for a specific service (first telephone line) of a first account to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is the same as the account being billed, then the charge is billed under the current account being billed. Otherwise, the iterative process proceeds to the next step.

JP920020226 4. Check for Service Level Charge Type consolidation relationships. For instance, there may be a request to redirect all charges belonging to a specific charge type (for example, all Recurring Charges) for a specific service (first telephone line) of an account to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is same as the account being billed, then the charge is billed under the current account being billed. Otherwise, the iterative process proceeds to the next step.

Check for Service Level consolidation relationships. For instance, there may be a request to redirect all charges relating to a specific service (such as a first telephone line) of an account to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is same as the account being billed, then the charge is billed under the current account being billed. Otherwise, the iterative process proceeds to the next step.

Check for Account Level Sub Charge Type consolidation relationships. For instance, there may be a request to redirect all charges belonging to a specific charge type / sub charge type (for example, Recurring Charges / Telephony Rental) of an account to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is same as the account being billed, then the charge is billed under the current account being billed. Otherwise, the iterative process proceeds to the next step. 7. Check for Account Level Charge Type consolidation relationships. For instance, there may be a request to redirect all charges belonging to a specific charge type (for example, all Recurring Charges) of an account to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is same as the account being billed, then the charge is billed under the current account being billed. Otherwise, the iterative process proceeds to the next step. 26 JP920020226 8. Check for Account Level consolidation relationships. For instance, there may be a request to redirect all charges belonging to an account to another account. If such a relationship exists for the current charge being processed and if the billing account in the relationship is same as the account being billed, then the charge is billed under the current account being billed.

If there are no relationship records for the current charge and the account currently being processed, then the current charge is not billed under the current account.

A simple solution for avoiding requirements for locking the charges database involves omitting the current day's usage charges for the day on which the Account Billing process executes. The charges database can be in the process of being updated and yet the updates do not affect the charges information which is to be processed for the current billing cycle processing sequence.

The consolidated billing solution described above allows the business customer (for example, a telecommunication business or other service provider) to provide flexible payment options for their own customers. Customers are provided with options to pick and choose charges that they can redirect to other accounts so that the payment can be made by accounts that do not own the charges or services that incur the charges. The ability to provide this flexibility without locking or closing front-end applications can be highly advantageous for telecommunications billing, for example, where the volume of usage data to be processed is enormous and 24 hour and 7 day availability is required.

A number of the consolidated billing options listed earlier are explained below, with reference to Figures 5 to 10, using examples to illustrate the flexibility of charge redirection that is supported by the billing system.

In the example of Figure 5, customer ABC has two accounts A1 and A2.

A1 has 4 services - A11, A12, A13 and A14 A2 has 2 services - A21 and A22 27 JP920020226 With conventional billing systems, the accounts A1 and A2 will get a bill each (Account is the billing node in applications such as IBM Corporation's ICMS™ product).

Al's bill will contain the charges for the services A11, A12, A13 and A14. A2's bill will contain the charges for the services A21 and A22.

With consolidated billing using the billing system described herein, the system provides various options of charge re-directions and billing as described in the following sections: Facility to bill one or more accounts to another account In the example of Figure 6, the customer ABC can define how many bills he wants. For instance, assume customer ABC decides to have only one bill - that being for Account Al.

In this example, Account Al's bill will contain the charges for the services All, A12, A13, A14, A21 and A22.

Facility to bill one or more service's charges to another account In the example of Figure 7, it is assumed that customer ABC decides to have two bills: one bill for Account Al and another one for Account A2. However, the customer decides that Account A2's bill will contain only charges for service A22.

This means that Account Al will be billed for all the charges of Al 1, A12, A13, A14 and A21. Account A2 will be billed for the charges of A22.

Facility to bill one or moire charges to another account In the example of Figure 8, customer ABC decides to have two bills: One bill for Account Al and another bill for Account A2. This means that Account Al will be billed for services of Al 1, A12, A13 and A14 and Account A2 will be billed for services of A21 and A22. However, customer ABC requires all Local and International usage 28 JP920020226 charges of A21 and A22 to be billed to account Al and also requires all the Services & Equipment charges of Al 1 and A14 to be billed to account A22.

Account Al will be billed for the following: • All charges of Al 2 and Al 3 • All charges except S & E charges for Al 1 and A14 • Local and International usage charges using carrier AT & T for A21 and A22 Account A2 will be billed for the following: • Services & Equipment charges for Al 1 and A14 • All charges except Local and International usage charges for A21 and A22.

Facility to bill one or more sub charges to another account Sub charge is a further lower level classification within a specific charge type. In this example, customer ABC decides to have two bills: One bill for Account Al and another bill for Account A2. This means that Accoimt Al will be billed for services of Al 1, A12, A13 and A24 and account A2 will be billed for services of A21 and A22. However, customer ABC decides the following: 1. Service & Equipment (referred as S & E) items RR - Residential Rental and MWIRE - Wiring Maintenance from Al 1, A12, A13 and A14 will be billed to account A2. 2. All direct dialed international calls with call type DD and carrier AT & T from service A13 will be billed to account A2. 3. Any debit adjustment with charge code 467 will be billed to account A21 4. Any non-recurring charge for installations INSTL for A21 will be billed to account Al . All local calls using carrier MCI from A21 and A22 will be billed to account Al 6. All adjustments for Account A2 with charge code 872 will be billed to account Al 7. CATV package GOLD on service A22 will be billed to account Al 8. For service A22, any Pay Per Viewing event in the content category of FOOTBALL that is provided by the Content Provider 'STAR SPORTS' will be billed to Al 29 JP920020226 In this example, as shown in Figure 9. Account Al will be billed for the following: 1. All charges for All, A12, A13 and A14 except S & E charges for RR and MWIRE 2. For A13, all international usage except usage type DD from carrier AT & T 3. All debit adjustments except debit adjustment with charge code 467 4. Non-recurring charges for S & E item INSTL for service A21 from Account A2 . All local calls from carrier MCI for A21 and A22 from Accoimt A2 6. All adjustments with charge code 872 from Account A2 7. CATV package GOLD for service A22 from Account Al 8. Any pay-viewing event with content category FOOTBALL provided by content provider STARSPORTS for service A22 from Account Al Account A2 will be billed for the following: 1. S & E charges RR and MWIRE for services Al 1, A12, A13 and A14 2. All international usage with usage type DD from carrier AT & T for service A13 3. All debit adjustments with charge code 467 from Account Al 4. All charges and adjustments for Account A2 and services A21 & A22, except • All local calls from carrier MCI • Non-recurring charges for S & E item INSTL • All adjustments with charge code 872 • CATV package charges for GOLD for A22 • Any pay viewing event with content category FOOTBALL provided by content provider STARSPORTS for service A22 Facility to bill one customer's charges to another account Figure 10 shows two customers XYZ and ABC, for whom a single bill has been requested. Customer XYZ has account Al and customer ABC has account A2. The customers require all charges to be presented in the bill of customer XYZ. This means that account Al will be billed for all the charges of the account A2.

JP920020226 In the particular embodiment of the invention described in detail above, the snapshot of account relationships information for use in consolidated billing is stored in the same repository as the charges data, but is extracted from the database and stored as a set of work files to ensure that the relationship data used for billing is easily accessible during execution of the billing cycle. However, in alternative embodiments, the snapshot of relationships information may be stored separately from the repository holding the charges database. The snapshot of relationships information may provide an efficient index for accessing the main repository of relationship information, or in an alternative embodiment may be the main source of relationships information which is used during execution of a billing cycle.

In embodiments in which the master file of billing relationships can be updated during execution of a billing cycle, and is used as the final confirmation of applicable billing relationships, the integrity of billing relationships can be maintained by ensuring that users cannot update billing relationships which are relevant to a billing cycle which is currently executing. That is, a check is performed of whether a relevant billing cycle is active when billing relationships for two or more accounts are being updated by a user and, if the billing cycle is active for either of the set of accounts for which a user wishes to update the billing relationships, then the update is rejected (or in another implementation is deferred) until completion of the billing cycle execution. The user may be instructed by the interactive front end system to try again later. In this way, the integrity of billing relationships can be maintained for the period of the billing cycle.

It will be clear to persons skilled in the art that a number of other modifications to the above-described embodiments may be made within the scope of the present invention.

Claims (14)

31 JP920020226 WHAT IS CLAIMED IS:

1. A method for redirecting charges between accounts for an accounts processing application, comprising the steps of: (a) storing account information in a repository for each of a plurality of accounts, including storing charges information against accounts within the plurality and storing requirements for redirecting of specific types of charges between accounts; (b) retrieving from the repository the requirements for redirecting of specific types of charges between a first set of accounts, and storing the retrieved requirements; (c) for a first account within the first set of accounts, using the retrieved requirements to identify charges stored against the first account which require redirection to a different account; (d) processing the charges information stored against the first account except for identified charges stored against the first account which require redirection to a different account; (e) for each account within the first set of accounts other than the first account, processing any charges stored against any one of the other accounts which charges require redirecting to the first account as determined by the retrieved requirements; and (f) repeating steps (c) to (e) for each account within the set.

2. A method according to claim 1, wherein each account has an account identifier and is assigned to a billing cycle, and wherein the step of retrieving the requirements from the repository for a first set of accounts comprises searching the repository using the account identifiers for the set of accounts assigned to a first billing cycle.

3. A method according to claim 2, wherein the steps of processing the retrieved charges include generating a bill for each account within the set of accounts assigned to a billing cycle. 32 JP920020226

4. A method according to claim 1, wherein a charge type is assigned to charges within the repository, and charges are stored in the repository in association with their assigned charge types to enable separate redirection of specific types of charges between accounts.

5. A method according to claim 4, wherein the step of identifying charges which require redirection includes a step of checking the retrieved requirements for charge-specific consolidation relationships, using an input account number to identify the current account to be processed and using an assigned charge type code to identify the type of charges.

6. A method according to claim 4, wherein the account processing application is a billing application for telephony charges and wherein the charge types include one or more charge types selected from the set of charge types comprising: recurring charges; non-recurring charges; local usage charges; long distance domestic usage charges; and international usage charges.

7. A method according to claim 1, wherein a service code is assigned to charges within the repository, and charges are stored in the repository in association with their service codes to enable separate redirection of charges between accounts for specific services.

8. A method according to claim 7, wherein the step of identifying charges which require redirection includes a step of checking the retrieved requirements for service level code type consolidation relationships, using an input accoimt number to identify the current account to be processed and using a service code to identify the service. 33 JP920020226

9. A method according to claim 1, including the steps of: defining requirements for redirection between accounts of specific types of charges and/or specific services, for specific accounts within a set of accounts, by selecting redirection relationships from a set of redirection relationships including two or more of: a service level code type consolidation relationship; an account level code type consolidation relationship; a service level sub-charge type consolidation relationship; a service level charge type consolidation relationship; a service level consolidation relationship; an account level sub-charge type consolidation relationship; an account level charge type consolidation relationship; and an account level consolidation relationship.

10. A data processing apparatus for supporting redirection of charges between accounts for an accounts processing application, the apparatus including: an interface for specifying requirements for redirecting of specific types of charges between accounts; a repository for storing account charges for each of a plurality of accounts and for storing the requirements for redirecting charges between accounts; a data retriever for accessing the repository to retrieve the requirements for redirecting charges between a first set of accounts; and program code for controlling processing of charges information for the first set of accounts with reference to the retrieved redirection requirements to perform the steps of: (i) for a first account within the first set of accounts, using the retrieved requirements to identify charges stored against the first account which require redirection to a different account; 34 JP920020226 (ii) processing the charges information stored against the first account except for identified charges stored against the first account which require redirection to a different account; and (iii) for each account within the first set of accounts other than the first account, processing any charges stored against any one of the other accounts which charges require redirecting to the first account as determined by the retrieved requirements; and (iv) repeating steps (i) to (iii) for each account within the set.

11. A data processing apparatus according to claim 10, wherein the charges stored against accounts are associated with one or more of a charge type, sub-charge type and service code, and wherein the interface enables selection from a set of charges redirection options including: an option to bill all charges for one or more accounts to another account; an option to bill one or more account level charges to another account; an option to bill one or more account level sub-charges to another account; an option to bill one or more service's charges to another account; an option to bill one or more service level charges to another account; and an option to bill one or more service level sub-charges to another account.

12. A data processing apparatus for supporting redirection of charges between accounts for an accounts processing application, the apparatus including: an interface for specifying requirements for redirecting of specific types of charges between accounts, wherein the interface enables selection from a plurality of charges redirection options; a repository for storing account charges for each of a plurality of accounts and for storing the requirements for redirecting charges between accounts; a data retriever for accessing the repository to retrieve the requirements for redirecting charges between a first set of accounts; and 35 JP920020226 program code for controlling processing of charges information for the first set of accounts with reference to the retrieved redirection requirements to redirect charges between accounts.

13. A data processing apparatus according to claim 12, wherein the charges stored against accounts are associated with one or more of a charge type, sub-charge type and service code, and wherein the interface enables selection from a set of charges redirection options including: an option to bill all charges for one or more accounts to another account; an option to bill one or more account level charges to another account; an option to bill one or more account level sub-charges to another account; an option to bill one or more service's charges to another account; an option to bill one or more service level charges to another account; and an option to bill one or more service level sub-charges to another account.

14. A computer program product comprising computer program code recorded on a machine readable recording medium, for controlling the performance of a data processing apparatus on which the program code executes, to perform a method for redirecting charges between accounts for an accounts processing application, the method comprising the steps of: (a) storing account information in a repository for each of a plurality of accounts, including storing charges information against accounts within the plurality and storing requirements for redirecting of specific types of charges between accounts; (b) retrieving from the repository the requirements for redirecting of specific types of charges between a first set of accounts, and storing the retrieved requirements; (c) for a first account within the first set of accounts, using the retrieved requirements to identify charges stored against the first account which require redirection to a different account; ■52 x 36 JP920020226' (d) processing the charges information stored against the first account except for identified charges stored against the first account which require redirection to a different account; and (e) for each account within the first set of accounts other than the first account, processing any charges stored against any one of the other accounts which charges require redirecting to the first account as determined by the stored requirements; and (f) repeating steps (c) to (e) for each account within the set. International Business Machines Corporation By Attorneys for the Applicant SPRUSON & FERGUSON li' ' i "Oc J § 55 37 JP920020226 ABSTRACT OF THE DISCLOSURE METHODS. APPARATUS AND COMPUTER PROGRAMS FOR FLEXIBLE CONSOLIDATED BILLING AND CHARGES ALLOCATION FOR ACCOUNTS PROCESSING APPLICATIONS Methods, apparatus and computer programs are disclosed for accounts processing applications, which enable redirecting of charges between accounts without adversely affecting performance of the accounts processing application. A service provider's customers individual requirements for redirection of specific types of charges between specific accounts are stored within a repository. Service usage and charges information is also stored in the repository. Before processing accoimt charges for a set of accounts assigned to a billing cycle, a snapshot is taken of the charges-redirection requirements of the set of accounts. The snapshot is then used when processing account charges, to enable redirection without locking the charges database or the front end processes for updating relationships between accounts.