Embodiments of the invention are hereinafter described in detail in conjunction with the drawings.
According to an embodiment of the invention, a Charging Trigger Function (CTF) collects related information of third party charging. According to another embodiment of the invention, the related information of third party charging may be initiated by a service requesting party, be configured in the CTF itself or be obtained through interaction with the external system, e.g., a call centre or an operating support system. The related information of third party charging includes a paying party identifier, and may further includes a verifying code corresponding to the paying party identifier, etc. After the service requesting party accesses the service and the CTF determines that the accessed service will be debited from the third party account, the CTF sends, to the charging system, the third party charging information determined based on the related information of third party charging. The charging system reserves or debits the expense of the use of the service according to the third party charging information. The paying party identifier is configured to identify a paying party account.
The paying party may preset paying party information including its own account verifying code and a payment limit in the charging system. Specifically, the paying party may preset the paying party information in the call centre or the operating support system; and then the call centre or the operating support system sends the paying party information to the charging system directly or through the CTF.
According to an embodiment of the invention, a client may trigger third party charging. In other words, when the client accesses the service, the client may send to the CTF a service request message including related information of third party charging. The related information of third party charging may include a third party charging sepcial access identifier and a paying party identifier, or further include a verifying code corresponding to the paying party identifier and so on. In addition, the client may support an interface for the user to input the paying party identifier and the verifying code if there is an interface input manner for delivering the data service. The paying party identifier mentioned here may be the SIP URI of the paying party, the Mobile Station ISDN number(MSISDN) of the paying party, the account of the paying party, or the like.
The CTF mentioned above is configured to collect, send and integrate the related information of third party charging from the service requesting party or the call centre, and send to the charging system the third party charging information complying with the standardized profile for the interface between the CTF and the charging system to enable the reservation or debiting of the charging system. The third party charging information may include the paying party identifier, the user account identifier, or the paying party verifying code, etc.
The charging system correlates the third party charging information of the CTF with the paying party account, and carries out the reservation or debiting from the third party account. Or the charging system correlates the third party charging information including the verifying code of the paying party account with the paying party information to validate the third party charging information, and carries out the reservation or debiting from the third party account according to a validation result.
In one approach, as shown in {circle around (1)} {circle around (2)} {circle around (3)} in
In another approach, as shown in (1) (2) (3) (4) in
Alternatively, the third party charging condition may be set in the CTF by the service requesting party through the media system, such as the call centre or the operating support system. Thus the service requesting party may choose the paying party account freely.
A method for third party charging is illustrated in detail in an embodiment of the present invention.
According to this embodiment, the paying party presets a verifying code for its own account in the charging system through a call centre or an operating support system, or further presets a payment limit. Embodiments are illustrated in detail with respect to the process of online charging and the process of offline charging respectively.
Block 301: when accessing a service, a user sends, through an access client (e.g., a phone), a service request message including related information of third party charging such as a third party charging access identifier, a paying party identifier, a verifying code, and so on to a CTF in order to trigger the third party charging service.
The paying party identifier may be a client identifier of the paying party, for example, Mobile Station ISDN number(MSISDN), Session Initiation Protocol Uniform Resources Identifier (SIP URI), or the like. For instance, in a calling service, the user dials additionally the third party charging access identifier, the paying party identifier, and the verifying code. For example, the number dialed by the user is ‘179998613800000000*12345#07552000000’, ‘17999’ is the third party charging access identifier; ‘8613800000000’ is the paying party identifier, which is the user identifier corresponding to the paying party account in this example; ‘12345’ is the verifying code; ‘*’ is a separator for separating the paying party identifier and the verifying code; and ‘#’ is a separator for separating the verifying code and the called number.
In some data services, if there is an interface input manner, the user can input the paying party identifier, the verifying code and otherwith by setting the display interface.
Block 302: in response to receiving the service request message sent by the user through the access client, the CTF detects that the requested service will be charged to the third party account according to the third party charging access identifier in the related information of third party charging, and obtains the paying party identifier and the verifying code from the related information of third party charging.
Block 303: the CTF sends third party charging information including the paying party identifier, the verifying code and the third party charging identifier indicating that the requested service will be charged to the third party account to an Online Charging System (OCS) where the paying party account is located through a Credit Control Request (CCR).
Block 304: in response to receiving the CCR, the OCS verifies the CCR, and further verifies the paying party identifier and the verifying code in the CCR according to the verifying code set for the paying party account in the OCS. The OCS further determines whether a reservation amount exceeds the payment limit preset by the paying party in the paying party account. When the CCR passes the verification and the reservation amount does not exceed the payment limit, Block 305 is performed.
In the Block 304 above, if the CCR does not pass the verification, the OCS may return a verification failure message to the CTF. And the CTF forwards the verification failure message to the client, and the process is terminated. Similarly, if the reservation amount exceeds the payment limit, the OCS may return a payment limit shortage message to the CTF, the CTF forwards the payment limit shortage message to the client, and the process is terminated.
Block 305: the OCS carries out the reservation from the paying party account, and returns a reservation answer notification to the CTF via a Credit Control Answer (CCA).
Block 306: the CTF provides the service to the client.
Block 307: after the reservation amount is used up, the CTF interacts with the OCS for the reservation, i.e., Block 303 to Block 306 are performed.
In this embodiment, Block 303 to Block 306 are performed once the reservation amount is used up.
Block 308: the OCS debits the total expense of the use of the service from the paying party account after the service is terminated.
A process of offline charging in another embodiment is shown in
Block 401: a user Client sends a service request message including related information of third party charging such as a third party charging access identifier, a paying party identifier, a verifying code, etc., to a CTF in order to trigger a third party charging service.
Block 402: in response to receiving the service request message sent by the Client, the CTF detects that the requested service will be charged to the third party account according to the third party charging access identifier in the related information of third party charging, and then obtains the paying party identifier and the verifying code from the related information of third party charging.
Block 403: the CTF sends a third party charging information including the paying party identifier, the verifying code and the third party charging identifier to a Calling Data Function (CDF) and a Charging Data Record (CDR) Gateway Function (CDF/CGF) via an Accounting Request (ACR). The third party charging identifier indicates that the requested service will be charged to the third party account.
Block 404: the CDF/CGF returns an answer notification to the CTF via an Accounting Answer (ACA).
Block 405: the CTF provides the service to the client for the user.
Block 406: the CDF/CGF generates a CDR including the third party charging information including the paying party identifier, the verifying code, etc.
Block 407: the CDF/CGF delivers the CDR to an offline charging system.
Block 408: the offline charging system verifies the paying party identifier and the verifying code in the third party charging information, and debits the total expense of the use of the service from the account corresponding to the paying party identifier according to the CDR.
If the paying party identifier and the verifying code are verified as failure, the charging system returns a verification failure message to the CDF/CGF. After the service is terminated, the CDF/CGF may interact with the charging system where the account of the user is located to debit the expense of the service from the account of the user. The CDF/CGF may also notify the CTF that the paying party identifier and the verifying code are verified as failure, the CTF then interacts with the charging system where the account of the user is located to debit the expense of the service from the account of the user.
Additionally, a payment limit may be preset for the paying party account in the offline charging system according to this embodiment. If the expense of the use of the service exceeds the payment limit, the offline charging system returns a charging reject message to the CDF/CGF or to the CTF via the CDF/CGF. The CDF/CGF or the CTF debits the expense of the use of the service from the account of the user.
In another embodiment of the invention, when a service requesting party accesses the service, the information sent to the CTF does not include the related information of third party charging such as the third party charging access identifier, the paying party identifier, the verifying code, etc. Instead, the paying party presets third party charging condition in the CTF. For example, the paying party presets the information on whether the service requesting party will be charged by the third party and corresponding paying party identifier, or further presets the valid period of the third party charging and/or service type for the third party charging, and the corresponding paying party identifier.
Embodiments are described in detail with reference to online charging and offline charging respectively.
The process of online charging in an embodiment is shown in
Block 501: when accessing a service, a user client sends a service request message including a sending party identifier to the CTF. The sending party identifier is the user identifier.
Block 502: in response to receiving the service request message, the CTF determines whether the use of the service will be charged to the third party account according to the user identifier and the third party charging condition preset in the CTF. In other words, the CTF determines whether the service is a third party charging service. If the service is a third party charging service, the CTF determines the paying party identifier, and Block 503 is performed. If the service is not a third party charging service, the CTF performs a regular process.
If the third party charging condition preset in the CTF is the information on whether the requested service will be charged to the third party account, the CTF determines whether to perform the third party charging according to the user identifier in the service request message, and determines the paying party identifier according to the third party charging condition.
If the third party charging condition preset in the CTF includes the valid period of third party charging and/or the service type, the CTF determines whether to perform the third party charging and determines the corresponding paying party identifier according to the sending party identifier and the current time. In another embodiment of the invention, the CTF determines whether to perform the third party charging and determines the corresponding paying party identifier according to the sending party identifier and the service type. Additionally, in order to determine whether to perform the third party charging and determine the paying party identifier according to the service type, the service request message should include the service type. And the CTF determines whether to perform the third party charging and determines the paying party identifier according to the service type included in the charging request message.
Block 503: the CTF sends the third party charging information including the paying party identifier and the third party charging identifier to the OCS where the paying party account is located via a CCR. The third party charging identifier indicates that the charging request is the third party charging.
Block 504: in response to receiving the CCR, the OCS verifies the CCR and determines whether the reservation amount exceeds the payment limit preset for the paying party account. When the CCR passes the verification and the reservation amount does not exceed the payment limit, Block 505 is performed.
In Block 504 above, if the reservation amount exceeds the payment limit, the OCS may return to the CTF a payment limit shortage message, and the CTF returns the payment limit shortage message to the client, and the process is terminated.
Block 505: the OCS carries out the reservation from the paying party account, and returns a reservation answer notification to the CTF through a CCA.
Block 506: the CTF provides the service for the client.
Block 507: after the reservation amount is used up, the CTF interacts with the OCS for the reservation, i.e., Block 503 to Block 506 are performed.
When the service is going on, Block 503 to Block 506 are performed once the reservation amount is used up.
Block 508: the OCS debits the total expense of the service from the paying party account after the service is terminated.
The process of offline charging in accordance with another embodiment of the invention is shown in
According to an embodiment of the invention, the verifying code corresponding to the paying party identifier is set in the charging system, and the paying party identifier and the verifying code are set in the service request message by the service requesting party. As a result, when the CTF interacts with the charging system, the expense of the service will not be debited from the paying party account until the account information and the verifying code pass the verification, thus the security of the paying party account is ensured.
According to an embodiment of the invention, a corresponding relationship of the paying party account to the period for the third party charging and/or the service type is set in the CTF, and the paying party account is determined according to the period and/or the service type. More flexible third party charging is realized as the expense can be debited from different paying party accounts in different periods or according to different service types.
To sum up, the forgoing are only embodiments of the invention but not for use in limiting the protection scope of the invention. Those skilled in the art may make changes and variations on the basis of the invention without departing from the spirit and scope thereof.
| Number | Date | Country | Kind |
|---|---|---|---|
| 200610090411.X | Jun 2006 | CN | national |