Patent Application
20130297491
The technology relates to charging or financial account rendering for use of services, such as telecommunications services, for example.
For many products and/or services a customer or subscriber desires that a financial charge for the product/service be satisfied or paid from one or more of accounts, e.g., asset accounts owned by the customer or authorized for the customer's use. The debiting of the appropriate accounts, or reserving of assets in the appropriate accounts, is generally handled by a charging system.
For some products, such as telecommunication products, a product offering configuration is typically prepared separately from and subsequently to design of the charging system which will be utilized to charge the customer for use of the product. By “product offering configuration” is meant the information which identifies or describes a product, e.g., a new product. In view of the pre-existent nature of the charging system, charging for the use of the product is dependent upon the account selection mechanism of the conventional charging system. This means that charging for new products must occur within the constraints of the account selection mechanism of the conventional charging system.
The account selection component attempts to determine, from account pre-analysis, what account(s) may be used based on a subscription for the identified customer. The input to query an account selection component is a combination of customer identifier, the segment (e.g., service class) of the customer, the service type, and maybe some other parameters that may be obtained from the network. Since one subscriber may have several different accounts, the account selection component attempts to determine which of the accounts are to be used (e.g., charged), or even if the account of another subscriber should be debited (e.g., a shared account).
It may be that plural accounts are found by the account selection component of the charging system. At this point the price for the service has not been calculated, the charging system now knowing basically only that a certain type of service used, who is calling and who is being called, to which segment or quality class the call belongs, and which accounts for are eligible for charging.
Then a service class rating component of the charging system is consulted via a rating request in order, e.g., to identify the priority order for the account. When the service class rating is obtained, the charging system may start calculating the price for that service (e.g., a cost calculation). For example, if the call is a voice call during busy hour, the call may cost X per minute, and for a reservation of y minutes, and then the charging system will calculate what the cost for the reservation, and then try to reserve money from one or more eligible accounts maintained by the account component of the charging system.
The charging system may employ one or more quote requests in order to try to reserve money from one or more accounts which have been identified as eligible accounts. The charging system receives a quote result from each account queried with a quote request. For example, the charging system may use a first quote request to first try to reserve money from a first eligible account. If the first eligible account has insufficient balance or is otherwise unavailable as indicated by the first quote result, the charging system will continue with a second quote request for a next eligible account, and then continue in a priority order of accounts until the charging system is able to reserve as much money as needed. It may be that one or more accounts have certain contexts or rules of availability, e.g., one account may only be allowed to be accessed for a specific service or a specific day or week; another account may be available only on weekdays from 8 am to 5 pm; yet another account may be available all day. The account selection component thus may put the accounts in prioritized order, and then the charging system performs a rating. Thus, the account selection component and the service class rating component must be synchronized. The service class rating component will try to reserve money from the account in the order specified in the account selection. It may not be possible to withdraw/reserve all the requested money from a first selected account, in which case the charging system continues in accordance with the prioritized listing of available accounts until the needed or requested amount is reserved. If the needed or requested amount cannot be fulfilled, then the call will not be granted, i.e., there will be a service denial.
Thus, in a conventional charging system such as that illustrated in
In a conventional charging system such as that illustrated in
Thus, as mentioned above, one of the problems with the conventional charging system such as that described in
Another problem is that the architecture of the conventional charging system requires the account selection of possible accounts to be done prior to the product selection. The constraining architecture of the conventional charging system presents at least the following difficulties:
Moreover, in the conventional charging system it is also not possible to address all accounts of a specific type without indicating each individual account.
Yet another problem with the architecture of the conventional charging system is that all dedicated accounts are aggregated together with a main account and seen as a pot of money during rating & charging. This hinders and complicates follow up on different account types.
In one of its aspects the technology disclosed herein concerns a method of operating a charging system. The method comprises acts of defining a pool of plural asset accounts and classifying the asset accounts of the account pool according to one or more account type classifications; and storing at least one appropriate account type classification for a product. The method further comprises, upon receiving an indication of a service request involving the product, obtaining at least one appropriate account type classification for the product; and selecting from the pool of plural asset accounts one or more of the asset accounts belonging to the at least one appropriate account type classification to charge (e.g., reserve/deduct) for the service request involving the product.
In an example embodiment and mode the method further comprises storing product charging/offering information for the product; and using the product charging/offering information to determine an amount to charge for the service request.
In an example embodiment and mode the method further comprises selecting, from the pool of plural asset accounts, a selected asset account to charge for the service request involving the product, the selected asset account belonging to the at least one appropriate account type classification and being sponsored by another product. In an example implementation the method further comprises using a product specification of the another product stored in the charging system to identify sponsorship of the selected asset account.
In an example embodiment and mode the method further comprises determining whether to create in the pool of plural asset accounts a product asset account for the product, the product asset account being classified according to the at least one appropriate account type classification for the product. In an example embodiment and mode the method further comprises upon creating the product asset account for the product, identifying the product asset account as a sponsored product asset account, only the product which sponsors the sponsored product asset account being eligible to fund the sponsored product asset account.
In an example embodiment and mode the method further comprises for the product, storing in the charging system a product specification which defines the at least one appropriate account type classification for the product; and using the product specification for determining whether to create the product asset account for the product.
In an example embodiment and mode the method further comprises classifying the asset accounts of the pool of plural asset accounts according to one or more pre-defined account type classifications, the at least one appropriate account type classification being one of the pre-defined account type classifications.
In an example embodiment and mode the method further comprises for the product, storing in the charging system a product specification which defines the at least one appropriate account type classification for the product; and, upon receiving the indication of the service request involving the product, obtaining from the product specification the at least one appropriate account type classification for the product and using the at least one appropriate account type classification to select the one or more of the asset accounts belonging to the at least one appropriate account type classification to charge for the service request involving the product.
In an example embodiment and mode the method further comprises associating, with each account type classification, plural account type parameters, the account type parameters comprising at least one of an account type unit of measure and an account type selection rule. In an example embodiment and mode the method further comprises using the account type selection rule to sequence charging for the service request from one or more asset accounts that belong to the at least one appropriate account type classification.
In an example embodiment and mode the method further comprises associating, with each account type classification, plural account type parameters, the account type parameters comprising an account type unit of measure.
In an example embodiment and mode the method further comprises maintaining a pool of plural products and, for each product in the pool, storing an indication of at least one of the appropriate account type classifications; and dynamically changing the constituent members of at least one of the pool of plural products and the pool of plural asset accounts during run time of the charging system.
In another of its aspects the technology disclosed herein concerns a method of operating a dynamically changeable charging system. The method comprises using a logic processing circuit to define a pool of plural asset accounts and classifying the asset accounts of the account pool according to one or more account type classifications; maintain a pool of plural products and, for each product in the pool, store an indication of at least one appropriate account type classification; handle service requests for the products in the pool of plural products by using the indication of the least one appropriate account type classification associated with the respective telecommunication products to select from the pool of plural asset accounts one or more of the asset accounts to charge [reserve/deduct] for the respective service requests; and dynamically change contents of one or both of the pool of plural asset accounts and the pool of plural products during run time of the logic processing circuit.
In another of its aspects the technology disclosed herein concerns a charging system. The charging system comprises a logic processing circuit; an asset account database; and, a product specification database. The logic processing circuit is configured to: define in the asset account database a pool of plural asset accounts and to classify the asset accounts of the account pool according to one or more account type classifications; store in the product specification database at least one appropriate account type classification for a product; upon receiving an indication of a service request involving the product, to obtain from the product specification database the at least one appropriate account type classification for the product; and select from the pool of plural asset accounts one or more of the asset accounts belonging to the at least one appropriate account type classification to charge [reserve/deduct] for the service request involving the product.
In an example embodiment the logic processing circuit is further configured to store, for the product, product charging/offering information (44); and use the product offering information (44) to determine an amount to charge for the service request.
In an example embodiment the logic processing circuit is further configured to select, from the pool of plural asset accounts, a selected asset account to charge for the service request involving the product, the selected asset account belonging to the at least one appropriate account type classification and being sponsored by another product.
In an example embodiment the logic processing circuit is further configured to use a product specification of the another product stored in the charging system to identify sponsorship of the selected asset account.
In an example embodiment the logic processing circuit is further configured to determine whether to create in the pool of plural asset accounts a product asset account for the product, the product asset account being classified according to the at least one account type classification for the product.
In an example embodiment the logic processing circuit is further configured, upon creating the product asset account for the product, to identify the product asset account as a sponsored product asset account, only the product which sponsors the product asset account being eligible to fund the sponsored product asset account.
In an example embodiment the logic processing circuit is further configured to, for the product, store in the charging system a product specification which defines the at least one appropriate account type classification for the product; use the product specification for determining whether to create the product asset account for the product.
In an example embodiment the logic processing circuit is further configured to classify the asset accounts of the pool of plural asset accounts according to one or more pre-defined account type classifications, the at least one appropriate account type classification being one of the pre-defined account type classifications.
In an example embodiment the logic processing circuit is further configured to, for the product, store in the charging system a product specification which defines the at least one appropriate account type classification for the product; and upon receiving from the telecommunications network the indication of the service request involving the product, obtain from the product specification the at least one appropriate account type classification for the product and using the at least one appropriate account type classification to select the one or more of the asset accounts belonging to the at least one appropriate account type classification to charge for the service request involving the product.
In an example embodiment the logic processing circuit is further configured to associate, with each account type classification, plural account type parameters, the account type parameters comprising at least one of an account type unit of measure and an account type selection rule.
In an example embodiment the logic processing circuit is further configured to use the account type selection rule to sequence charging for the service request from one or more asset accounts that belong to the appropriate account type classification.
In an example embodiment the logic processing circuit is further configured to associate, with each account type classification, plural account type parameters, the account type parameters comprising an account type unit of measure.
In an example embodiment the logic processing circuit is further configured to maintain a pool of plural products and, for each product in the pool, to store an indication of one of the account type classifications; dynamically change the constituent members of at least one of the pool of plural products and the pool of plural asset accounts during run time of the charging system.
The foregoing and other objects, features, and advantages of the technology disclosed herein will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the technology disclosed herein.
In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the technology disclosed herein. However, it will be apparent to those skilled in the art that the technology disclosed herein may be practiced in other embodiments that depart from these specific details. That is, those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the technology disclosed herein and are included within its spirit and scope. In some instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the technology disclosed herein with unnecessary detail. All statements herein reciting principles, aspects, and embodiments of the technology disclosed herein, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.
Thus, for example, it will be appreciated by those skilled in the art that block diagrams herein can represent conceptual views of illustrative circuitry or other functional units embodying the principles of the technology. Similarly, it will be appreciated that any flow charts, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
The functions of the various elements including functional blocks, including but not limited to those labeled or described as “computer”, “processor” or “controller”, may be provided through the use of hardware such as circuit hardware and/or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and/or computer-implemented, and thus machine-implemented.
In terms of hardware implementation, the functional blocks may include or encompass, without limitation, digital signal processor (DSP) hardware, reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) [ASIC], and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer and processor and controller may be employed interchangeably herein. When provided by a computer or processor or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, use of the term “processor” or “controller” shall also be construed to refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
In contrast to an account centric charging system, in a product-centric system accounts may be shared between products. Moreover, products may be shared between subscribers, but each product is still kept self contained and independent of other products. A product-centric system with account type addressing may also add, change, and remove accounts without changing the consuming products.
As used herein, a “product” is not limited to a device or apparatus, but may comprise any service or commodity, whether offered for use or sold. Nor is the term “product” as used herein limited to any particular industry, commerce, or service. For example, the product may be a telecommunications product, a telemarketing product, an internet or web-based product, a financial or banking product, to name a few.
As used herein, a “telecommunications product” is not limited to a telecommunications device, but may comprise any commodity provided (e.g., offered or sold) by a telecommunications provider or network operator. For example, a telecommunications product may comprise a service plan or subscription such as a telecommunications voice service plan, or a telecommunications data service plan, or a plan which includes a combination of voice and data and/or other services. Moreover, a telecommunications product may also include one or more commodities that are described in other offerings of a telecommunications provider or network operator, such as purchasable deals for one or more services or features. Such deals may be characterized by time duration, time of the week or day, geographic location, nature of content (e.g., video), etc.
Typically the product consumer (e.g., a purchaser or recipient of the product 21) accesses the product 21 through a product utilization device. Accordingly,
In an example embodiment and as depicted by way of example in
As shown in
The product offering database 44 of
For each product offering in product offering database 44 there is a corresponding product specification (P SPEC) in product specification database 46, e.g., product specifications SP-21 through SP-21-p for each of products 21 through 21-p, respectively. As shown by an arrow in
In an example embodiment, the product specification included in product specification database 46 may specify necessary technical details needed for a product. Among other things, the product specification includes an account specification and a charging specification. The account specification specifies a specific account of a specific account type and/or a reference to an existing account type. The charging specification uses the information from the account specification and indicates if charges will be withdrawn from the specified account or from the specified account type.
When a customer purchases or otherwise acquires a product defined by a product offering, an “instance” of the purchased product is created in product pool 54 for the customer. For example, if customer 30 purchases the product 21 defined by the product offering PO-21 in product offering database 44, a product instance PI-21-30 is created in product pool 54. As shown by an arrow, the product instance PI-21-30 refers or points to or incorporates the product offering PO-21 in product offering database 44. As mentioned above, a product offering PO-21 in product offering database 44 in turns refers or points to or incorporates the product specification PS-21 in product specification database 46 (as shown by another arrow). The same customer 30 may also have purchased product 21-1, and thus would have product instance PI-21-1-30 in product pool 54. Although not shown in
Thus, when a product is purchased or acquired through acceptance or purchase of a product offering, the charging system 20 creates an instance of the product in product pool 54. The instance of the product refers to the corresponding record in product offering database 44, which in turn refers to the corresponding specification for that product in product specification database 46.
The product-centric charging system 20 utilizes an “account type” classification as a way to represent a number of accounts which can be charged upon product usage. An account is an instantiated asset that belongs to a certain account type. An account can be seen as an asset container holding e.g. monetary units, counter, pieces, etc.
In the above regard
As explained with reference to act 3-1 of
Each “account type” or “account type classification” may have a name and one or more parameters for the account type. Table 1 provides selected examples of account types (e.g., account type classifications), with account type names being depicted in the second column of Table 1 and various parameters or descriptive fields shown in other columns of Table 1. In some of the example account types of Table 1, the account type defines, among other things, a unit of measure, currency and account selection rule.
Table 2 shows an example of how an account of a certain AccountType may be defined in/during a product Offering definition.
As one aspect of the technology disclosed herein, a product may be categorized as either an “account-sponsoring”/“account-owning” product on the one hand, or an “account-using” product on the other hand. Such categorization of the product as either “account-sponsoring” or “account-using” may occur as an indication stored, e.g., in the respective product offering (e.g., in the respective record for the product in product offering database 44).
Selected characteristics of an “account-using” product are illustrated in
Selected characteristics of an “account-sponsoring” product, also known as an “account-owning” product, are illustrated in
As evident from the above, the term “balance” is sometimes used herein synonymously with the term “account” but may, depending on the context, refer also to the value of an account.
Thus, when a product has its own account assets such owned account is referred to that as a sponsored account, e.g., the account that the product “owns”. In some situations a subscription may involve plural different products, and not every product may have its own assets (e.g., not every product may be an account-owning or accounts-sponsoring product), and therefore is an “account-using” product. An account-owning product can also use assets that are owned by another product. The product specification specifies whether a product will be an “account-owning” product or an “account-using”. The “account specification” portion of the product specification indicates what type of account is required.
Then, rather than proceeding to account selection as would a conventional charging system, the product-centric charging manager 22 has service handling unit 40 make a product request (act 6-3) of the product handling manager 42. The purpose of the product request of act 6-3 is to identify which products of product pool 54 may be appropriate for the service request issued as act 6-1. The service request of act 6-1 may have been issued for a voice service, so in response to the product request of act 6-3, as act 6-4 the product handling manager 42 checks the product pool 54 for the customer for whom the service request was issued and makes a product identification. The product identification of act 6-4 may indicate that the customer has two voice products, e.g., a first product being an ordinary voice product and a second voice product being a discounted voice product. So as a result of the product request of act 6-3, as act 6-4 the eligible products suitable for the particular service request are identified.
Having identified the eligible products available to the customer for the particular service for which the service request was received, the pricing plan for each of the eligible products must be fetched. Act 6-5 comprises the product handling manager 42 requesting, from product offering database 44, a price plan for each of the eligible products identified by act 6-4. As act 6-6 the product offering database 44 returns a price plan for each eligible product. Based on the price plans return as act 6-6, the product handling manager 42 determines which of the eligible products has the most favorable price plan, and for the most favorably priced product makes a cost calculation as act 6-7. In the example scenario being discussed, the discounted voice product would be the most favorable, and accordingly as act 6-7 the cost calculation for the service request of act 6-1 is made with respect to the discounted voice product.
Having determined what product is to be allocated to the service request, and the cost of the product in fulfillment of the service request, the product-centric charging manager 22 seeks to determine which asset account of pool 24 of plural asset accounts is to be charged, debited, or have assets reserved for the service request. Accordingly, as act 6-8 the product handling manager 42 sends a request to product specification database 46 in order to determine which account, or which account type, is to be charged for the service request. In this regard, the customer's instance of the selected product is linked through the product offering database 44 to the product specification database 46, as shown by arrows in
Having received from 46 either the account or the appropriate account type classification for the product, as act 6-10 the product handling manager 42 attempts to determine the appropriate asset accounts in pool 24 of plural asset accounts that may be charged, debited, or reserved for the service request of act 6-1. If all that is returned from the product specification database 46 as act 6-9 is an identification of a particular account, or a particular code that indicates that only one particular account may be charged, then such particular account will be charged for the service request. But if the product specification database 46 returns a account type classification as act 6-9, the determination of act 6-10 is based on the account type classification for the product and possibly other information as well, such as an account selection rule which may comprise the account type definition. If an account type classification is returned from product specification database 46, act 6-10 comprises consulting the accounts for the corresponding account type 64 and, as illustrated by act 6-11, issues a quote request to one or more asset accounts of the account type classification 64 which is associated with the customer.
The number and order (e.g., sequence) of such quote requests may be determined by the account selection rule associated with the account type. As each asset account is checked, as act 6-12 the asset account tentatively or preliminarily reserves or deducts from its balance as much as the asset account can contribute toward payment of the cost calculated at act 6-7. The amount so reserved or deducted toward payment of the cost calculated at act 6-7 is returned in a quote result of act 6-13 to product handling manager 42. If the asset account which is consulted first in the sequence is able to cover the entire calculated cost, then no other asset account need be consulted. But if the amount reserved or deducted toward payment of the cost is insufficient to cover the entire cost calculated at act 6-7, the product handling manager 42 may send quote requests (act 6-11) to other asset accounts in, e.g., an order provided by any account selection rule defined for the account type.
After quote results (act 6-13) are obtained from one or more asset accounts, as act 6-14 the product handling manager 42 actually charges the appropriate asset accounts. In such case the tentative or preliminary reservations or deductions of act 6-12 may be finalized.
The three voice plan products having instances for product consumer 30 in product pool 54 are main voice plan 21-70; a one weekend voice discount plan 21-71; and, a family and friends voice plan 21-72. Each of these voice plans is shown in product specification database 46 to have an account type of “VOICE”. Of these three voice plans, the product specification database 46 indicates that the first two are “account-sponsoring” or “account-owning” products (e.g., OAV), with main voice plan 21-70 owning an account OAV1 in account type classification 64V (which has account type classification “VOICE”) and one weekend voice discount plan 21-71 owning an account OAV2 in account type classification 64V. The family and friends voice plan 21-72 is shown in product specification database 46 to be an “account-using” product.
In the context of the example of
The five data plan products having instances for product consumer 30 in product pool 54 are original home data plan 21-74; supplement/replacement data plan 21-75; late night data discount plan 21-76; employer data plan 21-77; and, video download special plan 21-78. Each of these data plans is shown in product specification database 46 to have an account type of “DATA”. Of these, original home data plan 21-74 may be the plan historically used by and still available to product consumer 30, but scheduled for soon phase out in favor of the supplement/replacement data plan 21-75. As further products the product consumer 30 has purchased the late night data discount plan 21-76 (which provides more favorable data rates at non-peak, late night hours) and the video download special plan 21-78. In addition to these four personal or household plans, the product consumer 30 also has access to the employer data plan 21-77, ostensibly for professional purposes. Of these five data plans, the product specification database 46 indicates that the first two and fourth are “account-sponsoring” or “account-owning” products (e.g., OAD), with original home data plan 21-74 owning an account OAD1 in account type classification 64D (which has account type classification “DATA”); supplement/replacement data plan 21-75 owning an account OAD2 in account type classification 64D; and employer data plan 21-77 owning an account OAD3 in account type classification 64D. The late night data discount plan 21-76 and the video download special plan 21-78 are shown in product specification database 46 to be “account-using” products.
As shown in
In the context of the example of
It should be understood that the instances of products in product pool 54 available to product consumer 30 at any given time may change in accordance with product purchase and expiration timing. Moreover, the asset accounts which may be chargeable or otherwise usable by the product consumer 30 may also change over time, particularly as “account-sponsoring” or “account-owning” products are added or removed from the pool 24 of plural asset accounts.
The technology disclosed herein facilitates access to many different products that are potentially using many different types of accounts. In an example embodiment of the technology disclosed herein a determination is made in runtime as to which account is to be used. The determination of asset account to use is not made by hard pre-defined rule or hard relation. The technology disclosed herein uses an “account type classification” to handle subscriptions with new products so that the products and subscriptions can find each other during execution. In the past, the conventional charging system had to select the account purposely, identifying the types of services and then selecting the account. But the product-centric charging manager 22 of the technology disclosed herein instead looks at the products available, and then based on the products determines what accounts may be charged.
In the account centric world or the subscription centric world essentially everything was modeled around one base subscription. But with the technology disclosed herein the modeling better reflects what is actually sold to subscribers, e.g., the product itself. As mentioned above, a “product” is more than a piece of equipment, such as a smart phone. In the telecommunications environment, for example, a product may be voice calls for a certain price per minute, one price for daytime in another price for evenings. Another telecommunications product could be 500 short message service calls per month, but after that there is a certain price for each. Thus, a “product” may be a subscription package. Moreover, even if a consumer has already a subscription package, such package may currently be without capabilities for electronic data (e.g., for Internet surfing), but by using another product the original product may be upgraded (e.g., temporarily, e.g., for a weekend) to have electronic data service. In such case, the operator may offer a product which is a “free surf” weekend for a nominal amount. Thus, a “product” is a packaging for any particular commodity, whether apparatus or service, is sold. The product could be like subscriptions that recur (with the monthly fee and prescribed volume), or the product could be just a one-time offer (for example, 50 min. of data traffic). Or the product could be ten ring tones or five downloads of movies or other types of content. Another product to be a downloadable movie within twenty four hours. Thus, with the technology disclosed herein the seller or operator has the freedom to put configure a product in any way desirable. The charging system of the technology disclosed herein thus reflects the ways that the products are sold and consumed, and is therefore “product centric”.
The account centric approach asked the question “which account can I use?” The “product” centric, on the other hand, primarily asks “what products can be used?” Previously, with the conventional charging system, if a consumer purchased a subscription, the consumer might be able to select between perhaps five different subscription packages. But now with advantages of the technology disclosed herein and its product-centric charging system the customer may obtain a card that gives the customer access to a bundle of different products, and there may be selection between the different products and in different combinations.
The charging system 20 of the technology disclosed herein also has an ability to produce reports on how the product was consumed, e.g., what is left on the product. The charging system of the technology disclosed herein is indeed “product centric” since a focus is on the communication package as sold and how it is used. With the technology disclosed herein a big subscription now comprises many small subscriptions and more freedom for the customer to put together his/her own list of products.
It was also mentioned above that the charging system and particularly including product-centric charging manager 22 may be realized by a machine platform 50. A computer implementation of the machine platform may be realized by or implemented as one or more computer processors or controllers as those terms are herein expansively defined, and which may execute instructions stored on non-transient computer-readable storage media. In such a computer implementation the machine platform 50 may comprise, in addition to a processor(s), a memory section (which in turn can comprise random access memory; read only memory; an application memory (a non-transitory computer readable medium which stores, e.g., coded non instructions which can be executed by the processor to perform acts described herein); and any other memory such as cache memory, for example). Another example platform suitable for charging system 20(4) is that of a hardware circuit, e.g., an application specific integrated circuit (ASIC) wherein circuit elements are structured and operated to perform the various acts described herein.
The product-centric charging system of the technology disclosed herein provides numerous advantages and benefits, including but not limited to the following:
It was mentioned above that the access network 36 can be any suitable type of access network, and that a radio access network is just one example. In a typical cellular radio system, wireless terminals (also known as mobile stations and/or user equipment units (UEs)) communicate via a radio access network to one or more core networks. The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station, e.g., a radio base station (RBS), which in some networks may also be called, for example, a “NodeB” (UMTS) or “eNodeB” (LTE). In some versions of the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a controller node (such as a radio network controller (RNC) or a base station controller (BSC)) which supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
Although the description above contains many specificities, these should not be construed as limiting the scope of the technology disclosed herein but as merely providing illustrations of some of the presently preferred embodiments of the technology disclosed herein. Thus the scope of the technology disclosed herein should be determined by the appended claims and their legal equivalents. Therefore, it will be appreciated that the scope of the technology disclosed herein fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the technology disclosed herein is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more.” All structural, chemical, and functional equivalents to the elements of the above-described preferred embodiment that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the technology disclosed herein, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed under the provisions of 35 U.S.C. 112, sixth paragraph, unless the element is expressly recited using the phrase “means for.”
