JPH0834527B2 - Billing method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Industrial field of application] The present invention easily charges for each service type even when a service type change request is made while one or more services are being executed. It relates to the charging method to be obtained.

[Conventional technology]

The conventional charging method is a method of charging until the end of service at a fixed charging rate for one service type determined when a service request is made, as described in, for example, Japanese Patent Laid-Open No. 60-28360. Even if a plurality of services are provided to the calling party or the called party, the provided services are treated as a unified charge.

[Problems to be solved by the invention]

In the above conventional technology, when a calling party or a called party adds or deletes a service type while a plurality of services are simultaneously provided to the calling party or the called party,
In order to adjust the charge sharing between the two parties, it is necessary to newly determine the sharing method for the calling party or the called party. Therefore, it is necessary to terminate the service once and make a call so that the service after the service type change is performed. in this case,
Since the charging methods that exist for various types of services are mixed, it is not easy to redetermine the sharing method. Moreover, it is almost impossible when the service type change request from the calling party or the called party changes dynamically during the service.

An object of the present invention is to provide a billing method that can easily perform billing for each service type even when a caller or a called party makes a service type change request during service.

[Means for solving problems]

The above-mentioned object is a service database for registering a calling party identification code, a called party identification code, a calling party billing degree, a called party billing degree, a service type code, a billing count, and a billing target code in a switch of a switching network. Is provided separately from the charging database for each subscriber, and when a service request is made, the service is provided after the information related to the service is registered in the service database. When there is a service change request from the service called party, if the service is to be deleted based on the service change request, the charge level of the service to be terminated is calculated, this is registered in the service database, and then the service is deleted. When adding a service based on a service change request, information regarding the additional service After providing all the requested services, the caller charging degree and the called party charging degree in the service database are transferred to the subscriber-by-subscriber charging database after all the requested services have been provided. The registration data in the service database is erased, and charging is performed based on the charging data in the charging database for each subscriber.

[Action]

A service database is provided to provide information such as a calling party identification code, a called party identification code, a calling party billing degree, a called party billing degree, a service type code, a billing count, and a billing target code related to a provided service. Since the service is provided after the registration, the fluctuation of the charging degree caused when the service is changed is temporarily registered in the service database, and the charging degree in the service database is transferred to the charging database for each subscriber after the service ends. Easily handle dynamic service change requests.

〔Example〕

An embodiment of the present invention will be described below with reference to the accompanying drawings.

FIG. 2 is a system configuration diagram of an exchange network to which a charging method according to an embodiment of the present invention is applied. In FIG. 2, an exchange 10 includes a digital terminal interface 31, an input / output trunk 32, an exchange controller (CP) 11 and a common line signal controller (CCP) 15, and the exchange controller 1
A service database (SDB) 12, a charge level conversion table (RDB) 13 for each service type, and a charge level database (CDB) 14 for each subscriber are connected to 1. The data line 50 and the signal line 51 connecting the terminal 1 and the exchange 10 are connected to the digital terminal interface 31, and the signal line 51
Is sent to the signal line 61 through the exchange control device 11, the common line signal control device 15 and the input / output trunk 32. Further, when the data line 50 and the data line 60 are connected, the link 52 is set.

The exchange 20 includes a digital terminal interface 41, an input / output trunk 42, a exchange controller (CP) 21, and a common line signal controller (CCP) 25. The exchange controller 21 includes a service database (SDB) 22 and a service type. A billing degree conversion table (RDB) 23 for each subscriber and a billing degree database (CDB) 24 for each subscriber are connected. Terminal 2 and exchange 2
The data line 70 and the signal line 71 connecting 0 are connected to the digital terminal interface 41, and the signal of the signal line 71 is sent to the signal line 61 through the exchange control device 21, the common line signal control device 25, and the input / output trunk 42. Sent out. Further, when the data line 70 and the data line 60 are connected, the link 72 is set.

FIG. 3 is a block diagram of the service database SDB.
The service database SDB registers an area for registering a service caller number (identification code) and a service called party number (identification code) when a service is called, a calling party charging degree registration area, and a called party charging degree registration. Area, service type code registration area, charging count registration area having an initial count (value) of 0 provided for each service type, and charging target code registration area indicating which of a calling party and a called party is charged And are provided. A service type code registration area, a charging count registration area having an initial count (value) of 0 provided for each service type, and a charging target code registration area indicating which of a calling party and a called party is charged. Is designed to be extended with a continuation pointer if needed.

FIG. 4 is an explanatory diagram of a charge level conversion table (RDB) for each service type. The charge rate for each service type is set in the charge frequency conversion table for each service type. For example, the short-distance call VO is set to 1 count per count, the medium-distance call V1 is set to 10 counts per count, ..., The text-to-speech conversion service C0 is set to 50 counts per count.

FIG. 5 is an explanatory diagram of charging target codes. In this embodiment, the calling party is charged when the charging target code is "01", and the called party is charged when the charging target code is "10".

FIG. 6 is a block diagram of the charging frequency database CDB for each subscriber. The subscriber charging frequency database CDB has a subscriber identification code registration area and a charging frequency count registration area.

Next, a charging method according to the present embodiment in the exchange network system having the above-mentioned configuration will be described with reference to the flow chart of FIG. In this embodiment, a person who requests the addition of a service is charged for the service. However, the present invention is not limited to this, and it goes without saying that the service called party can always be charged.

For example, when the service caller issues a service start request from the terminal 1, this request is detected by the CP 11 of the exchange 10 as shown in FIG. 1 (a) (step 100). Then, the CP 11 registers the calling party number (identification code) and the called party number (identification code) transmitted from the service caller in the service database 12 (step 102) and sets the service type requested by the caller. The charge count initial value "0" for each type and the charge target code "01" indicating the charge target (service caller) are registered in the service database 12 for each requested service (step 104). The requested service is started between the caller and the called party, between the calling party and the exchange, or between the called party and the exchange (step 10).
6).

Proceeding to FIG. 1 (b), when a request code is transmitted from the calling party (or called party) through the terminal 1 (or terminal 2) after the service is started, the request code is detected by the CP11 (or CP21). (Step 110) and analyzed (Step 112). As a result of this analysis, when it is determined that all services should be terminated, the process proceeds to service termination processing (step 120) and the service database 1
The service is terminated for each of the services registered in 2 and the charge count is changed. Then, in step 148 of FIG. 1 (c), when the CP 11 detects the end of all services, first, the accounting degree (value) for each service type is used to calculate the accounting degree using the accounting degree conversion table of FIG. Then, the calculated charge is added to the total frequency of the caller and the callee on the service database 12 (FIG. 3) corresponding to the caller who has issued the termination request. The frequency is added for each service type (step 150). And then the service database 1
2 Total charge count on the charge count database for each subscriber 14
It is added to the total charge degree (FIG. 6) (step 152), and a series of information (caller / callee identification code, which indicates the relationship between the service caller and the callee) is displayed on the service database 12. The charge frequency, service type, charge count for each type, charge target code) is deleted (step 153). here,
If there is a charge to the called party (step 154), CP1
1 transfers the callee's charge level data to the exchange 20 on the callee side (step 156), and the CP 21 adds the charge level to the charge database 24 for each subscriber (step 158), and terminates all processing. To do.

If the request code described in FIG. 1 (b) does not indicate the end of all services or service changes, or if no request code is input from the terminal, step 118
Then, the process proceeds to step S12 to update the charge count for each service type on the service database 12. Here, the CP 11 updates the billing count for each service type transferred by a billing program having publicly known services after executing a service unit such as a fixed time period or a fixed communication amount unit.

If the request code described with reference to FIG. 1 (b) is not for all service termination requests but for changing service content, the process proceeds from step 116 to service content changing processing of FIG. 1 (d). In the service content change processing, first, the change request code and the service type code sent from the terminal 1 (or 2) to the signal line 51 (or 71) are analyzed (step 170), and the analysis result by the determination processing of step 172 is obtained. If it is the deletion code, the service database 12 is searched for whether or not the service type to be deleted exists (step 174). If the service type to be deleted exists, the execution of the service is ended (step 174). 17
Five). Then, the charging frequency is calculated from the charging count of the service type according to the conversion table of FIG. 4 (step
176), if the charge target code indicates the calling party (step 178), the obtained charging degree is added to the calling party charging degree of the same service database 12 (step 180). When the charge target code indicates the called party, the obtained charging degree is added to the called party charging degree of the same service database 12 (step 182). When the process of step 180 or 182 is completed, the process proceeds to step 184, and the service type, the charge count for each type, and the charge target code which are the deletion targets are deleted from the service database 12.

Step 172 because the change request code is not a delete code
If the determination is negative (N) or the processing of step 184 ends, the process proceeds to FIG. 1 (e). Here, first, it is determined whether or not the change request code is service addition (step 190), and if it is a service addition request, it is searched whether or not the service type to be added already exists in the service database 12. Is done (step 192).
If the service to be added does not exist, the program for executing the service to be added is activated by the CP 11 (step 193), and the type of service to be added and the billing count (initial value 0) are registered in the service database 12 (step 194). . If the addition request is from the caller, the code "01" that charges the caller is registered in the service database 12 (step 198), and the addition request is from the callee. If so, the code "10" for charging the called party is registered in the service database 12 (step 200). Next, the CP 11 confirms whether the service to be added is being executed (step 202), and if not, deletes the service type additionally registered in the service database 12 (step 204).

When the determination process of step 192 is affirmative (Y), the determination process of step 202 is affirmative (Y), and the determination process of step 204 is completed, or when the determination process of step 174 of FIG. 1 (d) is negative (N). Returns to step 101 in FIG. 1 (b).

According to the above processing procedure, while one or more services provided from the switching system to the service caller or the service callee are being executed, the service caller or the service callee receives a call from the service caller or the service callee. When a service addition or deletion request is made, a charging target is set for each additional service to indicate the charge to the service caller or service called party, and a service caller or service called is set for each deletion service. It is possible to set whether to charge the person.

In the above-described embodiment, the charge target code is set in steps 104, 198 and 200, but other processing codes such as shared charge may be input under the agreement between the calling party and the called party. . By doing so, the charge sharing rate set for each service type is calculated, and the service charge can be charged to the calling party and the called party at an arbitrary rate.

Further, in the embodiment, the service database of the calling side exchange 10 is used, but the service database of the called side exchange 20 can also be used. That is, the charging information can be managed by using a database or the like without being limited to the calling party and the called party.

Further, in the embodiment, the billing program executed for each service transfers and registers the billing information of the service (service time, processing data, etc.) to the billing count for each service type at a fixed time or at a fixed process. But,
The billing program may convert the billing unit into a frequency unit common to all services, and transfer the unit at a fixed time or at a fixed frequency. By doing so, it becomes possible to add the total frequencies to the calling party and the called party without using the table of FIG. 4 in the accounting frequency calculation,
The table search time can be omitted.

Furthermore, when the execution of the additional service is not confirmed in step 202 of the embodiment, the CP 11 uses the signal line to the terminal 1 or 2 of the calling or called party who requested the addition, It is easy to transfer the message "service execution is not possible" and output and display it on the terminal 1 or 2 so as to confirm with the calling party or called party who requested addition.

〔The invention's effect〕

According to the present invention, for the service provided by the switching system, management of charging data to the calling party or called party for each service type is performed, and a dynamic service content change request from the calling party or called party is requested. There is an effect that it can be easily executed.

[Brief description of drawings]

1 (a), (b), (c), (d), and (e) are flow charts showing the processing procedure of the charging method according to an embodiment of the present invention, and FIG. 2 is an exchange network system. Diagram,
FIG. 3 is a block diagram of the service database shown in FIG. 2,
FIG. 4 is a configuration diagram of a charge level exchange table for each service type shown in FIG. 2, FIG. 5 is an explanatory diagram of a charge target code, and FIG. 6 is a configuration diagram of a charge database for each subscriber shown in FIG. 1,2 ... Terminal, 10,20 ... Switch, 11,21 ... Switch control device, 1
2, 22 ... Service database, 13, 23 ... Service type charge level conversion table, 14, 24 ... Subscriber charge database.

Claims (1)

[Claims] 1. An arbitrary two terminals are accommodated in a switching network in which exchanges are connected by a data line and a common line signaling system via the data line and the signal line, and the arbitrary two terminals are exchanged. While connected via a network, one or more different services including a call service, a translation service, and a voice / data storage service are connected to the two terminals from the switching network, and are called or called. This is a charging method in the case where the addition / deletion of service types during the service is provided at any time based on the service change request from the terminal. A charge rate database and service database for each subscriber, and a charge rate database for each subscriber are provided in advance in the exchange accommodated by the called terminal. In addition, it is assumed that the calling party identification code and the called party identification code are registered in common in the service types on the basis of the information at the time of calling to the called terminal on the service database. A service type code for identifying the service type of the service, every time a service addition request is made from the calling terminal or the called terminal after the service request and after the initial service is started, and the initial value of the service A charge count value and a charge target code indicating a predetermined service charge sharing ratio for the service are registered in the service database, and the charge count value is initially set for each service type while each service is performed. Each time a service deletion request is made from either the calling terminal or the called terminal, while +1 is updated from the value at regular intervals , From the final accounting count value obtained for each service type according to the deletion request,
The shared billing degree for each of the calling party and the called party, which is obtained by referring to the billing degree conversion table corresponding to the service type and the billing target code, is cumulatively added between the service types, and then added to the above service database. It shall be registered once, and after waiting for the disconnection between the calling terminal and the called terminal, the cumulative additional charge for the calling party on the service database shall be calculated for each subscriber on the side of the calling terminal accommodating exchange. In addition to being added to the total billing rate for the calling party registered in the billing degree database, the cumulative additional charge rate corresponding to the called party in the service database is the common line signaling system for the exchange accommodated in the called terminal. And is added to the total billing rate for the called party registered in the billing rate database for each subscriber on the side of the exchange accommodated by the called terminal. Charging method which is adapted.