Intelligent network charging edge

FIELD OF THE INVENTION

The present invention relates generally to network communications systems, and more particularly, to a system and method for mediating charging transactions between service-providing network elements and charging/billing network elements.

BACKGROUND OF THE INVENTION

Technological advances in networking systems continue to facilitate ease of information transfer and convenience to users. The proliferation of local, regional, and global networks such as the Internet has availed a sea of information to the consuming public. These networking technologies have expanded to increasingly include wireless and mobile technologies. Information can be downloaded to desktop systems, wireless systems, mobile systems, etc. through a variety of interconnected networks. For example, information available via the Internet can be downloaded onto mobile wireless units, such as cellular telephones, personal digital assistants (PDAs), laptop computers, etc.

Through the introduction of current and future access technologies such as General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Wireless Application Protocol (WAP), etc., data subscribers will experience and use an unprecedented variety of new services based on the subscriber's location, selected content, and personal preferences. In this arena operators and service providers compete to offer differentiated service variety and pricing. As new services are rolled out, the time-to-market issue affecting these competitive new services becomes a paramount concern, and delays due to integration requirements with charging and billing systems becomes increasingly intolerable.

Network elements related to charging, billing, rating, etc. (hereinafter generally referred to as charging elements) can be complex. For example, rating engines are often required to handle a very large number of permutations resulting from factors such as rating multiple services, each which includes a great number of flexible pricing and discounting variables. Charging elements may be based on different pricing options, such as postpaid, direct pay, prepaid or other real-time payment options. Further, charging can be based on a combination of data volume, duration, type of content, transaction, etc. All of these different variables make charging elements, and communicating with such charging elements, quite complex.

In a conventional billing system, each of the services communicates charging/billing information, such as call-detail records (CDRs), to the charging elements. However, each of the various network elements may collect and provide CDR information in different formats. The charging elements need to know the format used by each particular network element in order to comprehend its content. This fact, coupled with the complexities of charging elements described above, typically requires that an “integration” be performed for each network element handled by the charging elements. More particularly, the charging and billing elements must undergo an integration to allow it to understand and communicate with each of the network elements in which it is to collect and process charging and billing information. These custom modifications at the charging elements present a significant task, requiring colossal amounts of time and money, and have a major adverse impact on getting a new service to market quickly. The problem of requiring such integration is exacerbated as new services and network elements continue to be designed and deployed in the network.

Furthermore, charging for network services can be based on postpaid, prepaid, direct pay, and other real-time or non-real-time payment methodologies. As new network systems are presented in the networks, these various payment approaches add significant complexities to existing charging and billing methodologies. For example, as more and more real-time interaction is required between networks and Operations Support Systems (OSS) systems, custom solutions must continually be derived. There is currently no manner of facilitating the integration of these new systems into existing networks in an expeditious and effective manner.

Therefore, the challenge still remains to expedite the interfacing of services and charging elements, and reduce the resulting interface complexities in these network elements. The present invention provides a solution to these and other shortcomings of the prior art, and offers additional advantages over the prior art.

SUMMARY OF THE INVENTION

The present invention is directed to a system and method for mediating charging transactions between service-providing network elements and charging/billing network elements.

In accordance with one embodiment of the invention, a method is provided for managing charging and billing for services on a network, where the network includes network elements that provide billable services and charging elements that perform various charging and billing functions. Charging event records, herein referred to as charging events, are received at a network charging edge that isolates the network elements and charging elements. The network charging edge includes one or more bridge modules that are logically coupled between the network elements and the charging elements. Charging transactions between the network elements and their respective charging elements are managed via the bridge modules, by applying rules to the charging transaction initiated by corresponding charging events.

More particular features of such a method include implementing an application programming interface (API) at each of the network elements to interface each of the respective network elements to the bridge modules. Further, managing the charging transactions may include transforming the charging events to a format recognizable by targeted charging elements, pursuant to the rules. The rules also govern selection of an interface object for communicating with a corresponding charging element. This selection of an interface object includes identifying one of the multiple interface objects as determined by object configuration rules. In one embodiment, each of the bridge modules is pre-configured with the requisite rules. This configuration process includes configuring each of the bridge modules with a subset of the rules assigned to the services managed by that bridge module. One of the bridge modules may be assigned as a primary bridge module that receives all of the rules for all of the bridge modules. The primary bridge then distributes the rule subsets to the remaining bridge modules. Such a rule configuration may be effected through entry of the rules at a console coupled to the primary bridge module.

In accordance with another embodiment of the invention, a system for facilitating charging for services available via a network is provided. At least one network charging element is provided in the network to perform service charging functions. Further, at least one network service element provides a service subject to use charges. A network charging edge, including at least one charging bridge logically coupled between the network service element and the network charging element, mediates communications between the network service element and the network charging element.

In accordance with another embodiment of the invention, a bridging apparatus is provided for mediating charging transactions between at least one network service element and at least one network charging element on a network. The bridging apparatus includes a transformation module to receive a charging event from the network service element, and to transform the charging event to a format comprehensible by the network charging element. A business rule module is coupled to the transformation module to provide predefined business rules that govern transformations performed by the transformation module. An interface object module is provided, which includes a various interface objects for communicating with corresponding network charging elements. An interface object management module is coupled to the transformation module to receive the transformed charging events. An object configuration rule module is coupled to the interface object management module, and includes object configuration rules to instruct the interface object management module to direct the transformed charging events to the interface objects of the charging elements for which the transformed charging events are destined.

In accordance with another embodiment of the invention, a method is provided for managing charging and billing for services on a network having network elements providing billable services and charging elements. The method includes receiving multiple charging information records generated by multiple network elements at a network charging edge. The various charging information records are associated with a particular user session that involves each of a number of the multiple network elements. The charging information records are coordinated into a user-session charging transaction at one or more bridge modules of the network charging edge, which is logically coupled between the plurality of network elements and the charging elements. Coordinating the charging information records into a user-session charging transaction is governed by first predetermined rules applied at the bridge modules. The user-session charging transaction is executed at the bridge modules according to second predetermined rules.

The above summary of the present invention is not intended to describe each illustrated embodiment or implementation of the present invention. This is the purpose of the figures and the associated discussion which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a prior art charging and billing architecture used to charge customers service use provided by various network elements;

<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of a network employing a charging edge in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 3</figref> is another representation of a network employing an intelligent charging edge in accordance with the invention;

<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram illustrating a prepaid transaction initiated by a network element in a network implementing a charging bridge to form an intelligent charging edge in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram illustrating a postpaid transaction initiated by a network element in a network implementing a charging bridge in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 6</figref> is a block diagram of an exemplary embodiment of a charging edge bridge in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 7</figref> is a diagram illustrating an exemplary manner in which a charging bridge according to the invention carries out a plurality of calls in connection with a charging transaction;

<figref idrefs="DRAWINGS">FIG. 8</figref> is an exemplary embodiment of a network employing an intelligent charging edge (ICE) layer in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates an embodiment of one manner of employing a plurality of charging edge bridges in a network system;

<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates representative types of business rules utilized in a charging bridge in accordance with the invention;

<figref idrefs="DRAWINGS">FIG. 11</figref> is a flow diagram of an exemplary manner of implementing an intelligent charging edge in accordance with the principles of the present invention;

<figref idrefs="DRAWINGS">FIG. 12</figref> is a flow diagram of a more particular manner of interfacing network elements in the network domain and elements in an OSS domain; and

<figref idrefs="DRAWINGS">FIG. 13</figref> is a block diagram illustrating one embodiment of a charging edge utilized in connection with charging information generated by multiple network elements.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

In the following description of the various embodiments, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, and structural and functional modifications may be made without departing from the scope of the present invention.

Generally, the present invention is directed to a system and method for interfacing network elements and charging/billing elements in a network, using a network layer serving as a charging edge. Charging events, such as “call-detail records” (CDRs), are provided by network element services. These charging events are directed to an intermediary network charging layer which isolates the network elements from the charging and billing elements. Within the network charging layer are one or more bridge systems that isolate the network elements and the Operations Support Systems (OSS) charging and billing elements. The bridge systems provide intelligence at the network charging layer, thereby allowing the network elements to focus on providing services, and the charging and billing elements to focus on charging and billing. This bridge intelligence involves coordination and management of the transactions arising out of charging event occurrences.

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a prior art charging and billing architecture <b>100</b> used to charge customers for use of services provided by various network elements. Network operators generally have some type of billing system, such as the charging and billing system <b>102</b>. Generally, a billing system such as the charging and billing system <b>102</b> includes various independent applications. These independent applications, when operated together, are referred to as the billing system. The billing system <b>102</b> includes a number of major components. For example, a charging event record (hereinafter referred to as a charging event) is used to record the details of the call. In the postpaid context, a call-detail record (CDR) has traditionally been the name given to such a charging event. While “CDR” has generally been used to denote a charging event related to a postpaid paradigm, the term CDR may be used herein for convenience to denote a charging event associated with other charging paradigms, such as prepaid, real-time, etc. In any event, the call in which details are recorded traditionally include voice transmissions, but is also generally used to refer to transmissions of data, video, sound, and other transmittable content. The information in a charging event generally depends on the type of transmission, and the payment option selected. For example, in the context of postpaid services, usual information associated with a CDR may include start time of call, end time of call, duration of call, originating number, terminating number, number of bytes transferred, URL visited, etc. In the context of postpaid services, the CDR may be stored until time of billing.

Other billing system components include rating applications, and billing and invoicing components. Rating applications are systems and programs that apply the rate for the individual calls. Rating gives the call a value to be charged at the time of billing, taking into consideration promotions, discounts, etc. The billing system may be prepaid, real-time billing, postpaid, etc., and has the responsibility of collecting information from the rating system. Some billing systems account for promotions, discounts, and the like rather than having the rating system perform such a task. An invoicing system creates a file including the customer's information, and the corresponding billing information, so that invoices for the customer's usage may be created and dispatched.

In a conventional billing system, each of the various network elements (NE) <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b>, <b>112</b>, <b>114</b>, <b>116</b> communicate charging/billing information to the charging and billing system <b>102</b>. As networks continue to expand in the number and types of services available to users, more network elements <b>104</b>-<b>116</b> are implemented in the network. However, each of the various network elements <b>104</b>-<b>116</b> may collect and provide charging event information in different formats. The charging and billing, system <b>102</b> will need to know the format used by each particular network element in order to comprehend its content. For example, some network elements may provide such information in an ACSII (American Standard Code for Information Interchange) file, others in XML (eXtensible Markup Language ) format, or other formats.

The charging and billing system <b>102</b> must therefore be able to comprehend each of the different formats for event records provided by the various network elements <b>104</b>-<b>116</b>. This generally requires that an integration be performed for each network element. More particularly, the charging and billing system <b>102</b> must undergo an integration to allow it to understand and communicate with each of the network elements in which it is to collect and process billing information. Resulting integration modules <b>118</b>, <b>120</b>, <b>122</b>, <b>124</b>, <b>126</b>, <b>128</b>, <b>130</b> represent the specific conversion systems and applications required to convert the billing information in an incoming format to a format recognized by the charging and billing system <b>102</b>. These conversions are represented by the format gradients at each of the integration modules <b>118</b>-<b>130</b>. For example, the format of the transmitted billing information from network elements <b>106</b> and <b>114</b> are comprehensible by the charging and billing system <b>102</b>, as represented by the uniform integration modules <b>120</b> and <b>128</b>. Alternatively, the formats of the transmitted billing information from network elements <b>104</b>, <b>108</b>, <b>110</b>, <b>112</b>, and <b>116</b> are converted by the integration modules <b>118</b>, <b>122</b>, <b>124</b>, <b>126</b>, and <b>130</b> respectively. This conversion, and the need for specific integration of a new service to be operable with the existing charging and billing system <b>102</b>, is an enormous task, requiring large amounts of time and money, and having a major adverse impact on getting a new service on the market fast.

This drawback of the prior art may be further illustrated through an example. Assume that the network element <b>104</b> is an MMSC (Multimedia Message Service Center) that produces charging events to, for example, transmit a digital image. The charging event may include information such as an IP address, the size of the image, etc. In the charging and billing system <b>102</b>, the information required to perform rating, billing, and/or invoicing may be different from the information included in the charging event from the MMSC <b>104</b>. For example, the charging and billing system <b>102</b> may include service logic to charge for services based on the resolution of the image transmitted, and the number of images transmitted. The service logic must therefore include integration or conversion logic to transform the information into something meaningful with respect to the service being purchased by the customer. Thus, if the information to be billed to the customer via the charging and billing system <b>102</b> is to be presented to the customer as a number of images and resolutions of each image, then the IP address, size of image, or other information provided by the MMSC <b>104</b> in the charging event must be converted by the service logic represented by the integration module <b>118</b>. As described above, this results in expenditures of time and money to obtain the requisite integration from a company or other entity that provides such integration services, which adversely affects the time at which the MMSC <b>104</b> can be implemented in the network. The problem of requiring such integration is exacerbated as new services and network elements continue to be designed and deployed in the network. The present invention solves these problems.

Further, charging for network services can be based on postpaid, prepaid, direct pay, and other real-time or non-real-time payment methodologies. As new network systems are presented in the networks, these various payment approaches add significant complexities to existing charging and billing methodologies. For example, as more and more real-time interaction is required between networks and Operations Support Systems (OSS) systems, custom solutions must continually be derived. The present invention provides a solution to these problems, by expeditiously and effectively managing charging transactions from a variety of new services, regardless of the particular charging paradigm implemented by these new services.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of a network <b>200</b> employing a charging edge <b>202</b> in accordance with the principles of the present invention. In accordance with the invention, an Intelligent Charging Edge™ (ICE™) <b>202</b> is provided as a charging layer of the network <b>200</b>. The ICE <b>202</b> provides an interface between the network elements and servers <b>204</b> and the billing and/or charging elements <b>206</b>. The ICE <b>202</b> communicates with the network elements <b>204</b> as represented by links <b>208</b>, and also communicates with the charging elements <b>206</b> as represented by links <b>210</b>. The ICE <b>202</b> network layer essentially isolates the charging elements <b>206</b> from the network elements <b>204</b>, thereby allowing data conversions and other processing to be performed while allowing both the network and charging elements to be otherwise unaware of each other. The ICE <b>202</b> removes the requirement that one or both of the network and charging elements be subject to integration, which further eliminates the need for integration service logic from residing in either the charging or network elements. This allows the charging elements <b>206</b> to do what they do best, which is charging and billing, while further allowing the network elements <b>204</b> to do what they do best, which is to provide the services in which they are designed. The interface between the two entities <b>204</b>, <b>206</b> is thus extracted from these entities, and provided in a new network layer represented as the intelligent charging edge <b>202</b>.

<figref idrefs="DRAWINGS">FIG. 3</figref> is another representation of a network <b>300</b> employing an intelligent charging edge <b>302</b> in accordance with the invention. This representation illustrates how the Intelligent Charging Edge (ICE) <b>302</b> isolates the network elements <b>304</b> from the charging and billing elements, such as the customer care and billing (CCB) system <b>306</b>, the rating engine <b>308</b>, and the prepaid server <b>310</b>.

The network elements <b>304</b> represent any network element that may provide a service requiring rating, charging, billing, invoicing, or other general billing functionality. For example, the network elements <b>304</b> may include Serving GPRS Support Nodes (SGSN), Gateway GPRS Support Nodes (GGSN) which acts as a gateway between the GPRS network and a packet switched public data network, home location registers (HLR), WAP gateways, payment servers, Mobile Switching Centers (MSC), Unstructured Supplementary Service Data Centers (USSDC), Multimedia Message Service Centers (MMSC), or any other network element.

The charging elements on the other side of the ICE <b>302</b> include the CCB <b>306</b>, the rating engine <b>308</b>, and the prepaid server <b>310</b>. The CCB <b>306</b> represents any type of charging and/or billing system. In one embodiment, the CCB <b>306</b> system offers a customer care and billing solution to meet the needs of ISPs and other companies offering Internet services. It may collect, store and administer customer information, and handle billing and payment requirements. The rating engine <b>308</b> gives service providers flexibility in pricing all service usage submitted by the data collection agents. A prepaid server <b>310</b> may be used for transactions involving prepaid customers. These charging elements are merely representative of various types of charging and billing systems, however the invention contemplates any type of charging and billing system that may be employed in the network.

The ICE <b>302</b>, as described above, essentially isolates the network elements <b>304</b> from the various charging elements to the extent that neither the network elements nor the charging elements need to be fitted for direct communication of charging information therebetween. The ICE <b>302</b> hides the complexity of the network from the charging elements, and hides the complexity of the external charging systems from the network. In this manner, third party integration from network or backend OSS systems is enabled. Charging and related intelligence is left to the ICE <b>302</b>, thereby allowing functionality with multi-vendor networks as well as multi-vendor Customer Relationship Management (CRM) and CCB systems.

The charging edge of the present invention therefore serves as a network layer, essentially buffering charging and billing elements from the various network elements that are, and will continue to be, availed to network service subscribers. The invention includes logically migrating network functionality that manages charging and billing operations away from the network elements and charging/billing elements, and into this new network layer. As will be described more fully below, this migration of charging and billing intelligence may also involve physically migrating charging and billing operations away from the network elements and charging/billing elements, but such physical separation is not necessary to implement the desired charging layer. This logical isolation allows the network elements to divorce themselves from the charging issue, and instead focus on the service that it provides. Analogously, the charging and billing elements need not be aware of the various types and quantities of network elements on the network, as the ICE layer manages the communication in a format required or preferred by the charging and billing systems. The intelligent charging edge provided by the invention includes systems that define boundaries of this charging edge, including an ICE “bridge” which serves to buffer the network elements and charging and billing elements in the desired manner. <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref> described below provide examples of how a bridging module in accordance with the present invention facilitates execution of various charging transactions.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram illustrating a prepaid transaction initiated by a network element in a network implementing a charging bridge to form an intelligent charging edge in accordance with the principles of the present invention. The network element <b>400</b> may represent any network system providing a service which is to be charged to the customer. Each network element in the network provides call detail information or other event records in some native format. For example, this information can be in ASCII format, XML, etc. Thus, while the example described in connection with <figref idrefs="DRAWINGS">FIG. 4</figref> is described in terms of an XML message, it should be recognized that this is for illustrative purposes, and any other current or future type of data format for document exchange may alternatively be used. This include any current or future standard, or proprietary, data format. Further, the example associated with <figref idrefs="DRAWINGS">FIG. 4</figref> identifies fields associated with an exemplary event record, however those skilled in the art will readily appreciate that any type of field may be associated with an event record, and those depicted in <figref idrefs="DRAWINGS">FIG. 4</figref> are merely representative.

The network element <b>400</b> sends event record data via an XML message <b>402</b> to the charging edge bridge, referred to as the Intelligent Charging Edge (ICE) bridge <b>404</b>. The ICE bridge <b>404</b> is an intelligent interface between the network and OSS domains, and performs a variety of functions including rule-based data transformations and interface management operations. For example, conversion rules may be applied such that when a network element generates a charging event, it is transformed by the bridge <b>404</b>. Prior art network environments would require integration and translation at the charging center, as described in connection with <figref idrefs="DRAWINGS">FIG. 1</figref>. Therefore, if a network element provides information in the form of, for example, URLs (uniform resource locator), the number of bytes transferred, etc., the bridge <b>404</b> can translate that information into a format that is meaningful to the ultimate charging/billing destination.

The bridge <b>404</b> can also recalculate fields, to convert data to a particular format identifiable by the charging and billing system. For example, a piece of charging information identified at a network element may be identified in bytes, and the bridge <b>404</b> can convert this to kilobytes if that is the format desired by the charging destination. Another example is that the network element could assign numbers, symbols, or other non-descriptive identifiers to fields such as URL fields, such as assigning a value of “1” to a first URL associated with the service. The bridge <b>404</b> can convert that identifier to a textual, graphic, or other “descriptive” identifier more readily usable by the charging center and that properly identifies the particular service utilized by the customer. In other words, when billing, a meaningful service identifier should be provided to the customer so that the customer is aware of the particular service (e.g., URL) used. Fields may need to be combined, and mathematical calculations performed to provide the information in the appropriate format, which can be accomplished by the ICE bridge.

Other functions that can be carried out by the bridge <b>404</b> include filtering and routing functions. Conventionally, CDRs are all sent to the billing system, but if there is an error in a CDR it should not be charged for, and the charging center was traditionally responsible for dropping the CDR upon receipt and notification that the CDR was erroneous. The bridge can perform such filtering tasks at the network element, before the erroneous charging event is sent to the charging and billing system. Often charging events are sent to multiple destinations in addition to the charging and billing system, such as a data warehousing facility. Routing charging events can also be managed by the bridge <b>404</b>, as well as other functions.

The bridge can also coordinate charging information generated by multiple network elements involved in a single session or call. In other words, a session or call may involve multiple network elements, each of which produces information that may be used to generate a charging event for that session. As dictated by the rules associated with the bridge <b>404</b>, the bridge can collect and coordinate the charging information generated by the various network elements, and make rule-based decisions in response. For example, the bridge <b>404</b> can decide, based on the rules, to independently handle each of the charging information records from each of the network elements associated with the session. In this case, multiple charging events may result. Alternatively, the bridge <b>404</b> can determine that the rules are to be collectively considered, such that all or a portion of the collected charging information is used to create one or more charging events. The use of the bridge and the intelligent charging edge in connection with charging information generated by multiple network elements is described in greater detail in connection with <figref idrefs="DRAWINGS">FIG. 13</figref>.

The creation of the intelligent charging edge enables the network elements and charging/billing elements to essentially be unaware of each other. This arrangement allows a new service in a new network element to be quickly deployed, and allowing the bridge <b>404</b> to perform the interfacing functions. The information from each of the configured network elements can be collected via a single interface to the bridge <b>404</b>, and the charging and billing system does not need to be cognizant of, nor integrated to work in connection with, any of the network elements.

In the illustrated example of <figref idrefs="DRAWINGS">FIG. 4</figref>, the message from the network element <b>400</b> to the ICE bridge <b>404</b> includes a user number <b>406</b>, such as the user's phone number or other user identifier. An authorization request <b>408</b> is also part of the message <b>402</b>, which is a request for authorization to use the requested service. The network element <b>400</b> also sends an accessed content type (ACT) <b>410</b>, identifying the particular type of content that is requested and is to be charged. In this example, the ACT <b>410</b> identifies an MPEG (Moving Pictures Experts Group) file at a transfer rate of 34 Kbps. The message <b>402</b> also includes a network element identification (NE ID) <b>412</b>, which in this example identifies the network element as an MMSC.

This event record may be unique to the particular network element <b>400</b>, and is therefore provided in a format predefined by the network element <b>400</b>. Conventionally, providing an event record in a unique format would require integration modules to be implemented at the charging and billing system. This would not be unusual that a network element does not provide event records in a format comprehensible by the destination charging/billing system, as network elements may assume a particular format for an end charging system which changes during the development of the network element.

The ICE bridge <b>404</b> solves this problem. The bridge <b>404</b> may be a distinct module (e.g., server) or may be integrated with another module, such as an all-IP charging gateway, a network element, or an OSS element. The bridge <b>404</b> intercepts the message <b>402</b> from the network element <b>400</b>. Using Application Programming Interfaces (API), the network element <b>400</b> can provide the event record in a communicable format with the ICE bridge <b>404</b>. Upon receipt, the bridge <b>404</b> uses predefined event management rules to analyze the network element identifier (NE ID), the authorization request, or other predetermined parameter to recognize that the request is for access to the CRM (Customer Relationship Management) system <b>414</b> or other CCB system. The bridge <b>404</b> determines the format required by the CRM system <b>414</b>, extracts the appropriate information, and generates an API call <b>416</b> to the CRM <b>414</b> or other CCB system. Using predefined business rules, the ICE bridge <b>404</b> generates the API call <b>414</b> in a transformed format recognizable to the CRM system <b>414</b>, such as the native format of the CRM <b>414</b>.

In this example, the ICE bridge <b>404</b> determined that the CRM system <b>414</b> requires a user identifier <b>418</b>, and a product identifier <b>420</b>. The API call <b>416</b>, named the CRM_AA_USER call in this example, provides the user and product identifiers <b>418</b>, <b>420</b> as parameters of the API call <b>416</b>. In this example, the user identifier <b>418</b> requires no transformation from the user identifier <b>406</b> generated by the network element <b>400</b>, and it can be directly passed to the CRM system <b>414</b>. This is determined by the bridge <b>404</b>. However, the business rules associated with the bridge <b>404</b> determine that the CRM system <b>414</b> also requires a “product” identifier <b>420</b>, which does not directly correspond to any of the parameters provided in the XML message <b>402</b>. Therefore, the ICE bridge <b>404</b> transforms the relevant event record information in the XML message <b>402</b> to the requisite product identifier <b>420</b>, which in this example is identified by “MP3 DOWNLOAD.”

When the CRM system <b>414</b> receives the API call <b>416</b>, it analyzes the received information in the format required by the CRM <b>414</b>. The CRM <b>414</b> did not need to know anything about the network or network element <b>400</b> sending the request, and did not need to convert any information. Rather, the CRM <b>414</b> receives the information in a format recognizable by the CRM <b>414</b>, processes the information, and returns a status message <b>422</b> indicative of whether the requested service is authorized. In this example, the returned status indicates that the requested service is authorized.

The status from the CRM <b>414</b> is returned to the ICE bridge <b>404</b>. In this manner, the bridge <b>404</b> again bridges the CRM <b>414</b> and the prepaid system server <b>424</b>. Using predefined rules, the ICE bridge <b>404</b> determines that the prepaid server <b>424</b> is now to be called. An API call <b>426</b>, referred to as the SMI RESERVE MONEY call, includes parameters such as a user identifier <b>428</b>, and a “content” identifier <b>430</b>. In this example, the user identifier <b>428</b> requires no transformation from the user identifier <b>406</b> generated by the network element <b>400</b>, and it can be directly passed to the prepaid system <b>424</b>. Again, this determination is made by the bridge <b>404</b>. However, the business rules associated with the bridge <b>404</b> determine that the prepaid system <b>424</b> also requires a “content” identifier <b>430</b>, which does not directly correspond to any of the parameters provided in the XML message <b>402</b>. Therefore, the ICE bridge <b>404</b> transforms the relevant event record information in the XML message <b>402</b> to the requisite content identifier <b>430</b>, which in this example is identified by “MULTI-MEDIA SERVICE.”

When the prepaid system <b>424</b> receives the API call <b>426</b>, it analyzes the received information in the format required by the prepaid system <b>424</b>. The prepaid system <b>424</b> did not need to know anything about the network or network element <b>400</b> sending the request, and did not need to convert any information. Rather, the prepaid system <b>424</b> receives the information in a format recognizable by the prepaid system <b>424</b>, processes the information, and returns a status message <b>432</b> indicating whether the customer had the appropriate balance to carry out the requested transaction. In one embodiment, the returned message <b>432</b> may also identify the charge and balance amounts (e.g., $5 and $4 respectively). In this example, the returned status indicates that the requested service has been appropriately charged.

The ICE bridge <b>404</b> recognizes this message <b>432</b>, and notifies the network element <b>400</b> via a message <b>434</b>, thereby approving use of the service hosted by the network element <b>400</b>. At this point, other functions may optionally be carried out. For example, a service bar/unbar function may be implemented, which enables or disables particular services for that user. <figref idrefs="DRAWINGS">FIG. 4</figref> indicates that when the bridge <b>404</b> receives the message <b>432</b> from the prepaid system <b>424</b>, it may optionally generate a barring message <b>436</b> to the CRM <b>414</b> for certain services having a cost greater than the current balance provided by the prepaid system <b>424</b> to the bridge <b>404</b> in the status message <b>432</b> (e.g., $4 balance). For example, if “products” identified via the product identifier <b>420</b> of “MP3 DOWNLOAD” cost a predetermined amount (e.g., $5) that is greater than the balance (e.g., $4) identified by the prepaid system <b>424</b>, then further attempts to obtain “MP3 DOWNLOADS” or other services costing more than the predetermined amount must be barred. This barring message <b>436</b> is sent from the bridge <b>404</b> to the CRM <b>414</b> to notify the CRM <b>414</b> that the balance is below a predetermined limit. The CRM <b>414</b> can then provide the appropriate unauthorized status via status message <b>422</b> on subsequent attempts to access an MP3 DOWNLOAD (for example).

Similarly, a barring message may also be sent to other network elements in the network, such as depicted by the barring message <b>438</b> to the home location register (HLR) <b>440</b>. The HLR <b>440</b> represents a network element that may contain the network level information, such as profile information or service records, for the requested service. Yet further messages may be initiated by the bridge <b>404</b>, such as the “top-up” message <b>442</b>. This message <b>442</b> may be directed to the user, such as via a Short Message Service (SMS) message, e-mail message, or other messaging mechanism known in the art. Such a message may be used to notify the user that the prepaid balance is below a certain threshold which will bar the user from accessing particular services, and thus serves as a reminder to the user to replenish the account.

<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram illustrating a postpaid transaction initiated by a network element in a network implementing a charging bridge in accordance with the principles of the present invention. The network element <b>500</b> may represent any network system providing a service which is to be charged to the customer. Each network element in the network provides call detail information or other event records in some native format. As was described in connection with <figref idrefs="DRAWINGS">FIG. 4</figref>, this information can be in ASCII format, XML, etc., and is described in terms of an XML message for purposes of illustration. Again, it should be recognized that the examples utilizing XML is for illustrative purposes, and any other current or future type of data format for document exchange may alternatively be used, including any current or future standard, or proprietary, data format. The network element <b>500</b> sends event record data via an XML message <b>502</b> to the charging edge bridge, referred to as the Intelligent Charging Edge (ICE) bridge <b>504</b>. As in <figref idrefs="DRAWINGS">FIG. 4</figref>, this exemplary message includes a user number <b>506</b>, an accessed content type (ACT) <b>510</b>, and an network element identification (NE ID) <b>512</b>, which in this example identifies the network element as an MMSC.

The bridge <b>504</b> ascertains from information contained in the XML message <b>502</b> whether this request is associated with a prepaid, postpaid, hot billing, or other charging paradigm. In this example, it is determined by the bridge <b>504</b> that the request is associated with a postpaid charging paradigm, and an API call <b>514</b> can be directly dispatched to the charging and billing system <b>516</b>. However, before this API call <b>514</b> is sent, the ICE bridge <b>504</b> performs the necessary transformations of the XML message <b>502</b> content to place the information into a format recognizable by the charging and billing system <b>516</b>. For example, the parameters <b>506</b>, <b>510</b>, <b>512</b> are received by the bridge <b>504</b>, and transformed into an API call referred to as the FORWARD call having parameters such as a user identifier <b>518</b>, and a “content” identifier <b>520</b>. In this example, the user identifier <b>518</b> requires no transformation from the user identifier <b>506</b> generated by the network element <b>500</b>, and it can be directly passed to the charging and billing system <b>516</b>. This determination is made by the bridge <b>504</b>. However, the business rules associated with the bridge <b>504</b> determine that the charging and billing system <b>516</b> also requires a “content” identifier <b>520</b>, which does not directly correspond to any of the parameters provided in the XML message <b>502</b>. Therefore, the ICE bridge <b>504</b> transforms the relevant event record information in the XML message <b>502</b> to the requisite content identifier <b>530</b>, which in this example is identified by “MULTI-MEDIA SERVICE.”

When the charging and billing system <b>516</b> receives the API call <b>514</b>, it accepts the information, and adds the corresponding cost amount to an aggregated total for the user. The identifying information supplied such as the user identifier <b>518</b> and content identifier <b>520</b> can also be used by the billing system. The billing portion of the charging and billing system <b>516</b> can use this information to identify the transaction particulars and cost to the subscriber in a generated invoice.

The examples of <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref> are merely exemplary embodiments of the types of charging transactions that can be effectively managed by the ICE. The examples of <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref> are directed to prepaid and postpaid transactions respectively. However, the present invention is applicable to any type of charging paradigm, whether prepaid, postpaid, real-time, direct pay, etc. Further, the ICE is applicable to otherwise non-traditional charging categories that do not even fall into a currently known charging category.

As an example, a situation is described herein of a charging situation that would require an elaborate and complex solution in prior art charging systems, but is effectively managed by the principles of the present invention. This example does not necessarily fall into a currently known charging category such as prepaid, postpaid, etc. This example is provided to illustrate the ability of the ICE to be used as an intelligent buffer between the network and OSS systems, which circumvents the need for either the network or the targeted OSS system to be reconfigured to directly manage such a situation therebetween. Assume a wireless terminal user is browsing the network via a wireless terminal, such as a wireless telephone. The user comes across a web site hosted by a small, otherwise unknown bookstore, and desires to purchase a book. However, the user may not trust this unknown bookstore, and is hesitant to provide any personal or financial information in order to effect the purchase. In accordance with the invention, such a service provider can, for example, partner with known operators. This is beneficial to the service provider, as the small service provider does not need a separate charging and billing system, rating engine, etc. for the relatively small service provided, and in effect can use the operator's charging and billing systems. This is also beneficial to the user, as the user may be willing to provide the information to a known, partnering operator. For example, the operator could be the company that the user uses for telephone service, wireless service, Internet service, or some other company that the user is familiar with or otherwise conducting business with. The small service provider can provide an indication or link on the web site that he/she is a value-added reseller for this associated operator. The user can then just identify the book desired, and upon ordering, a message is sent to the Intelligent Charging Edge, which determines that the service provider exists and is authenticated. The user's information can already be stored by the operator, and when the user orders the book, the service provider charges the operator, and the operator puts the charge on the user's bill (or adjusts a prepaid account, etc.). This type of transaction, while not falling into a specific postpaid, prepaid, etc. category, can be effectively managed by the ICE in accordance with the present invention. This is just one example of how the ICE can be used to carry out otherwise complex and non-traditional charging transactions and payment methods that would require custom solutions in prior art systems.

Referring now to <figref idrefs="DRAWINGS">FIG. 6</figref>, an exemplary embodiment of a charging edge bridge <b>600</b> is provided in accordance with the principles of the present invention. In accordance with one embodiment of the invention, the charging edge bridge <b>600</b> is attached to the core network, but can alternatively be attached near the core network. A network element <b>602</b> requiring communication with one or more charging/billing components is equipped with a software plug-in module <b>604</b>. As is known in the art, Java™ is a general-purpose, object-oriented language, and is a “write once, run anywhere” programming language. Because Java is used extensively by object-oriented developers, the present example assumes a java-based implementation at the network element. However, it should be recognized that the invention is equally applicable to any data format or programming language used at the network element, such as CORBA, C++, SQL, COM, and other languages or specifications. XML is a text-based markup language that is currently used extensively for data interchange on the Web. As with HTML, data is identified using tags, which are collectively known as “markup”. XML tags identify the data, and act as a field name in the program. As is known in the art, an Application Program Interface (API) is an interface that enables programs to communicate with each other. The present examples assumes a Java-XML API for purposes of illustration. However, it should be recognized that other APIs may alternatively be implemented, depending on the interface utilized. Thus, in one embodiment, this plug-in module <b>604</b> is a JavaXML API serving as a communication interface to communicate XML messages, in this example, with the bridge <b>600</b>.

The XML message <b>606</b> is received at the bridge <b>600</b>, and provided to a transformer module <b>608</b>. Because this particular example involves an XML message <b>606</b>, the transformer module <b>608</b> is an XML transformer. The transformer <b>608</b> performs translations of the event record(s) contained in the XML message <b>606</b> by applying predefined business rules <b>610</b>. In this particular example, the business rules are described in XSL (eXtensible Stylesheet Language), although XSL is just one of many ways in which such rules may be described in accordance with the invention. Generally, XSL can be used to convert XML documents into other formats. The XML transformer <b>608</b> applies a particular one or more sets of the rules <b>610</b> to the XML file <b>606</b> to create a new document, file, data stream, etc. (hereinafter referred to as a file) in another format. Again, it should be recognized that the specific use of XML and XSL in this example is for purposes of illustration; however the invention is applicable to any input message format and any predefined rules to generate a transformed file at the output of the transformer <b>608</b>.

Using the rules <b>610</b>, the transformer <b>608</b> determines what should be done with the XML message <b>606</b>. In one embodiment, the rules <b>610</b> direct the transformer <b>608</b> to convert certain parameters from the XML message <b>606</b> into a format that can be recognized by the targeted charging/billing element. When applied to the XML message <b>606</b>, the rules <b>610</b> also determine which of the charging/billing elements is to be called. For example, the rules may indicate that the destination device is dependent on the network identifier (NE ID) and/or an authorization request. More particularly, the rules may indicate that if the NE ID is, for example, an MMSC, then the charging/billing device to be called is a CRM.

Thus, the resulting file <b>612</b> from the XML transformer <b>608</b> includes a transformed version of the XML message <b>606</b> provided by the network element <b>602</b>, along with instruction information identifying what should be done with this request. Based on this file <b>612</b>, a particular destination interface may be called. This is accomplished by providing the file <b>612</b> to the interface object management module <b>614</b>. Additional object configuration rules <b>616</b> are applied to the file <b>612</b> at the interface object management module <b>614</b>, to direct the information to the appropriate interface object associated with the interface object module <b>618</b>. It should be noted that although the interface objects module <b>618</b> is depicted as integral to the ICE bridge <b>600</b>, this module may be separate from the bridge <b>600</b>, such as in a separate server. A variety of interface objects may be provided, so that when a new charging/billing system is deployed in the network, a corresponding interface object can be provided. For example, if a new CRM is included in the network, the bridge <b>600</b> can be equipped with a CRM interface object <b>620</b> so that the new CRM can be called. Other examples of interface objects are also shown, such as the HLR <b>622</b>, prepaid system <b>624</b>, and SMS Gateway API <b>626</b> interface objects. Any number of interface objects can be provided, at least one for each charging/billing systems to be used in the network.

The object configuration rules <b>616</b> facilitate selection of the appropriate one of the interface objects. In other words, the rules <b>616</b>, in connection with the information file <b>612</b>, allow the interface object management module <b>614</b> to find the appropriate interface object. For example, the rules <b>616</b> applied to the file <b>612</b> at the interface object management module <b>614</b> may generate an address to the appropriate interface object, whether that interface object is located in the bridge, or in a separate system remote from the bridge <b>600</b>.

As an example, the transformer <b>608</b> transforms the information from the XML message <b>606</b> to a different format, such as a format containing actual object names, method names and attributes, etc. This transformation is facilitated by the business rules <b>610</b>. The interface object management module <b>614</b> will call each object in this resulting information file <b>612</b>, based on the rules <b>616</b>.

Referring briefly to <figref idrefs="DRAWINGS">FIG. 7</figref>, which corresponds to the prepaid charging transaction described in connection with <figref idrefs="DRAWINGS">FIG. 4</figref>, each of five calls that are made to interface objects in the charging transaction are identified by the letters A, B, C, D, and E. After the network element <b>700</b> sends a message to the ICE bridge <b>702</b>, the bridge <b>702</b> sends an API call, designated by the letter A, to the CRM system <b>704</b>. When the bridge <b>702</b> receives an authorized status, it sends an API call B to the prepaid system <b>706</b>. Barring calls may be made to the CRM <b>704</b> and HLR <b>708</b> as shown by designations C and D respectively. Finally, a top-up call E may be made to notify the user to replenish the account.

These calls are also shown in <figref idrefs="DRAWINGS">FIG. 6</figref> as corresponding calls A, B, C, D, and E. Call A is made to the CRM, which occurs via the CRM interface module <b>620</b>. Call B is made to the prepaid system via the prepaid system object interface <b>624</b>, as shown by call B. Barring calls are made to the CRM and HLR via CRM interface object <b>620</b> and HLR interface object D respectively. Finally, the top-up call E is made to an SMSC via the SMS gateway API object interface <b>626</b>. A reply message <b>630</b> to the network element <b>602</b> may also be made to notify the network element <b>602</b> of information such as the approval of the requested service. This is also shown in <figref idrefs="DRAWINGS">FIG. 7</figref> by the reply message <b>710</b>, which further corresponds to reply message <b>434</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>.

<figref idrefs="DRAWINGS">FIG. 8</figref> is an exemplary embodiment of a network <b>800</b> employing an intelligent charging edge (ICE) layer in accordance with the principles of the present invention. In this embodiment, multiple network elements <b>802</b>, <b>804</b>, <b>806</b>, <b>808</b> are coupled to the network. Various charging and billing elements <b>810</b>, <b>812</b>, <b>814</b>, <b>816</b> are also coupled to the network, to carry out the various billing functions required by the network elements <b>802</b>-<b>808</b>. The network elements <b>802</b>-<b>808</b> are essentially part of the traditional network portion of the network, while the charging elements <b>810</b>-<b>816</b> are part of the OSS side of the network. The ICE bridge <b>820</b> represents the network-to-OSS interface for this larger network <b>800</b>.

Each of the network elements includes an API, which may be a plug-in module. For example, the network element <b>802</b>, which is a WAP gateway in this example, is equipped with an API plug-in <b>822</b>. Similarly, network elements <b>804</b>, <b>806</b>, through <b>808</b> are equipped with, plug-in modules <b>824</b>, <b>826</b>, through <b>828</b> respectively. As described above, these plug-ins <b>822</b>-<b>828</b> include an API, such as a Java-XML API known in the art. The network elements call their respective API when a charging event is available, and the API carries out the necessary steps to efficiently pass the charging event over the network using an appropriate protocol to the bridge <b>820</b>.

The API modules <b>822</b>-<b>828</b> are, in the illustrated embodiment, designed to be used with charging events in Extensible Mark-up Language (XML) <b>830</b>. XML is a computer language that is used to format data into a text file in an organized manner, which can be easily generated and read by a computer. It uses tags of the form &lt;word&gt; to delimit pieces of data and attributes for putting values to tags. However, it will be readily apparent to those skilled in the art from a reading of the description provided herein that other suitable languages and/or mark-up languages could be used.

Analogously to that described in connection with <figref idrefs="DRAWINGS">FIG. 6</figref>, the XML <b>830</b> message is received at the bridge <b>820</b>, and provided to the XML transformer module <b>832</b> which performs translations of the event records (e.g., CDRs) contained in the XML message by applying predefined business rules <b>834</b>. Using the rules <b>834</b>, the transformer <b>832</b> determines what should be done with the XML message, and in one embodiment the rules <b>834</b> direct the transformer <b>832</b> to convert certain parameters from the XML message into a format that can be recognized by the targeted charging/billing element <b>810</b>-<b>816</b>. The rules <b>834</b> also determine which of the charging/billing elements is to be called.

Based on the information provided by the XML transformer <b>832</b>, a particular destination interface may be called by providing the information to the interface object management module <b>836</b>. Additional object configuration rules <b>838</b> are applied to the information received at the interface object management module <b>836</b>, to direct the information to the appropriate interface object associated with the interface object module <b>840</b>. The interface objects module <b>840</b> may be integral or external to the ICE bridge <b>820</b>. A variety of interface objects may be provided, so that when a new charging/billing system is deployed in the network, a corresponding interface object can be provided. The bridge <b>820</b> can be equipped with multiple interface objects, such as the CRM interface object <b>842</b>, HLR interface object <b>844</b>, prepaid system <b>846</b>, SMS gateway API <b>846</b>, or others. The object configuration rules <b>838</b> facilitate selection of the appropriate one of the interface objects. These interface objects facilitate the interface with the corresponding one of the OSS systems. For example, the charging event in its transformed form is provided to the charging and billing system (i.e., CRM) <b>810</b> via the CRM interface object <b>842</b>.

An intelligent charging edge in accordance with the present invention may implement one or more ICE bridges. The bridge(s) may be implemented in a separate network server device, or alternatively may be physically located at any point between the network elements and the OSS elements. While the physical location of the bridging elements may vary, the implementation of these bridges provides a logical network layer that effectively buffers the network domain from the OSS (e.g., charging/billing) domain.

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates an embodiment of one manner of employing a plurality of charging edge bridges in a network system <b>900</b>. The “charging edge” <b>902</b> essentially isolates the network elements and the OSS elements. In the illustrated example, various groups of OSS elements <b>904</b>, <b>906</b>, <b>908</b> each include charging, billing, rating, invoicing, and/or other charging-related devices. As part of the network, various network element groups <b>910</b>, <b>912</b>, <b>914</b> include network elements such as those previously described. Each group of network elements communicates with one or more OSS elements via at least one charging edge bridge which forms part of the intelligent charging edge <b>902</b>. For example, bridge <b>918</b> bridges the network elements <b>912</b> and the OSS elements <b>906</b>. As can be seen, any number of bridges can be used in creating the intelligent charging edge.

The bridging modules may be physically located at any point between the network and OSS elements. In one exemplary embodiment, the ICE bridge is a separate server, such as ICE bridge <b>918</b>. In such an embodiment, the bridge <b>918</b> is physically distinct from either the network elements or OSS elements in which it interfaces. In another embodiment, a bridge <b>916</b> is located proximate or integral to a particular network element <b>917</b>. The intelligent charging edge <b>902</b> is extended into the network domain <b>910</b> in this case to logically include the bridge <b>916</b>, thereby illustrating that the physical location does not impact the logical charging edge.

Similarly, another embodiment illustrates that a bridge <b>920</b> may be physically located proximate or integral to a particular charging/billing system <b>921</b>. For example, the charging/billing system <b>921</b> may be an extensive billing system capable of performing billing services for a substantial number of network elements, thereby warranting physical implementation of a bridge <b>920</b> proximate to that charging/billing system <b>921</b>. Again, the ICE <b>902</b> is extended into the OSS domain <b>908</b> in this case to logically include the bridge <b>920</b>.

An additional issue arising when implementing the ICE bridges <b>916</b>, <b>918</b>, <b>920</b>, etc. is the manner in which these bridges are configured. As previously described, each bridge includes various types of rules that are applied which gives the ICE bridge the intelligence needed to essentially eliminate such responsibility from either the network or OSS devices. In a preferred embodiment of the invention, a person/entity such as a service designer who enters the rules does not need to be aware of the number of bridging devices or other devices associated with the ICE layer. Rather, rules are entered in a general fashion, and the systems of the intelligent charging edge route the rules to the appropriate bridging devices. One manner of achieving this is to populate the ICE bridges <b>916</b>, <b>918</b>, <b>920</b> by having rules entered at a particular, centralized ICE bridge. For example, through a rule input console <b>922</b>, all rules are entered into the primary bridge <b>918</b>. Primary bridge <b>918</b> then appropriately distributes the rules to other bridges <b>916</b>, <b>920</b> that have responsibility for only a certain set of services, as depicted by rule distribution paths <b>924</b>, <b>926</b> respectively.

A more particular example assumes a number of services, such as five services A, B, C, D, E. Services A and B may be handled by bridge <b>918</b>, and the remaining services C, D, E may be handled by bridge <b>916</b>. Bridge <b>918</b> is made the primary bridge. When rules are entered at the rule input console <b>922</b>, these rules will be directed to the primary bridge <b>918</b>. In one embodiment, this holds true regardless of the number and locations of various rule input consoles <b>922</b>, such that initial entry of rules from any input location will be directed to the primary bridge. The collective rules entered at the various rule input consoles represent the rules intended for the services A, B, C, D, E. These rules are targeted to a particular service, however, and the primary bridge <b>918</b> routes rules intended for particular services to the bridges that serve those particular services. For example, the primary bridge <b>918</b> maintains possession of the rules that it will use to bridge the network element group <b>912</b> and the OSS elements <b>906</b>, and will pass on rules to bridges <b>916</b> and <b>920</b> for interfacing network element groups <b>910</b> and <b>914</b> with OSS elements <b>904</b> and <b>908</b> respectively. In this manner, the bridges that are not designated as the primary bridge (e.g., bridges <b>916</b>, <b>920</b>) will receive their respective rules from the primary bridge <b>918</b>, and will not know, or need to know, about services unrelated to its specific duties.

With respect to the rule input system <b>922</b>, this can be any computing device or terminal capable of receiving such rules. For example, a graphical user interface (GUI) may be provided for a user to create and enter rules in a user-friendly environment, essentially identifying what actions should be taken for particular services provided by the network elements. The back end of that GUI then maps these rules from the GUI to different ICE bridges, which is first directed to the bridge designated as the primary, centralized bridge. Thus, the primary bridge pushes rules towards the network to various other bridges, while the collective bridging and other elements maintain these rules at the intelligent charging edge. The primary bridge maintains information as to which ICE bridge will be managing which services. This can be accomplished, for example, by having each ICE bridge notify the primary bridge as to which services/network elements it will be serving. The primary bridge can be loaded with this mapping information through other means as well.

Application of these rules was discussed in connection with <figref idrefs="DRAWINGS">FIG. 6</figref>. Any number of rules may be applied, depending on the service and the desired actions. <figref idrefs="DRAWINGS">FIG. 10</figref> illustrates some exemplary types of business rules utilized in a bridge <b>1000</b>. Bridge <b>1000</b> is analogous to the bridge <b>600</b> described in connection with <figref idrefs="DRAWINGS">FIG. 6</figref>, and includes XML message <b>1002</b>, a rules processing module <b>1004</b> including transformer module <b>1006</b> and interface object management module <b>1008</b>, and interface object module <b>1010</b>. In this embodiment, three types of rules are illustrated, including message identification rules <b>1012</b>, actions rules <b>1014</b>, and backend system processing rules <b>1016</b>. The message identification rules <b>1012</b> include information as to how to identify messages via values, value ranges, properties, attributes, etc. in the incoming message. An initial transformation of the message includes utilizing the rules to specify what actions are to be taken when a message matches these predefined filtering rules. The conversion, field recalculation, filtering, and routing functions described in connection with <figref idrefs="DRAWINGS">FIG. 4</figref> are examples of the message identification and transformation rules.

The actions rules <b>1014</b> are those rules that specify what actions are to be taken for a given request that has been filtered. Examples of these actions are authentication, credit checks, determining whether a transaction is prepaid, postpaid, etc. Examples of these actions include the API calls <b>416</b>, <b>426</b>, <b>514</b> shown and described in connection with <figref idrefs="DRAWINGS">FIG. 4 and 5</figref>.

Another tier of rules is the backend system processing rules <b>1016</b>. These rules interpret the responses returning from backend systems, and take the appropriate action. Examples of such actions include bar/unbar actions such as the barring messages <b>436</b>, <b>438</b> shown and described in connection with <figref idrefs="DRAWINGS">FIG. 4</figref>. Another example is the top-up message <b>442</b> shown in <figref idrefs="DRAWINGS">FIG. 4</figref>. In other words, these rules <b>1016</b> define actions to be taken in response to parameters recognized or received from the systems to which the bridge <b>1000</b> is interfacing with.

These rules govern the functions performed at the bridge <b>1000</b>. Given the general exemplary rules <b>1012</b>, <b>1014</b>, <b>1016</b> shown in <figref idrefs="DRAWINGS">FIG. 1000</figref>, a number of bridge functions can be performed. Incoming messages may be transformed to a required internal format as well as transformed to multiple formats required by backend servers in the OSS domain. The bridge <b>1000</b> also locates the appropriate business rules for a given message and executes the relevant business objects. Functions may be invoked in the backend servers (i.e., charging/billing/rating elements in OSS domain) to execute necessary authentication/authorization functions based on service type such as WAP, e-mail, GPRS, etc. Similarly, functions may be invoked in the backend servers to execute necessary authentication/authorization functions based on payment type such as prepaid, postpaid, direct pay, etc. Credit checks can be invoked in the backend servers through application of the appropriate rules, when credit checks are necessary. Advice of Charge, which allows customers to query the approximate charge for a call or service, may also be configured into business rules and managed by the bridge <b>1000</b>. In cases such as prepaid services where an account balance is maintained by a backend system, messages such as top-up messages and bar/unbar messages may be invoked in the backend systems via application of rules in the bridge <b>1000</b>. User status, balance, etc. can be synchronized with OSS systems and external prepaid servers, and real-time service-related changes to subscriber service settings or attributes may be performed by invoking functions in backend servers. Further, the bridge <b>1000</b> can make decisions as to how to route incoming charging-related messages based on the rules preprogrammed to the bridge <b>1000</b>. For example, as was described in <figref idrefs="DRAWINGS">FIG. 6</figref>, object configuration rules may be applied at an interface object management module to direct the information to the appropriate interface object. The bridge <b>1000</b>, in connection with the rules, can thus handle all transactions related to a single message in a transaction-safe manner. The aforementioned represent examples of the types of functions that can be performed by the ICE bridge in accordance with the present invention. However, as will be readily apparent from those skilled in the art from a reading of the description provided herein, other rules and corresponding bridge functions may also be implemented without departing from the scope of the invention.

Referring now to <figref idrefs="DRAWINGS">FIG. 11</figref>, a flow diagram is provided of a manner of implementing an intelligent charging edge in accordance with the principles of the present invention. One or more network elements hosting billable services may each transmit <b>1100</b> charging events. These charging events are intercepted at the bridge modules of the intelligent charging edge as shown at block <b>1102</b>. One or more bridge modules forming part of the ICE coordinate and manage charging transactions between the network elements and the charging elements in accordance with rules resident in the bridge modules, as shown at block <b>1104</b>.

A more particular, exemplary embodiment of a method for interfacing network elements in the network domain and elements in an OSS domain is provided in <figref idrefs="DRAWINGS">FIG. 12</figref>. The embodiment represented by, <figref idrefs="DRAWINGS">FIG. 12</figref> includes various particular features of the present invention. For example, a networking environment employing multiple bridge devices may include a designated primary bridge device. Business rules are input <b>1200</b> to the primary bridge device via any type of input terminal, console, or other input mechanism. Business rules applicable to the entire charging layer are provided to the primary bridge device, and those business rules applicable to one or more secondary bridge devices (if present) are distributed <b>1202</b> to the respective secondary bridge devices. Those business rules applicable to the primary bridge device are retained by the primary bridge device.

With the rules being in place, network elements may generate charging events <b>1204</b>, and transmit <b>1206</b> the charging events via an API. The charging events are recognized and intercepted <b>1208</b> by the bridge devices of the charging edge that are associated with the transmitting network elements. Where necessary, the bridges transform <b>1210</b> the charging event pursuant to the rules at that bridge. As previously described, such transformations are used to format the charging event in any manner that results in a format corresponding to the destination OSS device. For example, this transformation may include data conversion <b>1212</b>, which may include converting from an input message format to an output message format. The transformations <b>1210</b> of charging events may also include the recalculation of fields, as shown by block <b>1214</b>. This includes, for example, transforming representations of information into a format that is meaningful to the ultimate OSS device destination. More particularly, such a transformation may include transforming a symbolic or numeric URL identifying the service into a textual URL that is useful to a billing system in creating invoices. Another example is the recalculation of data amounts, such as converting a number of bytes transferred into a number of downloads or other unit used by the destination OSS system, or performing mathematical functions on the information to arrive at the appropriate units sought by the destination OSS system.

The transformation <b>1210</b> may also include filtering <b>1216</b> and routing <b>1218</b>. Filtering <b>1216</b> includes, for example, dropping charging events due to an error in the charging event. The bridge performs this function, thus allowing these erroneous charging events to be dropped before reaching a destination charging/billing system. Further, charging events are often sent to multiple destinations in addition to the charging and billing system, such as to a data warehousing facility. Routing charging events <b>1218</b> can also be managed by the bridge <b>404</b>. Other transformation functions may also be performed in accordance with the invention, and the aforementioned are representative examples of transformations that may be performed.

A charging event, while representing a single message, may involve multiple transactions with various OSS elements. Such an example was described in the example corresponding to <figref idrefs="DRAWINGS">FIG. 4</figref>. In such a case, the information is extracted by the bridge, and a transaction sequence is coordinated <b>1220</b>. For example, in a prepaid scenario, the bridge may extract information from the charging event and recognize that calls will need to be made to both a CRM and a prepaid system. The business rules are applied to the information in the charging event in order to arrive at this conclusion. For each particular transaction derived by the rules from the charging event, an interface object is located, and a call to the located interface object is made pursuant to the rules, as shown at block <b>1222</b>. For example, if a first transaction involves calling a CRM to authorize the service for the user, then a CRM interface object is located using the object configuration rules, and the call may be dispatched to the CRM via the CRM interface object.

The backend systems, i.e., the OSS systems to which the bridge makes calls, may provide responses. These responses may be in the form of status, such as authorized, not authorized, charges imposed, account balances, or any other status or feedback from the backend OSS systems. Such status may not be provided in some instances, such as when the bridge forwards a charging record to a charging and billing system in a postpaid scenario. In that case, the charging and billing system may simply accept the information provided by the bridge, and utilize the information in performing postpaid charging and billing functions. No response may be necessary. However, in other instances such as a prepaid or direct pay scenario, the backend system may provide authorization, status, or other information in response to the call made by the bridge. In such a case, these backend system responses are interpreted <b>1224</b> pursuant to the rules. For example, if a CRM system returned a “not authorized” status, rules provided in the bridge direct the bridge to notify the service that the user is not entitled to use the service. Other messages may also be provided in response to such a response, such as a message (e.g., e-mail, SMS, etc.) to the user to provide notification of the authorization failure.

Depending on the information provided in the charging event, and/or depending on responses received from the backend systems, the bridge may need to initiate additional calls to complete the entire charging transaction initiated by the charging event. If additional calls are required as determined at decision block <b>1226</b>, additional steps are taken to complete the charging transaction. In one embodiment, the transformation <b>1210</b> is performed once, which results in a complete set of instructions that define all of the further actions to be taken, and coordinated <b>1220</b>, to complete that charging transaction. In such an embodiment, the determination <b>1226</b> that additional calls are present in the transaction will return processing to block <b>1222</b> to locate the next interface objects in the sequence to dispatch transaction calls and interpret <b>1224</b> backend system responses. In otherwords, in such an embodiment, the transformation <b>1210</b> is performed once for the charging transaction, and the resulting transformed instructions determine the remaining actions for any further calls associated with the charging transaction.

In accordance with an alternative embodiment, the particular responses from called devices may be further transformed <b>1210</b>. Those received responses may thus be subjected to the transformation rules, as illustrated by the alternative dashed line returning from decision block <b>1226</b> to the transformation block <b>1210</b>. In this embodiment, when additional calls are associated with the charging transaction, additional transformations <b>1210</b>, transaction sequence coordinations <b>1220</b>, interface object locations and transaction calls <b>1222</b>, and backend system response interpretations <b>1224</b> may be required. For example, in the examples described in connection with <figref idrefs="DRAWINGS">FIGS. 6 and 7</figref>, five different calls were initiated by the bridge, including calls A, B, C, D, and E. When no additional calls are required for the charging transaction, the transaction ends <b>1228</b>.

The Intelligent Charging Edge described herein provides extensive flexibility in the exchange of information between the network and OSS domains. The ICE allows for a variety of different types of network elements to communicate effectively with a variety of different types of charging and billing elements, and allows the introduction of new network and OSS elements to be accomplished more easily and efficiently. Charging events originating from various network elements are effectively managed by the ICE layer, even where multiple network elements create different charging records associated with a particular session or call. As networks continue to migrate towards all-IP networks, a greater emphasis will be placed on coordinating and managing charging information originating from multiple network elements, yet associated with a single session. The Intelligent Charging Edge of the present invention can manage such situations where multiple network elements generate charging event information associated with a common session or call. An example illustrating such a situation is described in connection with <figref idrefs="DRAWINGS">FIG. 13</figref>.

<figref idrefs="DRAWINGS">FIG. 13</figref> is a block diagram of an exemplary network <b>1300</b> employing an intelligent charging edge <b>1302</b> to manage a session where multiple network elements generate different segments of a collective charging event. For purposes of explanation and not of limitation, the example of <figref idrefs="DRAWINGS">FIG. 13</figref> is described in terms of a voice-over-IP call. It should be recognized that the example of <figref idrefs="DRAWINGS">FIG. 13</figref> is equally applicable to any type of transmission, whether voice, data, images, video, etc.

In this example, multiple network elements <b>1304</b>, <b>1306</b>, <b>1308</b> are each involved in the call, and each may generate charging information for that call. For example, in the context of a GPRS network or third generation (3G) network, charging information may be generated by one network element regarding the volume of traffic communicated in the voice-over-IP call. Another network element may track the duration of the call. Still another network element may track the number of messages associated with the call. Each of these network element functions may thus produce information that may in some combination collectively serve as the charging event.

In accordance with the invention, the management of the various charging information is accomplished through application of the charging edge rules previously described. In accordance with one embodiment of the invention, these rules are provided in one or more ICE bridges <b>1310</b>. These rules determine what actions are to be taken for each of the charging information segments produced by the multiple network elements involved with the session. For example, if network elements <b>1304</b>, <b>1306</b>, <b>1308</b> each generate charging information for the same call, the rules will determine how to treat this charging information relative to the ultimate charging event that may be utilized by one or more of the charging elements such as the prepaid server <b>1320</b>, CCB <b>1322</b>, and rating engine <b>1324</b>. One rule may, for example, indicate that out of the information A, B, and C provided by network elements <b>1304</b>, <b>1306</b>, and <b>1308</b> respectively, only the information B and C will be utilized in the ultimate charging event, and the information A will be dropped. A business model, reflected in the business rules, will dictate such action. A different rule may, for example, determine that certain subscribers will be charged for all chargeable activity, in which case the charging information from each of the network elements <b>1304</b>, <b>1306</b>, <b>1308</b> can be independently handled by the ICE rather than gathering all of the information and making collective decisions. Again, the rules provided in connection with the ICE can effectively carry out such decisions and resulting actions.

Yet another rule may, for example, dictate that one or more charging information records from the various network elements be sent to a correlation element <b>1312</b>, such as a charging gateway, to correlate the information in the charging information records. Alternatively, or in addition to utilizing the correlation element <b>1312</b>, the rule(s) may dictate that a session management element <b>1314</b> be called upon. A session management element <b>1314</b> can monitor the events of the call, and thereby know what the user or subscriber is doing. The bridge <b>1310</b> can work closely with such correlation elements <b>1312</b> and session management elements <b>1314</b> to effectively manipulate the charging information from the various network elements into a desired charging event. In these instances, the correlation element(s) <b>1312</b> and session management element(s) <b>1314</b> in effect form part of the intelligent charging edge in this context. The bridge <b>1310</b> can work in connection with other elements forming part of the intelligent charging edge in an analogous manner.

For example, the bridge <b>1310</b> can determine whether or not correlation is even required for a particular session. In a more particular example, consider a WAP transaction. At least two different records may be produced in a WAP transaction, including a record from a GPRS network indicating the number of bytes transferred during the session, and another record from a WAP gateway indicating the URL that was visited. If a particular operator was only concerned with the URL for charging purposes, that operator may want to drop the record from the GPRS network. This can be accomplished using the rules associated with the intelligent charging edge <b>1302</b>. On the other hand, an operator may want to correlate the two records (i.e., number of bytes transferred and the URL visited) to arrive at some charge taking both records into consideration. Again, the rules associated with the intelligent charging edge can effect this desire by, for example, applying rules to directly effect such a correlation, or instead forwarding the records to the correlation element <b>1312</b>. Accordingly, the charging edge according to the invention provides the ability to coordinate potential charging information from multiple network elements, to ultimately produce a desired charging event that can be used by any one or more of the OSS elements such as charging elements <b>1320</b>, <b>1322</b>, <b>1324</b>.

It should be recognized that the aforementioned embodiments are representative examples of the various intelligent charging edge principles described herein, and the invention is not limited to these illustrated embodiments.

Using the foregoing specification, the invention may be implemented as a machine, process, or article of manufacture by using standard programming and/or engineering techniques to produce programming software, firmware, hardware or any combination thereof.

Any resulting program(s), having computer-readable program code, may be embodied within one or more computer-usable media such as memory devices or transmitting devices, thereby making a computer program product or article of manufacture according to the invention. As such, the terms “article of manufacture” and “computer program product” as used herein are intended to encompass a computer program existent (permanently, temporarily, or transitorily) on any computer-usable medium such as on any memory device or in any transmitting device.

Executing program code directly from one medium, storing program code onto a medium, copying the code from one medium to another medium, transmitting the code using a transmitting device, or other equivalent acts, may involve the use of a memory or transmitting device which only embodies program code transitorily as a preliminary or final step in making, using, or selling the invention.

Memory devices include, but are not limited to, hard disk drives, diskettes, optical disks, magnetic tape, semiconductor memories such as RAM, ROM, PROMS, etc. Transmitting devices include, but are not limited to, the Internet, intranets, telephone/modem-based network communication, hard-wired/cabled communication network, cellular communication, radio wave communication, satellite communication, and other stationary or mobile network systems/communication links.

A machine embodying the invention may involve one or more processing systems including, but not limited to, CPU, memory/storage devices, communication links, communication/transmitting devices, servers, I/O devices, or any subcomponents or individual parts of one or more processing systems, including software, firmware, hardware, or any combination or subcombination thereof, which embody the invention as set forth in the claims.

From the description provided herein, those skilled in the art are readily able to combine software created as described with appropriate general purpose or special purpose computer hardware to create a computer system and/or computer subcomponents embodying the invention, and to create a computer system and/or computer subcomponents for carrying out the method of the invention.

It will, of course, be understood that various modifications and additions can be made to the various embodiments discussed hereinabove without departing from the scope or spirit of the present invention. From the foregoing description of the illustrated embodiments, those of ordinary skill in the art will readily appreciate the applicability of the invention in any comparable network environment. Accordingly, the scope of the present invention should not be limited by the particular embodiments discussed above, but should be defined only by the claims set forth below and equivalents thereof.