Patent Application
20100008484
This invention pertains to communications, and particularly to methods and apparatus for accounting and/or charging for services rendered by communications companies and utilized by communication customers.
Communications companies (e.g., telecommunications operators) issue financial charges to customers in return for services rendered. The revenue realized by communications companies upon customer payment (whether in advance or after service) defrays, among other things, the initial capital outlay and maintenance of the network infrastructure, as well as day-to-day operating costs.
Some customers may pay a flat fee for communications services. Most customers have an account which is established by a contract or fee arrangement/agreement. Typically a customer's account is structured or arranged, at least in part, so that the customer is assessed a communications fee which is dependent upon an amount of time or other network resource which is utilized by the customer (e.g., degree or quality of service, calendar or clock time of service, for example). The fee or charge typically either reduces a prepaid amount existing in the customer's account, or accumulates against the credit of the customer and is presented for subsequent payment.
For charging purposes the communications network provides some type of monitoring of resource consumption by the customers. The monitoring can occur at faculties or nodes involved in setup or administration of the services (e.g., of a call or connection). The resource monitoring and/or other types of reports from the communications network are communicated to a real-time charging system which associates the call or session with a customer's account as maintained by the charging system, and may send reports (e.g., Call Detail Record (CDR) files) to an off-line billing system which is maintained by the communications operator. The billing system likewise has an off-line account which is associated with the customer, and which includes other (e.g., historical information).
A billing system connected directly to the communications equipment without a real-time charging system lacks the possibility of providing real-time credit control (to protect the operator) and real-time spending control (to protect the end-user). In such case the billing systems only acts upon historical records received from the communications equipment (e.g., telecom equipment). The billing system by itself might be able to handle complex relations between accounts and services, but unless connected to a real-time charging system would lack the benefit of handling the balance and usage in real-time.
Real-time accounts of a real-time charging system can hold different “buckets” or subaccounts, each with a reserved amount, that can only be used for a specific service, e.g. SMS, GPRS etc. In a real-time charging system there may also be accumulators for measuring and reporting spending per service connected to the account.
As mentioned above, the charging system maintains an account for a customer, at least during the life of the call, connection, or session involving the customer. (The terms call, connection, and session are utilized interchangeably herein). The account is connected to (e.g., associated with or identified by) a user identifier or user identity such as, e.g. MSISDN (Mobile Subscriber Integrated Services Digital Network Number) or SIP URI (Session Initiation Protocol Uniform Resource Identifier).
A communications account can, in turn, have subaccounts for a specific service, like download of music, for example, in order for a customer to partition or itemize transactions according to a certain criteria (such as type of service utilized, for example). Similarly, some customer accounts (such as corporate accounts) are structured so that charges are split or classified by departments. Some household customer accounts are partitioned for billing purposes to be able to associate charges with family members or individuals.
Unfortunately, existing real-time charging systems can only handle accounts which involve certain limited relationships between a user identity (the identity such as MSISDN) used for a particular service and the real-time account holder (customer). The traditional limited relationships are either (1) a fixed one-to-one relation, or (2) a many-to-one relation. The relationships (e.g., “relations”) are configured once and thereafter are considered valid for all charging scenarios where the user uses the same identity. The traditional charging system thus focuses on the particular identity the user is using as the criteria for selecting an account or account structure. This means that when a user (e.g., a human individual) employs a different identity for a communications service than another identity associated with the individual, the individual is deemed to be a completely different user.
In one of its aspects the present technology concerns a method of operating a communications system to charge a call to one or more customer accounts. The term “call” is used throughout the description may be used interchangeably for event, session, services, etc. Basically, the method comprises receiving a user identifier from a communications network in conjunction with a communications call or session (the user identifier being associated with a first account), using a filter for the first account to make a determination whether the call should (alternatively or partially) be associated with a second account; and charging the call to at least one of the customer accounts in accordance with the determination. Preferably the first filter associated with the first account makes the determination based, at least in part, on a characteristic of the call. In differing embodiments, the characteristic of the call can be (by way of non-limiting example) at least one of type of service utilized by the call; time of the call; location of a party to the call; particular user identity employed at authentication of the call.
An example mode of the method includes initially associating the call to a first account in accordance with the user identifier employed by a party participating in the call. The example mode further comprises using the first filter for the first account to determine, based on the characteristic, whether the call should alternatively or partially be associated with the second account. If the first filter indicates that the call should be associated with the second account, the example mode uses a second filter of the second account to make a confirmation whether the second account can be associated to the first account. If the confirmation can be made, the call is charged (at least partially) to the second account. If the confirmation cannot be made, the call is charged to the first account.
Another aspect of the present technology concerns a charging system for a communications system. The charging system comprises an information storage database (comprising plural customer accounts); account selection logic; and an account charging unit. The account selection logic comprises account-based filters which are configured to make a determination whether the call, having a user identifier which is associated with a first account, should be alternatively or partially associated with a second account. The account charging unit is configured to develop financially related information for the call. In an example embodiment a first filter for a first account makes the determination based on a characteristic of the call. In potentially differing embodiments, the characteristic of the call can be at least one of type of service utilized by the call; time of the call; location of a party to the call; particular user identity employed at authentication of the call.
In an example embodiment, the account selection logic comprises a set of filters comprising a first filter for the first account which is configured initially to associate the call to a first account in accordance with the user identifier and to determine, based on the characteristic, whether the call should alternatively or partially be associated with the second account. The account selection logic is further configured, if the first filter indicates that the call should be associated with the second account, to comprise a second filter of the second account which is configured to make a confirmation whether the second account can be associated to the first account. If the confirmation can be made, the account selection logic is configured to direct the charging unit to charge the call to the second account. If the confirmation cannot be made, the account selection logic is further configured to direct the charging unit to charge the call to the second account.
The foregoing and other objects, features, and advantages of the invention 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 invention.
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 present invention. However, it will be apparent to those skilled in the art that the present invention 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 invention 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 present invention with unnecessary detail. All statements herein reciting principles, aspects, and embodiments of the invention, 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 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 labeled or described as “processors” or “controllers” may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared or distributed. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may include, without limitation, digital signal processor (DSP) hardware, read only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage.
As used herein and illustrated by
The real-time charging system 22 and off-line billing system 24 can, at least in some embodiments, comprise or be included in nodes or elements of communications network 20. However, as shown in
A generic, representative, real-time charging system 22 as shown in
As generally illustrated in
The rating function 34 is configured to calculate the charge rate for the selected call or service, such that an account can be accurately adjusted to reflect the cost of the call/service.
For sake of simplified illustration,
At the time shown in
Suppose in the scenario shown in
Suppose further, for the scenario of
In conventional practice, no matter what service the user 10 uses, when user 10 employs the work contact identifier CIDE as the contact identifier to access a service, the charging for the service will still be made to the employer's account 401 and therefore paid by the company/employer. In conventional practice the charging may be settled later between the company and employee in another transaction not handled by the billing system, but from an operator perspective the user 10 and the company represents the same party.
The present technology surpasses conventional practice by providing method and apparatus for performing such activities as, e.g., alternatively or at least partially charging the home account of user 10 for a service access for personal use by user 10 when using the employer/work contact identity CIDE (i.e., using the work MSISDN). Basic, representative acts or steps of the method are illustrated in
Act 6-1 of
As used herein, a call “characteristic” is any information related to a call that facilitates a determination regarding which of plural possible accounts should be charged for the call. In differing or combinations of embodiments, the characteristic of the call can be (by way of non-limiting examples) at least one of type of service utilized by the call; time of the call; location of a party to the call; particular party identifier (PID) employed at authentication of the call
Act 6-2 of the method of
For example, in the scenario discussed above wherein user 10 uses his work contact identity CIDE to download music, account selection logic 32 can initially determine that account 401 is associated with the particular (work) contact identity [CIDE] utilized by user 10. But also realizing that the particular service (music download) is not a service that should be charged to account 401, the account selection logic 32 can instead charge the cost of the music download service to the home account of user 10, e.g., account 402. Accordingly,
Thus, the present technology has the perspective that “user” is just a role that a specific party can take or play. It might as well take the role of a customer (i.e. the account holder). What role a party takes may depend on a number of things, like what service is used, identity used at authentication, or time of day. These roles can be reflected by the “characteristic” of the call, as discussed above.
The present technology and account selection logic 32 in particular encompasses a general procedure or method which includes the acts illustrated in
Act 7-1 of the generalized procedure of account selection logic 32 comprises checking, upon occurrence of a real-time request, to which party a specific user identity utilized in/associated with the call is connected. For example, when the work contact identity CIDE of user 10 is utilized, account selection logic 32 associates the work contact identity CIDE with user 10. This assumes that user 10 is disconnected from the user identities that are used for authorization and connection.
Act 7-2 comprises optionally checking the role the party normally has when using the user identity associated with the call, e.g., used to place the call (e.g., checking whether user 10 normally fulfills the role of employee when using his/her work contact identity CIDE).
Act 7-3 comprises checking a characteristic of the call, e.g., checking the type of service the party is trying to access, location, time of day etc.
Act 7-4 comprises determining whether the role the user 10 normally has is valid, or if user 10 should be considered as playing or fulfilling another role in light of the information obtained in the previous act (e.g., depending on the characteristic of the call). For example, act 7-4 involves determining whether, in view of the characteristic of the call placed by user 10, the user 10461 can correctly be considered to play its default role of employee or worker.
If the normal role of the party is not valid, act 7-5 comprises determining the customer (account holder) corresponding to the role the party has actually played, e.g., a role other than the default role for the utilized identifier.
The account selection logic 32 is shown as including a set of filters 50, with one or more accounts 40 of real-time account database 30 having one or more filters 50. In other words, associated or linked to at least some of the accounts 40 are one or more filters 50. The filters 50, also known as “characteristic” filters, provide criteria and/or code which can serve as input to account selection logic 32. For example, filter 501-1 (also known as service filter X) and filter 501-2 (also known as service filter Y) comprise or are associated with account 401; filter 502-1 (also known as service filter R) comprise or is associated with account 402; and filter 50n-1 (also known as service filter S) is associated with account 40n. In addition, in the example embodiment of
The filters 50 can, at least in one example embodiment, comprise code, scripts, or other information executable or usable by controller 52 for selecting an appropriate account to which a call, connection, or session is to be charged. Such information can, as in the illustrated example embodiment, be stored in real-time account database 30 in association with the particular account 40 to which the filter pertains. While
Act 9-2 comprises account selection logic 32 locating (in real-time account database 30) the appropriate real-time account by using the user identity received from telecom/end-user equipment. In other words, act 9-2 comprises initially associating the call to a first account in accordance with the user identifier which is input by or associated with a party participating in the call. In this illustrated scenario, since user 10 is using his work contact identity CIDE, as act 9-2 the account selection logic 32 selects account 401 as part of act 9-2.
Act 9-3 of the mode of
Had the filters associated with account 401 not established a relation with another account, the call would remained charged to the initially charged account, i.e., account 401.
Act 9-5 through act 9-7 can be performed as optional steps of the mode of
If the confirmation of act 9-5 cannot be made, the call is charged elsewhere, e.g., to the first account (e.g., account 401), as represented by act 9-7 of
Thus, in the example scenario of
Although not shown in
The account selection logic 32 of
Similarly, operator interface 74 serves as an interface or port through which filter configuration logic 70 of controller 52(10) receives filter specifications from an operator device 46E. The filter specification(s) obtained from the operator device 46E can ultimately be obtained from owner device 46D, as represented by arrow 76 in
Establishing, modifying, or deleting filter settings for a filter associated with the owner's account can be handled, either through communications network 20 and owner/telcom interface 72, or through the operator and operator interface 74, much in the same manner as changing settings on a cell phone account or on-line web-based account, e.g., through an appropriate menu drive selection process. Act 6-1 of
Thus, in view of the foregoing, it can be seen that the characteristic which is analyzed by account selection logic 32 can be selectively (re)configurable through actions implemented, e.g., by filter configuration logic 70.
The role determination functional unit 52a receives various service parameters (such as party identity [PID] and a contact identity [CID]) and, as a function of at least the PID and possibly other parameters, determines the role played by the party (e.g., by user 10). If necessary, role determination functional unit 52a can fetch other service parameters as inputs for its operation.
Account determination functional unit 52b receives various service parameters (e.g., PID, CID, and the “role” determined by role determination functional unit 52a) and determines a candidate account to be charged for the call placed by user 10. If necessary, account determination functional unit 52b can fetch other service parameters as inputs for its operation.
The controller 52(12) also comprises filter(s) 50(12). Although the account determination functional unit 52b may have selected a candidate account for charging, the filter(s) 50(12) can override the determination of account determination functional unit 52b and instead redirect the charge to another account. For example, the controller 52(12) may be programmed or configured to redirect a charge from one account to another account until some condition is fulfilled or satisfied, e.g., until some termination condition or the like is reached. If necessary, filter(s) 50(12) can fetch other service parameters as inputs for operation.
Thus, in the present technology, the role that a party plays when using a specific service can be used to determine which account is to be charged for the call or connection, not necessarily an account linked to the identity the party happens to be using. The technology thereby provides many advantages. One advantage is that an operator need only have one entry for each party. This in turn provides other benefits: (1) a party can get one bill/invoice/statement no matter what user identity the party may have used; (2) the operator can give promotions based on such criteria as the services the party is using, the time of day, the location, etc., and not the user identity; and (3) the party can use any user identity and be charged correctly.
Moreover, the technology affords an opportunity to define complex business rules without impact in the communications environment e.g. selection of sponsored calls/services for family or corporations. Sponsoring of a call does not necessarily need to be covered by the users own account e.g. children must always be able to call their family members and one of the parents accounts will carry the cost. The service filters could for instance act upon a dialed prefix and thereby let the end-users interact when selecting an account to carry the cost. Time-of-day, day-of-week and dates could be important input for the service filters. Charging scenario (service)-aware account differentiation, e.g., voice calls within a company, can be also carried by one account.
In accordance with the present technology, a customer (owner of an account) can also have the possibility to configure the service filters, and thereby decide for what other end-users and which charging scenarios he/she is going to carry the cost. Moreover, since it is known to connect accumulators to an account to, e.g., measure usage (e.g., of different services), the owner of an account can (using the accumulators) set spending limits on how much he/she is willing to sponsor or allow another end-user to consume or utilize a certain service.
Another advantage of the present technology is reduced signaling and CPU load in the communications network due, e.g., to the fact that the communications equipment does not need to be in control of the account relations and the fact that the charging system does not need to be interrogated separately for each involved account. Handling this relation internally in the charging system, compared to handling the relation by the communications equipment and the triggering of several session towards the charging system, reduces signaling and CPU load in the communications equipment.
The present technology thus may permit the redirecting of costs from one account to another (alternative) account. The present technology also permits the sharing of cost between plural customer accounts. For example, in some scenarios a call may be partially charged to a first account and partially charged to a second account.
Although the description above contains many specificities, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the presently preferred embodiments of this invention. Thus the scope of this invention should be determined by the appended claims and their legal equivalents. Therefore, it will be appreciated that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the present invention 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 present invention, 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.”
