WO2017000644A1

WO2017000644A1 - Method and device for account resource sharing

Info

Publication number: WO2017000644A1
Application number: PCT/CN2016/080251
Authority: WO
Inventors: 仝瑞国
Original assignee: 华为技术有限公司
Priority date: 2015-06-30
Filing date: 2016-04-26
Publication date: 2017-01-05
Also published as: CN106332040A; CN106332040B

Abstract

Disclosed in the present invention are a method and device for account resource sharing, the method comprising: receiving a service request initiated by a user terminal with a first account, wherein the service request carries an identifier of the first account; searching, from a pre-stored payment relationship, an identifier of a second account having a payment relationship with the first account according to the identifier of the first account; initiating to a charging system to which the second account belongs a charging request for the service request, wherein the charging request carries the identifier of the second account used for charging; and after receiving a charging success response from the charging system, allowing the terminal to use the service.

Description

Method and device for sharing account resources

This application claims priority to Chinese Patent Application No. 201510376580.9, entitled "A Method and Apparatus for Sharing Account Resources" on June 30, 2015, the entire contents of which are incorporated herein by reference. In the application.

Technical field

The present invention relates to the field of communications technologies, and in particular, to a method and apparatus for sharing account resources.

Background technique

In today's increasingly developed communications, the demand for package resource sharing is also increasing. Currently, the sharing of package resources in the billing system is implemented by means of a primary and secondary card. Since the relationship between the primary and secondary cards needs to be maintained in the same charging system, this method cannot share the sharing of resources between accounts of the accounting system.

Summary of the invention

Embodiments of the present invention provide a method and apparatus for sharing account resources to implement account resource sharing across a billing system.

In a first aspect, an embodiment of the present invention provides a method for sharing account resources, where the method includes:

Receiving, by the GGSN, a service request initiated by the user equipment by using the first account, where the service request carries an identifier of the first account;

Determining, by the GGSN, an identifier of a second account having a payment relationship with the first account from a pre-stored payment relationship according to the identifier of the first account;

The GGSN initiates a charging request for the service request to the charging system to which the second account belongs, where the charging request carries an identifier of the second account used for charging;

After receiving the charging success response from the charging system, the GGSN allows the terminal to use the service.

In a first possible implementation manner of the first aspect, before the GGSN receives the service request initiated by the first account, the method further includes:

Receiving, by the GGSN, a payment relationship between the first account and the second account, where the payment relationship is Including an identifier of the first account and an identifier of the second account;

The GGSN stores the payment relationship.

In conjunction with the first aspect or the first possible implementation of the first aspect, in a second possible implementation of the first aspect, the payment relationship further includes the first account and the second account Effective time of the payment relationship;

The GGSN searches for the identifier of the second account that has a payment relationship with the first account from the pre-stored payment relationship according to the identifier of the first account, and specifically includes:

The GGSN searches for an identifier of the second account having a valid pay-as-you-go relationship with the first account from the pre-stored payment relationship according to the identifier of the first account.

In conjunction with the second possible implementation of the first aspect, in a third possible implementation of the first aspect, the method further includes:

After the GGSN fails to perform the payment relationship between the first account and the second account, the GGSN deletes the payment relationship.

With reference to the first aspect or the first to second possible implementation manners of the first aspect, in a fourth possible implementation manner of the first aspect, the method further includes: receiving, by the GGSN, canceling the first account And a request for a payment relationship with the second account, and deleting a payment relationship between the first account and the second account according to the request.

With reference to the first aspect or the first to fourth possible implementation manners of the first aspect, in the fifth possible implementation manner of the first aspect, the charging request further carries an identifier of the first account; The identifier of the first account is used as a payment relationship authentication and/or used as a charging reference.

With reference to the first aspect or the first to fifth possible implementation manners of the first aspect, in a sixth possible implementation manner of the first aspect, the method further includes: extending an attribute value in the charging request For the AVP parameter, the identifier of the second account is carried by the extended AVP parameter.

In a second aspect, an embodiment of the present invention provides a method for sharing account resources, where the method includes:

The charging system receives a charging request for a service request initiated by the first account; the charging request carries an identifier of a second account for charging, and the second account has a payment relationship with the first account ;

The charging system uses the second account to charge the service request initiated by the first account.

In a first possible implementation manner of the second aspect, the method further includes:

The charging system receives a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account and an identifier of the second account;

The billing system stores the pay-as-you-go relationship.

In conjunction with the first possible implementation of the second aspect, in a second possible implementation manner of the second aspect, the charging request further carries an identifier of the first account.

In conjunction with the second possible implementation of the second aspect, in a third possible implementation manner of the second aspect, the charging system uses the second account to calculate a service request initiated by the first account. Before the fee, the method further includes:

The charging system authenticates the charging request according to the stored payment relationship, and determines that the identifier of the first account and the identifier of the second account carried in the charging request satisfy the payment relationship.

With reference to the second to third possible implementation manners of the second aspect, in a fourth possible implementation manner of the second aspect, the charging system adopts the service initiated by the second account to the first account The request for billing specifically includes:

The charging system determines a charging rate for the service request initiated by the first account according to the identifier of the first account, and determines a charging rate to perform charging in the second account.

With reference to the second aspect or the first to fourth possible implementation manners of the second aspect, in the fifth possible implementation manner of the second aspect, the charging request includes an extended attribute value pair AVP parameter, where The identifier of the second account is carried in the extended AVP parameter.

With reference to the second aspect or the first to fifth possible implementation manners of the second aspect, in a sixth possible implementation manner of the second aspect, the method further includes:

The billing system generates a bill including the first account identifier and the second account identifier.

In a third aspect, an embodiment of the present invention provides an apparatus for sharing account resources, where the apparatus includes:

a receiving module, configured to receive a service request initiated by the user equipment by using the first account, where the service request carries an identifier of the first account;

a service module, configured to search, according to the identifier of the first account, an identifier of a second account that has a payment relationship with the first account from a pre-stored payment relationship;

a control module, configured to initiate, by the charging system to which the second account belongs, a charging request for the service request, where the charging request carries an identifier of a second account used for charging; After the charging of the charging system is successfully responded, the terminal is allowed to use the service.

In a first possible implementation manner of the third aspect, the receiving module is further configured to receive a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account And Describe the identity of the second account;

The device also includes:

And a storage module, configured to store the payment relationship received by the receiving module.

With reference to the third aspect, or the first possible implementation manner of the third aspect, in the second possible implementation manner of the third aspect, the first account and the second account are further included in the payment relationship Effective time of the payment relationship;

The service module is specifically configured to search, according to the identifier of the first account, an identifier of a second account that has a valid pay-off relationship with the first account from a pre-stored payment relationship.

In conjunction with the second possible implementation of the third aspect, in a third possible implementation manner of the third aspect, the service module is further configured to perform a payment relationship between the first account and the second account. After the failure, the payment relationship is deleted.

With the third aspect or the first to second possible implementation manners of the third aspect, in a fourth possible implementation manner of the third aspect, the receiving module is further configured to receive and cancel the first account and the a request for a payment relationship of the second account;

The service module is further configured to delete the payment relationship of the first account and the second account according to the request received by the receiving module to cancel the payment relationship of the first account and the second account.

With the third aspect or the first to fourth possible implementation manners of the third aspect, in a fifth possible implementation manner of the third aspect, the charging request further carries an identifier of the first account; The identifier of the first account is used as a payment relationship authentication and/or used as a charging reference.

With reference to the third aspect or the first to fifth possible implementation manners of the third aspect, in a sixth possible implementation manner of the third aspect, the control module is further configured to extend an attribute in the charging request The value pair AVP parameter carries the identifier of the second account with the extended AVP parameter.

In a fourth aspect, an embodiment of the present invention provides an apparatus for sharing account resources, where the apparatus includes: a receiving module, configured to receive a charging request for a service request initiated by a first account; and the charging request is carried in the charging request An identifier of the second account that is billed, and the second account has a payment relationship with the first account;

The charging module is configured to perform charging for the service request initiated by the first account by using the second account.

In a first possible implementation manner of the fourth aspect, the receiving module is further configured to receive a payment relationship between the first account and the second account, where the payment relationship includes the first account Identification And an identification of the second account;

The device also includes:

a storage module, configured to store the payment relationship.

In conjunction with the first possible implementation of the fourth aspect, in a second possible implementation manner of the fourth aspect, the charging request further carries an identifier of the first account.

In conjunction with the second possible implementation of the fourth aspect, in a third possible implementation manner of the fourth aspect, the charging module is specifically configured to determine, according to the identifier of the first account, the first account The billing rate of the initiated service request, and the determined billing rate is charged in the second account.

With reference to the second to third possible implementation manners of the fourth aspect, in a fourth possible implementation manner of the fourth aspect, the charging module is further configured to perform the charging according to the stored payment relationship The requesting is performed to determine that the identifier of the first account and the identifier of the second account carried in the charging request satisfy the payment relationship.

With reference to the fourth aspect, or the first to fourth possible implementation manners of the second aspect, in the fifth possible implementation manner of the fourth aspect, the charging request includes an extended attribute value pair AVP parameter, where The identity of the second account is carried in the extended AVP parameters.

With reference to the fourth aspect or the first to fifth possible implementation manners of the second aspect, in a sixth possible implementation manner of the fourth aspect, the charging module is further configured to generate the first account identifier And the CDR of the second account identifier.

In the above embodiment, the GGSN saves the payment relationship, and the GGSN sends the service request of the first account to the charging system of the second account, so that the charging system charges the service in the second account. Sharing between accounts across systems.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention. Those skilled in the art can also obtain other drawings based on these drawings without paying any creative work.

1 is a network architecture diagram for implementing account resource sharing according to an embodiment of the present invention;

2 is a schematic flowchart of a registration payment relationship according to an embodiment of the present invention;

3 is a schematic flowchart of canceling a payment relationship according to an embodiment of the present invention;

4 is a flowchart of a method for sharing account resources according to an embodiment of the present invention;

FIG. 5 is a flowchart of a method for sharing account resources according to another embodiment of the present invention; FIG.

FIG. 6 is a flowchart of a method for sharing account resources according to another embodiment of the present invention; FIG.

FIG. 7 is a schematic structural diagram of an apparatus for implementing account resource sharing according to an embodiment of the present invention;

FIG. 8 is a schematic structural diagram of an apparatus for implementing account resource sharing according to another embodiment of the present invention; FIG.

9 is a schematic structural diagram of a GGSN according to an embodiment of the present invention;

FIG. 10 is a schematic structural diagram of a charging system according to an embodiment of the present invention.

detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

FIG. 1 is a network architecture diagram of implementing account resource sharing according to an embodiment of the present invention. As shown in FIG. 1 , the network architecture includes: customer relationship management (CRM) equipment, provisioning equipment (Provis ioning), and gateway general packet radio service (GPRS) support node (gateway GPRS support node). , GGSN) and billing system.

The CRM device is configured to register the payment relationship of the account, and send the registered payment relationship to the GGSN and the charging system respectively through the activation device.

The provisioning device can be used to forward and forward messages. In the embodiment of the present invention, the provisioning device is used for message forwarding between the CRM device and the GGSN, and between the CRM device and the charging system. Specifically, the provisioning device may forward the payment relationship registered in the CRM device to the GGSN and the charging system, respectively, and forward the response message returned by the GGSN and the charging system to the CRM device.

The GGSN is configured to receive a service request initiated by the user equipment by using the first account, and initiate a charging request to the charging system for the received service request, and control the usage of the service by the user equipment according to the charging response returned by the charging system. In the embodiment of the present invention, the GGSN stores a payment relationship from the CRM device. After receiving the service request, the GGSN determines, according to the payment relationship, whether there is a second account with a payment relationship with the first account. If yes, the GGSN sends a charging request to the charging system to which the second account belongs, and The charging request carries the identifier of the second account, and the charging system is instructed to use the second account for charging. If not, the GGSN sends the charging request to the charging system to which the first account belongs, and carries the identifier of the first account in the charging request, instructing the charging system to use the first account for charging.

The billing system is configured to perform billing according to the received billing request. The billing system includes a system with a charging function such as an online charging control (OCS) or a convergent billing system (CBS).

The Diameter protocol can be used for communication between the GGSN and the billing system.

Based on the above network architecture, the flow of the registration payment relationship and the process of canceling the payment relationship will be described in detail below through FIG. 2 and FIG. 3, respectively.

2 is a schematic flowchart of a registration and payment relationship according to an embodiment of the present invention. As shown in FIG. 2, the registration process includes:

S200. The CRM device receives an identifier of an account to be registered for a payment relationship. Wherein, the account to be registered for the payment relationship includes a payment account and a consumption account sharing the package resource of the payment account.

Specifically, the user can register a payment account with a payment relationship of one or more other consumer accounts in the CRM through the self-service channel or the business hall, so that the package resource of the payment account can be shared with the consumer account having the payment relationship with the payment account. . The account resource may specifically be a package resource that can be used by the account, for example, a data package.

S202. The CRM locally establishes a payment relationship between the accounts to be registered.

The payment relationship includes an identification of the payment account and an identification of the consumer account corresponding to the identification of the payment account. Optionally, the payment relationship may further include a valid time, where the valid time may be represented by two fields: an effective time and an expiration time. As shown in Table 1, Table 1 is an illustration of the pay relationship.

Table 1

The identifier of the payment account and the consumption account may be an international mobile subscriber identity (IMSI), an international mobile device identity. (international mobile equipment identity, IMEI), one or more of mobile station international ISDN numbers (MSISDN).

S204. The CRM device sends the payment relationship to the provisioning device.

Specifically, the CRM may initiate a synchronization message to synchronize the payment relationship to the provisioning device. This synchronization operation can be implemented by using an existing synchronization interface between the CRM and the provisioning device.

S206. The provisioning device sends the payment relationship to the GGSN.

The provisioning device can add a Simple Object Access Protocol (SOAP) interface, through which the payment relationship is synchronized to the GGSN.

S208. The GGSN stores the payment relationship.

Specifically, the GGSN may save the payment relationship in the form of a table, as shown in Table 1.

S210. The GGSN returns a response message indicating that the payment relationship is successfully received to the enabled device.

S212. The activation device sends the payment relationship to the charging system.

The provisioning device can add a SOAP interface, and the payment relationship is synchronized to the charging system through the SOAP interface.

S214. The charging system stores the payment relationship.

Specifically, the charging system may save the payment relationship in the form of a table, as shown in Table 1.

S216. The charging system returns a response message indicating that the payment relationship is successfully received to the provisioning device.

S218. The provisioning device returns a successful response to the CRM device.

It should be noted that the steps S208-S210 and the steps S212-S218 are not limited to the sequence, and the steps S212-S218 may be performed before the steps S208-S210 may be performed, or may be performed concurrently.

FIG. 3 is a schematic flowchart of canceling a payment relationship according to an embodiment of the present invention. As shown in FIG. 3, the cancellation process includes:

S300. The CRM device receives a request to cancel a payment relationship, where the request carries an identifier of an account that needs to cancel the payment relationship. The identifier of the account that needs to be cancelled includes the identifier of the payment account and the identifier of the consumer account.

Specifically, the user can cancel the payment relationship in the CRM through the self-service channel or the business hall.

S302. The CRM device sends a request to cancel the payment relationship to the provisioning device.

The CRM device can send a request to cancel the payment relationship to the provisioning device in a synchronized manner. The synchronous interface of the CRM device and the provisioning device can also use the existing interface.

S304. The provisioning device sends a request to cancel the payment relationship to the GGSN.

The provisioning device can also synchronize the request to cancel the payment relationship to the GGSN through the new SOAP interface.

S306. The GGSN deletes the payment relationship corresponding to the identifier of the account carried in the cancellation request.

The GGSN finds the identifier of the payment account and the identifier of the consumer account in the stored payment relationship, if the payment account has a purchasing relationship with the consumer account.

S308. The GGSN returns a cancellation success response to the provisioning device.

S310. The provisioning device sends a request for canceling the payment relationship to the charging system.

The provisioning device can also synchronize the request to cancel the payment relationship to the billing system through the new SOAP interface.

S312. The charging system deletes the payment relationship corresponding to the identifier of the account carried in the cancellation request.

The billing system finds the identifier of the payment account and the identifier of the consumer account in the stored payment relationship, if the payment account has a purchasing relationship with the consumer account.

S314. The charging system returns a cancellation success response to the provisioning device.

S316. The provisioning device returns a cancellation success response to the CRM device.

It should be noted that the steps S304-S308 and the steps S310-S314 are not performed in the sequence, and the steps S310-S314 may be performed before the steps S304-S308 may be performed, or may be performed concurrently.

The flow of account resource sharing will be described in detail below through FIG. 4 and FIG. 5 respectively.

FIG. 4 is a flowchart of a method for sharing account resources according to an embodiment of the present invention. This method is applied to the GGSN. As shown in FIG. 4, the method includes:

S400. The GGSN receives a service request initiated by the user equipment by using the first account, where the service request carries the identifier of the first account.

The service request may be a request for using a data service, for example, an online request of a user equipment.

It should be noted that, in all embodiments of the present invention, the first account represents a consumer account.

S402. The GGSN searches for an identifier of the second account that has a paying relationship with the first account from the pre-stored payment relationship according to the identifier of the first account.

The GGSN may acquire the payment relationship of the first account and the second account in advance, and maintain the payment relationship. The payment relationship includes an identifier of the first account and an identifier of the second account. The process of obtaining the payment relationship between the first account and the second account by the GGSN refers to the method shown in FIG. Law, no more details here.

It should be noted that, in all embodiments of the present invention, the second account represents a payment account.

S404. The GGSN initiates a charging request for the service request to the charging system to which the second account belongs, where the charging request carries an identifier of the second account used for charging.

The communication between the GGSN and the billing system can be based on the Diameter protocol. Specifically, the GGSN may send a charging request to the charging system by using a Credit Control Request (CCR) message.

The GGSN may also send the charging request by using a standard structure CCR message. The GGSN fills in the originator field of the service request (eg, the field Subscription-Id-Data) into the identifier of the second account in the CCR message of the standard structure.

It should be noted that the CCR message of the standard structure is used to carry the identifier of the second account, and the charging system is completely shielded from the charging process, so that the process is completely controlled by the network device GGSN, which is inconvenient for the charging system to calculate. Fee control.

Therefore, the embodiment of the present invention may further carry the identifier of the first account in the charging request. The identity of the first account can be used as a payment relationship authentication and/or as a billing reference. In this case, the GGSN may extend an attribute-value pair (AVP) parameter in the CCR message, and carry the identifier of the second account with the extended AVP parameter. The identity of the first account is carried in the originator field of the service request (eg, field Subscription-Id-Data).

Optionally, the AVP parameter extended by the GGSN in the charging request may be an AVP group, and the identifier of the first account may also be carried in the extended AVP group, so that the charging system can directly learn the current AVP parameter. The fee request is that the second account is paid for the first account, and no other fields are parsed to improve the processing efficiency of the billing system. Among them, the extended AVP group is as follows:

CCR message extension AVP group Subscriber-ID Group:

|-----Payment-SubscriberID

|-----Origin-SubscriberID

The Payment-SubscriberID is an identifier of the second account (ie, the identifier of the payment account), and may be an account that can be used in a charging system such as an IMSI, an IMEI, an MSISDN, or a card number of the payment card.

The Origin-SubscriberID is the identifier of the first account (ie, the identifier of the consumer account), and may be one or more of IMSI, IMEI or MSISDN.

S406. After receiving the charging success response from the charging system, the GGSN allows the terminal. Use the business.

It should be noted that the first account and the second account may be located in different charging systems. In step S404, the GGSN sends the charging request to the charging system to which the second account belongs. The above embodiment is directed to the processing of the case where there is a payment relationship in which the second account is paid for the first account. For the case where the payment relationship does not exist, the GGSN sends a charging request to the charging system to which the first account initiating the charging request belongs.

Further, the GGSN stored in the payment relationship may further include a valid time of the payment relationship between the first account and the second account, as shown in Table 1. Therefore, in step S402, the GGSN may, according to the identifier of the first account, search for the identifier of the second account that has a paying relationship with the first account from the pre-stored payment relationship, and the GGSN may include: The identification of the first account finds an identification of the second account having a valid payment relationship with the first account from a pre-stored payment relationship. An effective pay relationship is a pay relationship that is within the effective time frame.

After the payment relationship between the first account and the second account is invalidated, the GGSN may further delete the payment relationship between the first account and the second account.

In addition, the GGSN may further delete the payment relationship of the first account and the second account according to the received request to cancel the payment relationship of the first account and the second account. For details, refer to the process of canceling the payment relationship in the embodiment shown in FIG. 3.

FIG. 5 is a flowchart of a method for sharing account resources according to another embodiment of the present invention. The method is applied to a billing system. As shown in FIG. 5, the method includes:

S500. The charging system receives a charging request for a service request initiated by the first account. The charging request carries an identifier of a second account for charging, where the second account has a generation with the first account. Pay relationship.

The first account and the second account may belong to different charging systems. The charging system in step S500 is a charging system to which the second account belongs.

S502. The charging system uses the second account to perform charging for the service request initiated by the first account.

The control function for the payment relationship can be implemented in the billing system. Specifically, the billing system can be advanced Obtaining a payment relationship between the first account and the second account, and maintaining the payment relationship. The payment relationship includes an identifier of the first account and an identifier of the second account. The process of obtaining the payment relationship between the first account and the second account by the charging system refers to the method shown in FIG. 2, and details are not described herein again.

The identifier of the first account may be further carried in the charging request received by the charging system. For the carrying manner of the identifier of the first account and the identifier of the second account in this embodiment, reference may be made to the embodiment shown in FIG. 4, and details are not described herein again.

The charging system may perform the payment relationship authentication according to the identifier of the first account and the identifier of the second account carried in the charging request, and/or serve as a charging reference.

Specifically, the charging system performs the payment relationship authentication according to the identifier of the first account and the identifier of the second account carried in the charging request, and may be performed before step S502. That is, before the step S502, the charging system may perform the authentication on the charging request according to the stored payment relationship, and determine the identifier and the second identifier of the first account carried in the charging request. The identification of the account satisfies the payment relationship.

In addition, the billing system may set different preferential policies for each consumer account having a binding relationship with the payment account or the billing system may charge the payment account with the rates or offers of the respective consumer accounts themselves. Therefore, the charging request can carry the identity of the first account for use as a charging reference. The billing reference refers to determining rates, offers, and the like. For example, the charging system may determine a charging rate for the service request initiated by the first account according to the identifier of the first account, and determine a charging rate to perform charging in the second account.

After the billing system completes the billing, the bill including the first account identifier and the second account identifier may be further generated.

In the above embodiment, by controlling the payment relationship in the billing system, different charging policies can be adopted for different consumer accounts, so that each consumer account can use the payment resource of the payment account by using different rates or offers.

The scheme of the embodiment of the present invention is described in more detail below by taking the data package of the shared payment account in the data service as an example.

S600. The GGSN receives a service request request for using the data service initiated by the user equipment by using the first account.

The service request carries the identifier of the first account.

S602. The GGSN searches, according to the identifier of the first account, an identifier of the second account that has a pay relationship with the first account from a pre-stored payment relationship.

This embodiment is described by taking the payment relationship of the first account and the second account as an example. For the case where the payment relationship does not exist, the charging process in the prior art can be performed, and details are not described herein again.

S604. The GGSN initiates a charging request for the service request to a charging system to which the second account belongs.

The charging request is a CCR message, and the message type of the CCR message is Initial. The extended AVR group carries the identifier of the first account and the identifier of the second account in the CCR message.

S606. The charging system performs the payment relationship authentication according to the identifier of the first account carried in the charging request and the identifier of the second account.

The authentication process may include determining whether the identity of the first account and the identity of the second account have a pay relationship.

For a case where a payment account can be shared to multiple consumer accounts, the billing system can further authenticate whether to allow multiple consumer accounts to be used simultaneously.

S608: After the authentication is passed, the charging system uses the second account to perform charging processing such as rating and reservation.

The embodiment of the present invention is described by taking an authentication as an example. If the authentication fails, the authentication failure is returned and the process is terminated.

S610. The charging system returns a charging response indicating that the charging is successful to the GGSN.

The charging response may use a Credit Control Answer (CCA) message. The charging response carries the authorization amount.

S612. After receiving the charging success response, the GGSN allows the user equipment to use the data service.

S614. In the process of using the data service by the user equipment, the GGSN initiates a charging update request to the charging system according to the usage of the authorized amount.

The charging update request may also adopt a CCR message, and the message type of the CCR message is Update. The usage of the user is carried in the charging update request.

S616: After receiving the charging update request, the charging system performs charging processing such as deduction, approval, and reservation.

In this step, the charging system performs deduction according to the usage amount carried in the charging update request.

S618. The charging system returns a charging response to the GGSN.

The charging response carries a new authorization amount.

It should be noted that step S614 to step S618 may be repeatedly executed in the process of using the data service by the user equipment until the user stops using or the balance is insufficient.

S620. The GGSN receives a stop request for stopping the use of the data service from the user equipment.

S622. The GGSN sends a charging termination request to the charging system.

The charging termination request may also adopt a CCR message, and the message type of the CCR message is Terminate. The usage of the user is also carried in the billing termination request.

S624-S626, the charging system performs a chargeback and sends a charging termination response to the GGSN.

FIG. 7 is a schematic structural diagram of an apparatus 700 for sharing account resources according to an embodiment of the present invention. Wherein, the device may be a GGSN. The device 700 includes:

The receiving module 701 is configured to receive a service request initiated by the user equipment by using the first account, where the service request carries the identifier of the first account.

The service module 702 is configured to search, according to the identifier of the first account, an identifier of the second account that has a payment relationship with the first account from a pre-stored payment relationship.

The control module 703 is configured to initiate, by the charging system to which the second account belongs, a charging request for the service request, where the charging request carries an identifier of the second account used for charging; After the charging from the charging system is successfully responded, the terminal is allowed to use the service.

The function of receiving the service request by the receiving module 701 can be implemented by using the prior art, and details are not described herein again.

The control module 703 can send a charging request through the Diameter protocol. Specifically, the charging control request (CCR) message in the Diameter protocol may be used to send a charging request to the charging system. The charging request may further carry the identifier of the first account. The identifier of the first account is used as a payment relationship authentication and/or used as a charging reference.

For the identification of the identity of the first account and the identity of the second account in the charging request, reference may be made to the embodiment portion shown in FIG. For example, the control module 703 may carry the attribute value pair AVP parameter extended in the charging request, and carry the identifier of the second account in the extended AVP parameter.

The receiving module 701 is further configured to receive a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account and an identifier of the second account. The process of receiving the payment relationship by the receiving module 701 can refer to the embodiment shown in FIG. 2 .

The apparatus 700 may further include: a storage module 704, configured to store the payment relationship received by the receiving module 701.

In an embodiment, the payment relationship may further include a valid time of the payment relationship between the first account and the second account.

The service module 702 is specifically configured to search, according to the identifier of the first account, an identifier of a second account that has a valid pay-off relationship with the first account from a pre-stored payment relationship.

The service module 702 is further configured to delete the payment relationship after the payment relationship between the first account and the second account is invalid.

In another embodiment, the receiving module 701 is further configured to receive a request to cancel a payment relationship between the first account and the second account. The process of receiving the cancellation request by the receiving module 701 may refer to the embodiment shown in FIG. 3.

The service module 702 is further configured to delete the payment relationship of the first account and the second account according to the request received by the receiving module to cancel the payment relationship of the first account and the second account.

It should be noted that the deletion of the payment relationship according to the invalidation and the deletion of the payment relationship according to the cancellation request may exist simultaneously in the solution.

In the foregoing embodiment, the device 700 maintains a payment relationship, and the device 700 sends the service request of the first account to the charging system of the second account, so that the charging system charges the service in the second account. Sharing between accounts across systems.

For the implementation of each module in the device 700, reference may be made to the method embodiment shown in FIG. 4, and details are not described herein again.

FIG. 8 is a schematic structural diagram of an apparatus 800 for sharing account resources according to an embodiment of the present invention. Wherein, the device can be a billing system. The device 800 includes:

The receiving module 801 is configured to receive a charging request for a service request initiated by the first account, where the charging request carries an identifier of a second account for charging, where the second account and the first account have Payment relationship.

The charging module 802 is configured to perform charging for the service request initiated by the first account by using the second account.

The receiving module 801 can receive the charging request based on the Diameter protocol. Specifically, the received charging request may be a Credit Control Request (CCR) message in the Diameter protocol. The charging request may further carry the identifier of the first account.

For the identification of the identity of the first account and the identity of the second account in the charging request, reference may be made to the embodiment portion shown in FIG. For example, the scalable attribute value in the charging request is for the AVP parameter, and the identifier of the second account is carried in the extended AVP parameter.

The receiving module 801 is further configured to receive a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account and an identifier of the second account. Receive mode The process by which block 801 receives the pay-as-you-go relationship can be referred to the embodiment shown in FIG. 2.

The apparatus 800 further includes: a storage module 803, configured to store the payment relationship received by the receiving module 801.

The charging module 802 may perform the payment relationship authentication according to the identifier of the first account and the identifier of the second account carried in the charging request, and/or serve as a charging reference. Specifically, the charging module 802 is configured to determine, according to the identifier of the first account, a charging rate for the service request initiated by the first account, to determine that the charging rate is performed in the second account. Billing.

The charging module 802 is further configured to perform the authentication on the charging request according to the stored payment relationship, and determine that the identifier of the first account and the identifier of the second account carried in the charging request are satisfied. The payment relationship.

The billing module 802 is further configured to generate a bill including the first account identifier and the second account identifier after the billing is completed.

FIG. 9 is a hardware structural diagram of a GGSN according to an embodiment of the present invention. As shown in FIG. 9, the GGSN includes a memory 91, a communication interface 92, a processor 93, and a bus 94.

The processor 93, the memory 91 and the communication interface 92 are communicatively connected via a bus 94.

Communication interface 92 is used to enable communication between the GGSN and other devices or communication networks such as, but not limited to, PLMN/PSTN, the Internet, and the like. In the embodiment of the present invention, the payment relationship and the service request may be received through the communication interface 92.

The memory 91 may be a storage medium such as a hard disk. The memory 91 can be instructions of the program as well as application data. In the embodiment of the present invention, the memory 91 stores a payment relationship.

The processor 93 can be a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits for running related programs.

Bus 94 may include a path for communicating information between various components, such as processor 93, memory 91, and communication interface 92.

In the embodiment of the present invention, the processor 93 is configured to run the program instruction in the memory 91, and is configured to: receive a service request initiated by the user equipment by using the first account, where the service request carries the identifier of the first account. And searching, according to the identifier of the first account, an identifier of a second account having a payment relationship with the first account from a pre-stored payment relationship; and initiating, for the charging system to which the second account belongs a charging request for a service request, the charging request carrying a second account for charging The identity of the user; after receiving the charging success response from the charging system, allowing the terminal to use the service.

The specific processing procedure of the processor 93 can be referred to the method embodiment part shown in FIG. 4 and FIG. 6, and details are not described herein again.

FIG. 10 is a hardware structural diagram of a charging system according to an embodiment of the present invention. As shown in FIG. 10, the billing system includes a memory 101, a communication interface 102, a processor 103, and a bus 104.

The processor 103, the memory 101 and the communication interface 102 are communicatively connected via a bus 104.

Communication interface 102 is used to enable communication between the billing system and other devices or communication networks such as, but not limited to, PLMN/PSTN, the Internet, and the like. In the embodiment of the present invention, the payment relationship and the charging request may be received through the communication interface 102.

The memory 101 may be a storage medium such as a hard disk. The memory 101 can be instructions of the program as well as application data. In the embodiment of the present invention, the memory 101 stores a payment relationship.

The processor 103 can be a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits for running related programs.

Bus 104 may include a path for communicating information between various components, such as processor 103, memory 101, and communication interface 102.

In the embodiment of the present invention, the processor 103 is configured to run the program instruction in the memory 101, and is configured to: receive a charging request for a service request initiated by the first account; and the charging request carries the charging The identifier of the second account, the second account has a payment relationship with the first account; and the second account is used to charge the service request initiated by the first account.

The specific processing procedure of the processor 103 may refer to the method embodiment part shown in FIG. 5 and FIG. 6, and details are not described herein again.

Through the description of the above embodiments, those skilled in the art can understand that all or part of the steps in implementing the above embodiments can be completed by a program to instruct related hardware, and the program can be stored in a computer readable manner. In the storage medium, when the program is executed, the steps include the steps of the foregoing method embodiment, such as a ROM/RAM, a magnetic disk, an optical disk, and the like.

The above is only a specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope of the present invention. It should be covered by the scope of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

A method for sharing account resources, characterized in that the method comprises:

Receiving, by the GGSN, a service request initiated by the user equipment by using the first account, where the service request carries an identifier of the first account;

Determining, by the GGSN, an identifier of a second account having a payment relationship with the first account from a pre-stored payment relationship according to the identifier of the first account;

The GGSN initiates a charging request for the service request to the charging system to which the second account belongs, where the charging request carries an identifier of the second account used for charging;

After receiving the charging success response from the charging system, the GGSN allows the terminal to use the service.
The method of claim 1, wherein before the GGSN receives the service request initiated by the first account, the method further comprises:

Receiving, by the GGSN, a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account and an identifier of the second account;

The GGSN stores the payment relationship.
The method according to claim 1 or 2, wherein the payment relationship further includes an effective time of a payment relationship between the first account and the second account;

The GGSN searches for the identifier of the second account that has a payment relationship with the first account from the pre-stored payment relationship according to the identifier of the first account, and specifically includes:

The GGSN searches for an identifier of the second account having a valid pay-as-you-go relationship with the first account from the pre-stored payment relationship according to the identifier of the first account.
The method of claim 3, wherein the method further comprises:

After the GGSN fails to perform the payment relationship between the first account and the second account, the GGSN deletes the payment relationship.
The method according to any one of claims 1 to 3, wherein the method further comprises: the GGSN receiving a request to cancel a payment relationship between the first account and the second account, according to the Requesting to delete the payment relationship of the first account and the second account.
The method according to any one of claims 1 to 5, wherein the charging request further carries an identifier of the first account; wherein the identifier of the first account is used for payment relationship authentication And / or used as a billing reference.
The method of any of claims 1-6, wherein the method further comprises:

The attribute value pair AVP parameter is extended in the charging request, and the identifier of the second account is carried by the extended AVP parameter.
A method for sharing account resources, characterized in that the method comprises:

The charging system receives a charging request for a service request initiated by the first account; the charging request carries an identifier of a second account for charging, and the second account has a payment relationship with the first account ;

The charging system uses the second account to charge the service request initiated by the first account.
The method of claim 8 wherein the method further comprises:

The charging system receives a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account and an identifier of the second account;

The billing system stores the pay-as-you-go relationship.
The method of claim 9, wherein the charging request further carries an identifier of the first account.
The method of claim 10, wherein the charging system uses the second account to perform charging for the service request initiated by the first account, the method further comprising:

The charging system authenticates the charging request according to the stored payment relationship, and determines that the identifier of the first account and the identifier of the second account carried in the charging request satisfy the payment relationship.
A method according to claim 10 or 11, wherein said billing system employs The charging of the service request initiated by the second account by the second account specifically includes:

The charging system determines a charging rate for the service request initiated by the first account according to the identifier of the first account, and determines a charging rate to perform charging in the second account.
The method according to any one of claims 8 to 12, wherein the charging request includes an extended attribute value pair AVP parameter, and the identifier of the second account is carried in the extended AVP parameter.
The method of any of claims 10-13, wherein the method further comprises:

The billing system generates a bill including the first account identifier and the second account identifier.
An apparatus for sharing account resources, characterized in that the apparatus comprises:

a receiving module, configured to receive a service request initiated by the user equipment by using the first account, where the service request carries an identifier of the first account;

a service module, configured to search, according to the identifier of the first account, an identifier of a second account that has a payment relationship with the first account from a pre-stored payment relationship;

a control module, configured to initiate, by the charging system to which the second account belongs, a charging request for the service request, where the charging request carries an identifier of a second account used for charging; After the charging of the charging system is successfully responded, the terminal is allowed to use the service.
The device according to claim 15, wherein the receiving module is further configured to receive a payment relationship between the first account and the second account, where the payment relationship includes an identifier of the first account and The identifier of the second account;

The device also includes:

And a storage module, configured to store the payment relationship received by the receiving module.
The device according to claim 15 or 16, wherein the payment relationship further includes an effective time of a payment relationship between the first account and the second account;

The service module is specifically configured to search, according to the identifier of the first account, an identifier of a second account that has a valid pay-off relationship with the first account from a pre-stored payment relationship.
The device according to claim 17, wherein the service module is further configured to delete the payment relationship after the payment relationship between the first account and the second account is invalid.
The device according to any one of claims 15-17, wherein the receiving module is further configured to receive a request to cancel a payment relationship between the first account and the second account;

The service module is further configured to delete the payment relationship of the first account and the second account according to the request received by the receiving module to cancel the payment relationship of the first account and the second account.
The device according to any one of claims 15 to 19, wherein the charging request further carries an identifier of the first account; wherein the identifier of the first account is used for payment relationship authentication And / or used as a billing reference.
The apparatus according to any one of claims 15 to 19, wherein the control module is further configured to: extend an attribute value pair AVP parameter in the charging request, and carry the second in an extended AVP parameter. The identity of the account.
An apparatus for sharing account resources, characterized in that the apparatus comprises:

a receiving module, configured to receive a charging request for a service request initiated by the first account; the charging request carries an identifier of a second account for charging, and the second account has a generation with the first account Pay relationship

The charging module is configured to perform charging for the service request initiated by the first account by using the second account.
The device according to claim 22, wherein the receiving module is further configured to receive a payment relationship between the first account and the second account, where the payment relationship includes the first account Identification and identification of the second account;

The device also includes:

a storage module, configured to store the payment relationship.
The device according to claim 22 or 23, wherein the charging request further carries an identifier of the first account.
The device according to claim 24, wherein the charging module is specifically configured to determine, according to the identifier of the first account, a charging rate for a service request initiated by the first account, to determine The billing rate is billed in the second account.
The device according to claim 24 or 25, wherein the charging module is further configured to authenticate the charging request according to the stored payment relationship, and determine the carrying in the charging request. The identifier of the first account and the identifier of the second account satisfy the payment relationship.
The apparatus according to any one of claims 24 to 26, wherein the charging request includes an extended attribute value pair AVP parameter, and the identifier of the second account is carried in the extended AVP parameter.
The device according to any one of claims 24 to 27, wherein the charging module is further configured to generate a bill including the first account identifier and the second account identifier.