System and method for creating a billing record with a called party's name

[0002] The present invention relates generally to the creation of billing records and specifically to a system and method for creating a billing record with a called party's name.

[0003] Billing records (i.e., telephone bills) often provide the geographic location and telephone number of a person called by a calling party (“a called party”). Because it can be difficult to determine the identity of the called party based on geographic location and telephone number alone, the calling party often resorts to the time-consuming task of contacting directory assistance or his billing service to identify the calls. Determining the identity of the called party based on geographic location and telephone number is made even more difficult when a called party subscribes to a number portability service, which allows a called party to retain the same telephone number even when he moves to a different geographic location. With such a service, the area code listed on the billing record may not correspond with the geographic location listed on the billing record.

[0004] There is, therefore, a need for an improved billing system and method that will overcome the disadvantages discussed above.

[0005] FIG. 1 is an illustration of a presently preferred printed billing record showing the names of called parties.

[0006] FIG. 2 is a block diagram of a billing record generation system of a presently preferred embodiment

[0007] FIG. 3 is a block diagram of a system of a preferred embodiment for creating a billing record with a called party's name.

[0008] FIG. 4 is a flow chart of a preferred method of creating a billing record with a called party's name using the preferred system of FIG. 3.

[0009] FIG. 5 is a block diagram of system of another preferred embodiment for creating a billing record with a called party's name.

[0010] FIG. 6 is a block diagram of a system of another preferred embodiment for creating a billing record with a called party's name.

[0011] FIG. 7 is a block diagram of a system of another preferred embodiment for creating a billing record with a called party's name.

[0012] By way of introduction, the preferred embodiments described below include a system and method for creating a billing record, such as the billing record 100 shown in FIG. 1, with a called party's name. Providing the called party's name on the billing record facilitates the calling party's review of the billing record by reducing the amount of time and effort needed to determine the identity of the called parties. In addition to identifying fraudulent and misbilled calls, the called party's name allows a person reviewing the billing record to quickly identify long distance calls, quickly discern business from personal calls, and audit calls made from phone lines with multiple users (e.g., employees or kids). Additionally, the billing record reviewer saves time and money by avoiding the need to call directory assistance or a billing service to identify the calls.

[0013] Turning again to the drawings, FIG. 2 is a block diagram of a billing record generation system 200 of a presently preferred embodiment. As shown in FIG. 2, this system 200 comprises a public switch 210, a billable call creator 220, a call rating module 230, a call storage database 240, a call pricing module 250, a billing record assembler 260, a customer account database 270, a billing record formatter 280, and a billing record generator 290. The billing record generator 290 can comprise, for example, a printer 292, a CD-ROM drive 294, a tape/cartridge deck 296, and/or a data network interface 298.

[0014] In operation, the public switch 210 (ie., the telephone network) delivers a call record detailing the calls associated with the public switch 210 to a billing system. This is done after call processing, after the call is complete, and during the billing process in the billing system. The first component of the billing system is the billable call creator 220, which edits the call record to remove those call that will not be billed. For example, the billable call creator 220 can remove information about calls that were attempted but not terminated. The edited call record is then sent to the call rating module 230, which rates the calls and includes the rating information in the call record. The call record is then stored in the call storage database 240. It is preferred that the call record be provided by the public switch 210 and edited, rated, and stored on a daily basis.

[0015] At a given time, call records for individual calling parties are extracted from the call storage database 240, and the calls are priced by the call pricing module 250. Preferably, this takes place at the end of the billing period (e.g., at the end of a month) in order to apply volume discounts that are calculated at the end of the billing period. The call record is then sent from the call pricing module 250 to the billing record assembler 260, which combines the call record with information from the customer account database 270 to assemble a billing record for the calling party. The information from the customer account database 270 can include, for example, recurring monthly charges, non-recurring charges, credits, adjustments, current balance, previous balance, payments, and usage.

[0016] After the billing record is assembled, the billing record formatter 280 places the assembled billing record into a format specified by the customer account database 270. For example, the customer account database 270 can instruct the billing record formatter 280 to sort the calls in a particular order and to generate the billing record in an electronic or hard-copy form. The formatted billing record is then sent to the billing record generator 290, which prints a hard copy of the billing record using the printer 292. In addition to or as an alternative to a printed billing record, an electronic copy of the billing record can be provided to the calling party with, for example, the CD-ROM drive 294, the tape/cartridge deck 296, and/or the data network interface 298.

[0017] FIG. 3 is a block diagram of a system 300 of a preferred embodiment for creating a billing record with a called party's name. This system 300 is identical to the system 200 of FIG. 2 but further includes a terminating name module 362 coupled with a terminating-number-to-called-party's-name database 364. Preferably, the terminating-number-to-called-party's-name database 364 comprises a national and/or international directory assistance database. As used herein, the term “coupled with” means directly coupled with or indirectly coupled with through one or more components. As described in more detail below, the terminating name module 362 can extract a terminating number from the call record. In this preferred embodiment, the terminating name module 362 is part of the billing record assembler 360. If a calling party subscribes to the called-party's-name-on-bill service, the customer account database 370 sends a trigger to the terminating name module 362 in the billing record assembler 360 to determine the name of the called party associated the terminating number.

[0018] FIG. 4 is a flow chart of a preferred method of creating a billing record with a called party's name using the preferred system 300 of FIG. 3. As is apparent from the foregoing description, this method preferably takes places after a call is complete. First, the terminating name module 362 extracts terminating numbers from the call record (step 410). The terminating name module 362 can then determine which of the terminating numbers, if any, are eligible for the called-party's-name-on-bill service, as described below. Next, the terminating name module 362 queries the terminating-number-to-called-party's-name database 364 with the extracted terminating numbers to perform a reverse directory-assistance look-up (step 420). It is preferred that the terminating name module 362 sort the extracted terminating numbers to query only one instance of a given terminating number. The terminating name module 362 then modifies the call record to include the called party's name returned from the query (step 430). If the extracted terminating numbers were sorted so only one query per instance of a given terminating number was sent, it is preferred that the returned called party name be added to every occurrence of the terminating number in the call record. The modified call record is then passed to the other parts of the billing system, where a hard or electronic copy of the billing record can eventually be generated (step 440).

[0019] If the terminating-number-to-called-party's-name database 364 that is coupled with the terminating name module 362 does not contain the called party's name, the terminating name module 362 (“the first terminating name module”) can transfer the query to another terminating name module (“the second terminating name module”) coupled with a database that does contain the information. In this situation, it is preferred that the first terminating name module place the terminating number in a message format in accordance with the Electronic Directory Assistance (“EDA”) Standard Interface Specification Version 1.1, dated Oct. 16, 1997 and send the message to the second terminating name module. The second terminating name module then converts the EDA protocol into the protocol required by the database and performs the query. After the database returns a response to the query, the second terminating name module converts the database protocol back into the EDA protocol and sends the response to the first terminating name module, which extracts the called party's name from the EDA protocol and modifies the call record, as described above.

[0020] In the system 300 of FIG. 3, the terminating name module 362 is part of the billing record assembler 360. The terminating name module can, however, be implemented in other parts of the billing system, and the eligible terminating numbers can be extracted from the call record that is present in that part of the system. For example, FIG. 5 shows a billing system 500 in which the terminating name module 552 is part of the call pricing module 550. By being part of the call pricing module 550, the terminating name module 552 can extract eligible terminating numbers from the call record present in the call pricing module 550 and can query the terminating-number-to-called-party's-name database 554 to determine the called party's name during pricing when volume discounts, calling plans, and usage summaries are being calculated. In other alternatives, the terminating name module 632, 742 can be part of the call rating module 630 (as shown in FIG. 6) or the call storage database 740 (as shown in FIG. 7), and the eligible terminating numbers can be extracted from the call record in the call rating module 630 and call storage database 740, respectively. Since adding the called party's name to the call record may lengthen the call record, several components of the billing system may need to be modified accordingly. To introduce the least amount of intrusion into the billing system, it is preferred that the terminating name module be part of the billing record assembler, as shown in FIG. 3. Further, by being part of the billing record assembler, the terminating name module would be more response to those customers who activate or de-activate the service in the middle of a billing cycle (i.e., mid-month).

[0021] In the preferred embodiments described above, the call record was modified to include the called party name. To ensure that the call record is the same length before and after the modification, the called party's name can replace one of the fields (e.g., geographic location) already present in the call record. Alternatively, the called party's name can be added to the call record to create a more informative billing record. For example, providing the called party's name with the geographic location information can be particularly helpful when the called party's name is not available in the database or if the response from the database is inaccurate. Adding additional information to the record may require altering some parts of the billing system to accept the record.

[0022] As described above, the terminating name module can select which terminating numbers are eligible for the called-party's-name-on-bill service, thereby making the billing system more efficient. For example, the terminating name module can exclude those numbers that are already identifiable to a phone user, such as those for directory assistance, voice-message services, information provider services (e.g., 900 and 976 service), and conference-call set-up calls. If a particular telephone company only has access to a national directory assistance database, international numbers can be excluded from the terminating name module. If a particular telephone company only has access to a national directory assistance database, it is preferred that only the call types shown in Table 1 be sent to the terminating name module.

[0023] The call types shown in Table 1 refer to call types described in the document “Bellcore Standard Exchange Message Records” (Document Number BR 010-200-010). Of the call types listed in Table 1, it is preferred that only those calls with a settlement code number or a value of J in position 149 (the “settlement code”position) of the exchange message record be sent. It is preferred that the data used to query the database be the data stored in position 30-39 (the “to number”). If a value of 2 (collect) is stored in position 80 (“the call message type”), it is preferred that the data stored in position 15-24 (the “from number”) be used. Position 15-24 (the “from number”) is also preferably used for call types 010105 and 010125.

[0024] For simplicity, the terms “terminating name module”, “billing record assembler”, “call pricing module”, “call rating module”, “billable call creator”, and “billing record formatter” are used in the specification and claims to broadly refer to hardware and/or software that can be used to perform the functions described above. It is important to note that any appropriate software language and any appropriate hardware, analog or digital, now in existence or later developed, can be used. Examples of hardware that can be programmed to perform the above-described functions include IBM Series Numbers 9672 and 9021 and RISC-6000 systems. A computer-usable medium having computer readable program code embodied therein can be used to perform the functions described above, and the functions described above can alternatively be implemented exclusively with hardware. Additionally, the functionality associated with each element can be combined with or distributed to other elements. Also, some of the elements described above may not be needed in all embodiments.

[0025] It is intended that the foregoing detailed description be understood as an illustration of selected forms that the invention can take and not as a definition of the invention. It is only the following claims, including all equivalents, that are intended to define the scope of this invention.