# Patent

## Title
Method and apparatus to validate a subscriber line

## Abstract

A method is described of providing validation data associated with a subscriber line of a telecommunication network using a validation system. The method includes obtaining line data of the subscriber line wherein the line data is suitable for interrogating a line identification database (LIDB). The method interrogates the LIDB with the line data to obtain reference subscriber data associated with the line data, and processes the reference subscriber data to obtain validation data associated with the subscriber line. The method includes identifying a local exchange carrier (LEC) associated with the subscriber line to determine if a billing arrangement exists between the validation system and the LEC. The invention extends to a subscriber line validation system to validate a subscriber line of a communication network.

## Background
The present application is a continuation application of U.S. application Ser. No. 10/225,098 filed Aug. 20, 2002, now U.S. Pat. No. 7,054,430 which claims the benefit of the filing date of U.S. provisional patent application No. 60/314,604 entitled “METHOD OF VALIDATING A SUBSCRIBER LINE” filed Aug. 23, 2001.


BACKGROUND TO THE INVENTION
An increasing number of vendors are offering goods and/or services which may be purchased via a communication network such as a telecommunication network. For example, the customer may conduct a transaction via a subscriber line using a landline telephone or a personal computer. Conventionally, credit or debit card details are furnished by the customer to the vendor to effect payment for the goods and/or services. As many customers are hesitant to supply credit or debit card details over a communication network, an alternate method of payment would be advantageous. However, if an alternate method is used, verification of the payment method should preferably take place prior to concluding the transaction.
SUMMARY OF THE INVENTION
In accordance with the invention, there is provided a method to provide validation data associated with a subscriber line of a telecommunication network, the method including:
obtaining line data of the subscriber line, the line data being suitable for interrogating a line identification database (LIDB);
interrogating the LIDB with the line data to obtain reference subscriber data associated with the line data; and
processing the reference subscriber data to obtain validation data associated with the subscriber line.
The LIDB may be a conventional LIDB used by a service provider, e.g. a local exchange carrier, to investigate a destination or termination line to which a carrier requests a connection.
The method may include analyzing the reference subscriber data to determine if the data is associated with a billing telephone number (BTN) and, if so, generating an approval or a decline status. In one exemplary embodiment, the line data is automatic number identification (ANI) data and, the method includes interrogating the LIDB using the ANI data (herein also referred to as the ANI). The validation data may be processed to determine whether the subscriber line is a billable line having an associated account to which goods or services can be billed.
The reference subscriber data received from the LIDB may be processed selectively to approve a transaction requested via the subscriber line. In one exemplary embodiment, the reference subscriber data is in the form of conventional LIDB codes and the operation to process the data may include generating a modified code from at least one LIDB code. In certain embodiments, a common modified code is generated from a plurality of LIDB codes. The modified codes may be arranged in a billable group and a non-billable group.
The method may include conducting fraud control checks on the account associated with the subscriber line number or ANI. The fraud control checks may include at least one of the operations selected from the group consisting of checking if adjustments have been made to the account associated with the ANI, verifying a user entered ZIP code with ZIP data from a ZIP data source, verifying user entered address data with address data from an address data source, checking if the area code associated with the ANI has changed, checking if the ANI and the BTN match, and checking if the BTN or ANI are missing from the record.
The method may include interrogating a network database with the ANI to determine if the subscriber line is a billable subscriber line and, if not, generating a decline status. The method may include interrogating with the line data at least one of a competitive local exchange carrier (CLEC) database, a 42 BLOCK database, a Block and Cancel database, an unpaid bills database, an off network database, an on network database, an address verification database, a regional account office (RAO) database, an operating company number (OCN) database, and a customer account record exchange (CARE) database and selectively generating one of a decline status and an approved status in response to the interrogation.
The method may include receiving the line data from a vendor of goods or services (e.g. an Internet Service Provider (ISP)); and communicating at least the decline status to the vendor.
In one exemplary embodiment, the charges raised by the vendor are included in an account submitted by the exchange carrier to a subscriber for use of the subscriber line.
Further in accordance with the invention, there is provided a computer-readable medium for storing a set of instructions that, when executed by a machine, cause the machine to execute the method.
Still further in accordance with the invention, there is provided a subscriber line validation system for validating a subscriber line of a communication network, the system including:
a communication module for receiving line data of the subscriber line, the line data being suitable for interrogating a line identification database (LIDB);
an interrogation module for interrogating the LIDB with the line data to obtain reference subscriber data associated with the line data; and
a processor module for processing the reference subscriber data to obtain validation data associated with the subscriber line.
In one exemplary embodiment, the LIDB is a conventional LIDB. However, in other embodiments, a plurality of LIDBs may be provided that are used by one or more service providers, e.g. local exchange carriers, to investigate a destination or termination line to which a subscriber line requests a connection.
In one exemplary embodiment, the processor module is configured to analyze the reference subscriber data to determine if the data is associated with a billing telephone number (BIN) and, if so, the system generates a decline status. In one embodiment, the line data is automatic number identification (ANI) data and the processor module interrogates the LIDB using the ANI data.
The validation data may be processed to determine if the subscriber line is a billable line having an associated account to which goods or services can be billed.
The reference subscriber data may be received from the LIDB and may be processed selectively to approve a transaction requested via the subscriber line.
The reference subscriber data is preferably in the form of conventional LIDB codes and the processor module may generate a modified code from at least one LIDB code. In certain embodiments, the processor module generates a common modified code from a plurality of different LIDB codes. In one embodiment, the modified codes are arranged in a billable group and a non-billable group.
In certain embodiments, the system may conduct fraud control checks on an account associated with the ANI. The processor module may be configured to conduct at least one fraud control check selected from the group consisting of checking if adjustments have been made to the account associated with the ANI, verifying a user entered ZIP code with a ZIP data source, verifying user entered address data with an address data source, checking if the area code associated with the ANI has changed, checking if the ANI and the BTN match, and checking if the BTN or ANI are missing from the record.
The processor module may interrogate a network database with the ANI to determine if the subscriber line is a billable subscriber line and, if so, generate a decline status.
In certain embodiments, the system may interrogate at least one of a competitive local exchange carrier (CLEC) database, a 42 BLOCK database, a Block and Cancel database, an unpaid bills database, an off network database, an on network database, an address verification database, a regional account office (RAO) database, an operating company number (OCN) database, and a customer account record exchange (CARE) database.
The system may include receiving the line data from a vendor of goods or services; and communicating at least the decline status to the vendor. Charges raised by the vendor may be included in an account submitted by the exchange carrier to a subscriber for use of the subscriber line.
Further in accordance with the invention, there is provided a system to provide validation data associated with a subscriber line of a telecommunication network, the system including means for obtaining line data of the subscriber line, the line data being suitable for interrogating a line identification database (LIDB); means for interrogating the LIDB with the line data to obtain reference subscriber data associated with the line data; and means for processing the reference subscriber data to obtain validation data associated with the subscriber line.



BRIEF DESCRIPTION OF THE DRAWINGS
The invention is now described, by way of example, with reference to the accompanying diagrammatic drawings.
In the drawings,
FIG. 1 shows a schematic block diagram of a subscriber line validation system, in accordance with the invention, for validating a subscriber line of a communication network;
FIGS. 2 to 4 show a schematic flow chart of a method, in accordance with the invention, for validating the subscriber line;
FIG. 5 shows a schematic block diagram of how the system may be used in a conventional commercial environment; and
FIG. 6 shows a schematic representation of a sample telephone bill platform which the system can automatically update.
FIG. 7 shows a diagrammatic representation of machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one of the methodologies discussed herein, may be executed.



DETAILED DESCRIPTION
Referring to the drawings, reference number 10 generally indicates an exemplary subscriber line validation system, in accordance with an aspect of the invention, for validating a subscriber line 17 of a subscriber. In one exemplary embodiment, the subscriber line 17 is a telephone line or the like which a consumer or business 11 (see FIGS. 1 and 5) obtains from a telephone company (Telco) 13 or a local exchange carrier (LEC). As described in more detail below, the system 10 uses line data in the exemplary form of an automatic number identification (ANI) service to obtain the telephone line number of the subscriber line 17 thereby to validate the subscriber line 17 when the subscriber line 17 initiates a communication or connection. In one exemplary embodiment, the line number obtained from the ANI service is used to investigate various databases to obtain, for example, an indication of the credit worthiness of the subscriber account associated with the subscriber line 17. It is to be appreciated that any electronic apparatus, e.g. a personal computer, PDA, cellular telephone, or the like may be used to initiate the communication.
Referring in particular to FIG. 1 of the drawings, the system 10 includes an application program interface (API) 14 which is connected to a vendor 12 or service provider (see also FIG. 5) of goods and/or services which requires validation of a subscriber account. The vendor 12, which could for example be an Internet Service Provider, may request the validation of the subscriber line 17 prior to concluding an electronic transaction with a subscriber (e.g., a consumer or business 11) via the subscriber line 17. It is, however, to be appreciated that the API 14 may be connected to a variety of different hosts or clients which require validation of a subscriber line via which the vendor may carry out transactions for goods and/or services.
In one exemplary embodiment, the system 10 is connected to a plurality of vendors which conduct transactions with users via line termination equipment such as a telephone, a personal computer or the like. Such vendors, when conducting transactions, may preferably charge a user for their services by adding such charges to a telephone account of the user rather than charging the goods and/or services to a credit card, debit card, or the like. Accordingly, the validation of the subscriber line 17, and the subscriber account associated with the subscriber line 17, may be of benefit to the vendor 12 prior to completing a transaction. The validation may include determining whether or not the subscriber line 17, via which the communication is made to the vendor, is a billable line and, accordingly, the subscriber account associated with the subscriber line 17 may thus be billed for the transaction.
In one exemplary embodiment, the vendor 12 communicates a request to the system 10 and forwards the subscriber line number, determined by the ANI service, to the system 10 via its API 14. The system 10 then processes the information received from the vendor 12 and provides a validation status, e.g. a code indicating a valid billable number or a code indicating that the subscriber line number is not a valid billable number (e.g. unbillable or non-billable). In particular, a plurality of codes associated with various statuses of the subscriber line 17 may be communicated to the vendor 12 as described in more detail below.
The system 10 includes hardware and software to implement the invention. In the exemplary embodiment, the system 10 includes a comparator module 18, a threshold database 20, an OFFNET database 22, an ONNET database 24, a competitive local exchange carrier (CLEC) database 26, a 42 BLOCK database 28, a block and cancel database 30, an unbilled and/or unpaid bills database 32, line identification database (LIDB) short term cache 34, a validity check module 36, a regional account office (RAO) database 38, an operating company number (OCN) database 40, an ONNET database 42, an address verification database 44, a customer account record exchange (CARE) results database 46, an ANI watch database 48, and an NPA (Numbering Plan Area) exchange database 50. It is to be appreciated that, in less sophisticated embodiments of the invention, all of the above databases need not be included. However, for enhanced accuracy, all of the above databases are preferably included. Further databases may also be included to further enhance the reliability of the validation process.
In addition to any one or more of the above databases, the system 10 is in communication via a conventional communication channel with an off-site or, in some embodiments, on-site line identification database (LIDB) host 52. The LIDB host 52 may include a line number portability (LNP) database. In one exemplary embodiment, the LNP database may front end access to a plurality of industry standard LIDBs (e.g. 13 different LIDBs). The LNP database may however be a separate database. As described in more detail below, the system 10 communicates the subscriber line number to the LIDB host 52 which, in turn, communicates reference subscriber data in the form of industry standard LIDB codes back to the system 10 for processing. The system 10 then processes the LIDB codes to provide the vendor with validation data relating to the subscriber line 17. Unlike conventional LIDB applications which use LIDB to make decisions regarding destination subscriber lines or call completion decisions, e.g. decisions for calling cards, collect and third party toll services or the like, the system 10 may be used to identify telephone numbers being served by CLECs in order to ensure that calls are routed correctly on ported lines.
Broadly, the system 10 has a variety of different components, including a communication module defined by the API 14, and a processor module 54. The a processor module 54 includes the various databases 20 to 32 as well as the comparator module 18 and the validity check module 36, and an interrogation module 56 for interrogating the LIDB host 52. It is to be appreciated that the aforementioned modules may be defined by one or more servers with associated databases. Further, in the drawings, the LIDB host 52 is shown as a single database but may comprise many different LIDB databases maintained by various LECs and, accordingly, may be located at various different geographic locations.
Referring in particular to FIGS. 2 to 4 of the drawings, a flow chart describing the method of operation of the system 10 is shown. In one exemplary embodiment, a vendor 12 initiates a request to the system 10 to validate a subscriber line 17 via which the vendor 12 wishes to transact with a customer (consumer or business 11). As shown at operation 60, the system 10 first checks to see if the subscriber line number is present in the request from the vendor 12 and, if no line number is present, a return code 121 is generated and communicated to the vendor as shown at operation 62. The code 121 indicates to the vendor that the system 10 is unable to process the request. If, however, the subscriber line number is present in the request from the vendor 12, the system 10 then checks if the subscriber line number captured (hereinafter also referred to as the ANI) and a billing telephone number (BTN) match, as shown at operation 64 (see also the comparator module 18 in FIG. 1). In one exemplary embodiment, the BTN may be sourced from the consumer or customer 11 when a transaction is requested by the customer 11. If, however, the ANI and the BTN do not match, then the processor module 54 generates a code 120 (see operation 66) to indicate that the caller and the owner of the line number are not the same person (e.g. subscriber inputs a BTN and calls from a different ANI) and the relevant modified code is then returned to the vendor 12. If the ANI and the BTN do match, the processor module 54 interrogates the threshold database 20 (see operation 68) to ascertain whether or not the line number has reached its threshold (e.g., a predefined client threshold parameter such as an account threshold indicating a maximum dollar amount that may be charged to the account). If the line number has reached its threshold, the processor module 54 then generates a code 60, as shown at operation 70, which is then communicated to the vendor 12 to indicate that the line number should not be granted service. In other words, the subscriber account cannot be billed for the goods or services requested by the customer 11 from the vendor 12.
If the threshold for the particular subscriber line 17 has not been reached, the system 10 may then interrogate its OFFNET database (see operation 71) to check if the industry standard NPA/NXX and operating company number (OCN) of the subscriber line 17 is present in the OFFNET database 22. The OFFNET database 22 includes NPA/NXX and OCN combinations of operating companies with which the proprietor or user of the system 10 does not have billing and collection agreements to bill into the telephone company's or Telco's bill page associated with the subscriber line 17. Accordingly, the proprietor or user of the system 10 is unable to include a charge in the account associated with the subscriber line 17 on behalf of the vendor 12 for the transaction carried out with the vendor 12 via the subscriber line 17.
If the line number is in the OFFNET database 22, then the processor module 54 generates codes 130 to 133 (see operation 72) and communicates these codes to the vendor 12. The codes 130 to 133 indicate that the NPA/NXX and OCN for the particular line number 17 are not billable and, accordingly, charges for goods and/or services requested by a customer 11 via the subscriber line 17 cannot be included in a monthly account or the like by the system 10. As shown in Table 2 below, the codes 130 to 133 provide an indication to the vendor 12 why the subscriber line 17 is not billable or deliverable. If the subscriber line number is not included in the OFFNET database 22, a check is conducted to see whether or not the subscriber line number is included in the ONNET database 24. This check is however optional in the embodiment depicted in the drawings, but in certain embodiments, may be mandatory if the system 10 does not include the OFFNET database 22.
Thereafter, as shown in operation 78, the processor module 54 checks to see if the line number 17 is found in a known CLEC table in the CLEC database 26. CLEC numbers are those line numbers that are known to have ported to a CLEC and, accordingly, the proprietor of the system 10 is thus unable to route these line numbers to the correct billing entities. If the line number is found in the CLEC database 26, then the processor module 54 generates a code 140 (see operation 76), which is communicated to the vendor 12. The code 140 indicates that the line number is not billable for the CLEC and the system 10 can thus not charge the transaction to the subscriber account associated with the subscriber line 17.
If the line number is not found in the CLEC database 26, then the system 10 may check to see if the subscriber of the line number has requested a 4250 billing block as shown at operation 78. In particular, the processor module 54 interrogates the 42 BLOCK database 28 and, if the number is located in the database 28, which indicates that monthly recurring charges (4250 charges) are prevented from being billed to that line number, the processor module 54 generates a code 150 (see operation 80) which is communicated to the vendor 12 to indicate that billing to the particular subscriber line 17 has been blocked.
If, however, the subscriber line 17 has not been blocked, the system 10 may then check at operation 82 if the line number is located in the block and cancel database 30 and, if so, the processor module 54 generates codes 160 and 161 which are then communicated to the vendor 12 as shown at operation 84. The block and cancel database 30 includes requests from owners of subscriber lines, agencies, businesses, or the like that a service be canceled or blocked from further billing. Thereafter, the system 10 may interrogate the unbilled and/or unpaid bills database 32, as shown at operation 86, to check if there is a history of any unpaid bills and/or unbillable bills associated with the subscriber line 17. Unbillable bills relate to those subscriber line numbers where previous attempts have been made to bill charges to the subscriber account associated with the subscriber line number 17, and which have been returned as unbillable. If the processor module 54 locates the subscriber line number in the unbillable and/or unpaid bills database 32 then, as shown at operation 88, a code 170 is generated and communicated to the vendor 12 to indicate that the subscriber line number was previously found to be unbillable and is still considered to be unbillable.
The processing described in the abovementioned operations may conduct a preliminary investigation into the subscriber line number or ANI to provide an initial indication of whether or not the ANI corresponds with a billable subscriber line. Once the initial investigation has been conducted in certain embodiments, the system 10 then uses the ANI to obtain reference subscriber line data in the form of LIDB codes from one or more industry standard databases, e.g. the LIDB host or database 52. Examples of the LIDB codes used in the system 10 are shown in Table 3 below.
As shown at operation 90, if the ANI is not found in the LIDB database 52, then the system 10 cannot provide any validation data to the vendor 12 on this subscriber line and an appropriate code is then communicated to the vendor as shown at block 92.
Once the LIDB database or host 52 has been interrogated, it returns industry standard LIDB codes and line number portability (LNP) data to the system 10 as shown in operation 94. The LIDB codes may then be mapped or translated by the processor module 54 into modified validation codes (see Table 3) which provide relevant validation information to the vendor 12. As can be seen from Table 3, the same modified validation code can be generated from a plurality of different LIDB codes. Once the LIDB information codes have been returned to the processor module 54, the LIDB codes, including an OCN and RAO response codes, are fed into the validity check module 36 as shown at operation 96.
As mentioned above, the LIDB host 52 may also provide LNP data to the system 10. The LNP data is used to identify subscriber line numbers that have ported to a CLEC. If a subscriber line has been ported to a CLEC, the billing ONNET status of the CLEC may be verified in the CLEC database 26. The LNP identifies the facilities based CLECs which are CLECs that have been assigned all the line numbers for an NPA/NXX in a specific geographic territory. This type of CLEC may be in control of the cable, dial tone and billing envelope for that number. In one exemplary embodiment, the LNP cannot be used to identify CLEC sellers, which have resold the subscriber line under their brand, but still lease the cable and tone from an incumbent local exchange carrier (ILEC). Accordingly, a third-party billing facility, e.g. a proprietor or user of the system 10, may be unable to process transaction data onto a bill page of the CLEC reseller bill page. In order to identify reseller CLECs, the system 10 may compare RAO and OCN information, returned from the LIDB host 52, to data in the ONNET database 24. The OCN is the local Telco that owns the subscriber line number and the RAO is the office of the Telco that is responsible from a billing standpoint for the subscriber line number.
If the validity check module 36 determines that the response codes are invalid, the system 10 generates modified codes 180 to 999 (see operation 98 and Table 2) which are communicated to the requestor or vendor to indicate that the mapping of the LIDB codes to the modified codes concluded that the line is an unbillable subscriber line.
If the validity check module 36 confirms the validity of the LIDB codes and, in the event of the line number being a billable line number, the processor module 54 then may check the RAO database 38 to ascertain whether or not the RAO is billable, as shown at operation 100. If the RAO is not billable, then the processor module 54 generates and communicates a return code 143 (see operation 102) to indicate to the vendor 12 that the line number belongs to a CLEC which is not billable by the system 10.
In a similar fashion, at operation 104 the processor module 54 checks to see if the OCN returned from the LIDB host 52 corresponds with a known CLEC or if the OCN corresponds with an OFFNET OCN and is therefore also unbillable by the system 10. If the line number corresponds to an OCN that is not billable, a return code 142 is generated by the processor module 54 and communicated to the vendor (see operation 106).
If the subscriber line number has passed the RAO and OCN checks and, accordingly, it appears that the number is billable, the processor module 54 may then check to see if a new NPA/NXX and OCN combination for this line number is guidable to the correct local Telco for billing (see operation 108). If the line number is not guidable, then the system 10 generates a code 141 at operation 110 which is communicated to the vendor to indicate that, even though the line number is billable, the proprietor of the system 10 is unable to guide the billing information to the new Telco for billing. Accordingly, the telephone number is in fact non-billable insofar as the system 10 is concerned and a decline status is therefore communicated to the vendor 12.
The abovementioned operations are carried out to ascertain whether or not the subscriber line can be billed for the goods and/or services requested. However, to enhance the accuracy or reliability of the system 10, further checks or verification may be conducted as described below.
In the event that the subscriber line number has passed or complied with the abovementioned checks, and has thus not yet been rejected, the system 10 may perform address verification procedures at operation 112. In particular, when the ANI is communicated to the API 14, location data is also provided which has been fed in by the user, e.g. via a computer terminal, orally over a telephone, or the like. The system 10 then interrogates an address verification database 44 to compare the address or location data (e.g. a ZIP code) supplied by the customer 11 with a reference address data as shown at operation 112. If, however, the address supplied by the customer 11 does not match with the address in the verification database 44 or, the addresses are not within a predefined range or area, the processor module 54, as shown at operation 114, generates codes 10 to 39 which are then communicated to the vendor 12 to indicate the level of likelihood that the caller (ANI) and the account owner are the same person.
During the address verification operation 112, the system 10 may interrogate a customer account record exchange (CARE) database 46 (which can be an on-site database which is regularly updated), to provide enhanced reliability. In particular, in one exemplary embodiment, the CARE database 46 or information site is one or more industry standard off-site databases which allow consumers to select or change their long distance service provider. Local Telcos forward specific customer information to the LEC associated with the subscriber. In one exemplary embodiment, the information communicated includes a new telephone number, a billing address, an installation date, a person or organization responsible for the account, or the like.
As shown at operation 116, the system 10 may interrogate the CARE database or information site and CARE data is then loaded into CLEC and new line databases to perform certain fraud and/or billing checks. The CARE information investigation may occur after a successful validation event. In one embodiment, once the system 10 has validated the subscriber line 17, the subscriber line number data is sent to a CARE database provider hosting the CARE database 46 to obtain the BNA (Billing Name and Address) and age of the account. In one exemplary embodiment, the information is returned within 48 hours and then processed. CARE records that are returned without BNA and NO ACCOUNT codes may be inserted into the CLEC database 26 for future reference. Accordingly, if the BTN is presented again at a later date, it will fail the CLEC check operation 74 (see FIG. 2).
The ANI watch database 48, which may include historical and adjusted information, may be used by the system 10 to determine if the account has previously been adjusted (see operation 116). In one exemplary embodiment, this operation includes ascertaining previous requests by the subscriber for credit, obtaining data on any written off amounts for charges that were billed to a bill page, or the like.
If adjustments have previously been made to the account associated with the subscriber line 17, the processor module 54 generates codes 1 to 5 (see operation 118) to indicate to the vendor 12 that the adjustments have previously been made. If no adjustments have been made, the processor module 54 checks to see whether or not the subscriber line number has a business line indicator as shown at operation 120. If the business line indicator is active, the system 10 generates a code 70 (see operation 122), which is communicated to the vendor 12 to advise that the line is a business line. Thereafter, as shown in operation 124, the processor module 54 may check to see if the subscriber line number has been in service for less than about 90 days and, if so, a return code 80 (see operation 126) is generated to advise the vendor 12 who may then selectively decide whether or not to conclude the transaction. A database of new numbers may be updated with the new number.
Thereafter, the system 10 may interrogate the ANI watch database 48 (see operation 128) to ascertain whether or not the area code of the line number has been changed or is scheduled to change. In one embodiment, this interrogation is for billing purposes only and is not used to decide upon the validity of the request. In this operation, the vendor 12 requesting the validation updates the billing file with the new area code number, and the processor module 54 generates a code 110 (see operation 130) to advise the vendor 12 of the scheduled change to the area code.
Once the line number has passed all the aforementioned checks, the system 10 may conclude that the subscriber line 17 is in fact a billable subscriber line based on the data obtained using ANI techniques and, accordingly, the transaction may be charged directly to the account of the subscriber. Accordingly, the system 10 then generates a code 000 (see operation 134) which is communicated to the vendor 12. The code 000 may define an approved status following both a billable line number inquiry as well as several fraud checks which are carried out by the fraud control module 132 (see FIG. 1). If the subscriber line number of the subscriber line 17 has passed the abovementioned checks and a return code 000 is generated, the procedure shown in FIG. 4 is carried out whereafter the process terminates at operation 136. Thus, operation 136 may define the end of the process during which the various checks have been conducted on the subscriber line 17 to assess whether or not it is a billable subscriber line that charges may be billed to. Operation 138 defines, in one embodiment, the last operation to which the process jumps when, at any point during the abovementioned process, the line number is found not to be billable (or a creditworthiness decision is requested) and the inquiry is accordingly terminated and the relevant code is communicated to the vendor 12.
In one exemplary embodiment, the abovementioned operations are executed in real-time. However, information sources that do not allow checks on the line number in real time may be carried out subsequently on the subscriber line number. In one embodiment, once the real-time evaluation is carried out and the return code 000 is communicated to the vendor 12, and should the vendor 12 decide to proceed with the transaction, transaction data is then returned to the system 10 by the vendor 12 for a pre-billing validation check or actual billing. During the actual billing, the system 10 may access an account folder of the subscriber line at the Telco and insert the charges due to the vendor 12 for its goods or services. As shown at operation 140, subscriber line numbers may be sent to the CARE database 46 to determine if the BNA is available at the local Telco. If the folder is not available, the local Telco sends the BNA and codes as to why the number is unavailable. If the BNA is found in the CARE database 46, the processor module 54 may then check to see whether or not the account was created within the last 90 days as shown at operation 142. If the account was not created within the last 90 days, then the business indicator is checked as shown at operation 144 and the process ends as previously shown at operation 146. If, however, the number was found in the CARE database 46, the account was created within the last 90 days, or has an active business indicator, then the system 10 may generate the appropriate codes, which are communicated to vendor 12, and the process terminates as shown at operation 148.
The above process has been described in terms of modified codes set out in Table 2 but, it is to be appreciated, that any other defined set of corresponding codes may be provided so long as the codes are mapped onto, or generated in response to, any one or more of the industry standard LIDB codes.
A summary of the codes generated by one exemplary embodiment of the system 10 during execution of the validation process is provided in Table 1 below.







TABLE 1





Modified codes generated during the BTN Validation Process.
















Code Generated and



ref to flow charts
Description of code





Return Code 121
Indicates inability to proceed with validation; returned to requestor


See operation 64
Checks if ANI captured and BTN provided match (not required in all



scenarios)


Return Code 120
Indicates caller and # (line number) owner are not the same person;



returned to requestor


See operation 68
A defined Threshold limits the number of attempts on that # within a



certain timeframe


Return Code 60
Indicates # may not be granted service; returned to requestor.


See operation 71
Checks the NPA/NXX and OCN to those in the OFFNET.



OFFNET = NPA/NXX and OCN combinations where proprietor



of the system 10 does not have a Billing and Collections agreement to



bill into the Telco's' bill page.


Return Code 130-133
Indicates that NPA/NXX & OCN for that Number are not billable;



returned to requestor


See operation 74
Checks the line number to see if found in known CLEC table. These



are numbers that are known to have ported to a CLEC. Proprietor is



unable to route these # to the correct billing entities.


Return code 140
Indicates # not billable for CLEC; returned to requestor.


See operation 78
Checks line # to see if owner has requested a 4250 Billing block. This



block prevents monthly recurring (4250) charges from being billed to



that line #.


Return Code 150
Indicates that billing to a particular subscriber line has been blocked;



returned to requestor.


See operation 82
Checks line number for inclusion in the Block and Cancel database.



This database includes requests from line # owners, agencies,



businesses etc that have requested that service be cancelled and or



blocked from further billing.


Return Code 160-161
Indicates number found in Block and Cancel and is not billable;



returned to requestor.


See operation 86
Checks line # for unbillable history. Unbillables are #s where tried



to bill charges previously and have been returned as unbillable.


Return Code 170
Indicates # has unbilled before and is still considered unbillable;



returned to requestor.


See operation 90
If # not found in Unbillable, then routed to LIDB for info.





ITEM
Description





See operation 94
Identifies info returned from LIDB re. that line #; Response Code = status



about that # as a call termination point. OCN = Operating



Company # = the local Telco that owns that #.



RAO = Regional Accounting Office = the office of the Telco that



is responsible from a $ flow standpoint for that #.


See operation 96
Checks the validity of the LIDB code returned for the number as a Billable



#. This is where the mapping of the LIDB codes to the proprietor



validation codes happens.


Return Code 180-999
Indicates the mappings of the LIDB codes to the proprietor Val reply



codes. Each of these indicate a non-billable #; returned to requestor.


See operation
Checks if RAO returned is an RAO that is not billable.


100



Return Code 143
Indicates that the # belongs to a CLEC and is unbillable; returned to



requestor.


See operation
Checks if OCN returned from LIDB is a known CLEC or OFFNET OCN


104
and therefore unbillable.


Return code 142
Indicates that the new OCN is not billable; returned to requestor.


See operation
Checks to see if new NPA/NXX & OCN combination for # is guidable to


108
the correct local Telco for billing.


Return code 141
Indicates that even though the # is billable, the system is



unable to guide to the new Telco for billing; unguidable = unbillable;



# returned to requestor.







The operations to indicate if # is billable have been completed.


The next operations provide additional information about the # for the requestor e.g. to decide if


and how much credit to extend for services. They also provide additional billing information.








See operation
Provides address verification (if required). Matches # to address to


112
determine likelihood of person dialing to the person that owns the account



at local Telco.


Return Code 10-39
Indicates the level likelihood that the caller (ANI) and acct owner are the



same. Returned to requestor.


See operation
Checks to see if # has had adjustment activity previously. This includes


116
request for credit, written off for charges that billed to a bill page.



Requestor makes credit decision based on #s history of credits,



adjustments, write offs.


Return Code 1-5
Indicates the type and source of adjustment to charges to that #. Returned



to requestor.


See operation
Checks to see if the # has a business line indicator. Requestor decides if


120
would like to extend service or not.


Return Code 70
Indicates that the # is identified as a business.


See operation
Checks to see if the # has been in service less than 90 days. Requestor


124
makes a decision about how much service to offer # without much



payment history.


Return Code 80
Indicates that the # has been in service less than 90 days.


See operation
Checks if the Area Code of the # has been scheduled to change. This is for


128
billing information purposes only. Requestor updates billing filed with



new number.


Return Code 110
Indicates Area Code has been scheduled to change. New number is



appended to end of record.


See operation
If the number passes all the previous checks, then 000 code is returned to


134
requestor. The Validation is complete for this request.


See operation
End of validation for numbers that did not pass or were found in other


138
checks.







END OF REAL TIME VALIDATION EVENT


Information sources that do not allow checks on the # in Real-time (r-t), happen on # that was


returned as 000 after the r-t validation event has completed. The #s are loaded into the


appropriate databases. This information will be provided once the # is returned for billing.








Operations 140, 142, 144
Indicates path for those #s returned with a 000



code.


See operation 140
#s are sent to CARE source to determine if BNA



(billing Name and Address) available at local Telco.



Telco sends BNA and codes as to why unavailable.


CLEC
#s that are returned with codes that indicate the #



has moved to a CLEC from the local Telco are



loaded into the CLEC table.


See operation 142
#s are sent to the CARE source to determine if the



account has been crested within the last 90 days.



The response codes indicate this condition.


New within 90
#s that are returned with codes that indicate this



condition are loaded into the NEW table.


See operation 144
#s are sent to a Business source. This source



identifies which numbers belong to businesses.


Biz table
Numbers that are indicated as being line #s that



belong to businesses are loaded in this table.









Table 2 (see below) provides the various actions, which are executed in response to a modified validity code. The table provides an exemplary description and explanation of each code. Return codes 001 to 179 relate to failure codes, which are generated by the system 10 prior to investigation of the LIDB host 52. Return codes 180 to 451 are generated during the LIDB code checks. In the event of the subscriber line 17 failing the checks carried out on it, the system 10 provides optional use of a credit card and, accordingly, Table 2 sets out codes which the system 10 generates in response to executing a standard credit card enquiry for a particular transaction. If the system 10, which may be defined by a server and associated databases, is down, codes 994 to 999 are generated and communicated to the vendor.







TABLE 2







Validation & BNA Reply Codes










Code
Action
DESCRIPTION
EXPLANATION










BILLABLE CODES










000
Approved
Billable; was not found during
Passed all billing and fraud control checks




fraud control checks








FRAUD CONTROL CODES (performed after billable check)


ANI WATCH (adjustments to bill)










001
Verify
Billable; found in ANI WATCH -
Passed all billable checks; but ANI had




CLIENT source all
been adjusted previously at vendor's,





Client's or Telco's request for your Client #


002
Verify
Billable; ANI WATCH - CLIENT
Passed all billable checks; but ANI had




source Client
been adjusted previously at Client's





request for your Client #


003
Verify
Billable; ANI WATCH - CLIENT
Passed all billable checks; but ANI had




source Telco or Vendor
been adjusted previously at vendor's or





Telco's request for your Client #


004
Verify
Billable; found in ANI WATCH -
Passed all billable checks; ANI had been




GLOBAL
adjusted previously at vendor's, Client's or





Telco's request for all Client ids


005
Verify
Billable; found in ANI WATCH -
Passed all billable checks; ANI had been




PRODUCT
adjusted previously at vendor's, Client's or





Telco's request for same product type







ZIP VERIFICATION










010
Verify
Billable; Unable to match ZIP
Passed all billable checks; unable to find




invalid
this Zip code for this NPA/NXX-


011
Verify
Billable; ZIP does not match
Passed all billable checks; Zip code does





not match this NPA/NXX


012
Verify
Billable; ZIP matches to same
Passed all billable checks; Zip code




Metropolitan area
matches to same Metropolitan area as





NPA NXX.







ADDRESS VERIFICATION


Note: The result of an AVS check does not mean that the transaction is declined. This information may be


advice only. The system may compare the AVS data with billing information for the buyer and pass the


results of the comparison to the merchant.










020
Verify
Billable; BNA match not found
Passed all billable checks; no BNA match





found for ANI


021
Verify
Billable; Unable to verify BNA
Passed all billable checks; unable to verify




invalid
BNA to ANI info sent


022
Verify
Billable; with zip-Match, plus4-
Passed all billable checks; BNA Zip code +4




Match, locale-Match
& locale (street address) matches info





sent for ANI, Name does not match


023
Verify
Billable; with zip-Match, plus4-
Passed all billable checks; BNA Zip code +4




Match, NoMatch-locale
matches info sent for ANI but locale





(street address) does not match


024
Verify
Billable; zip-Match, NoMatch-
Passed all billable checks; BNA Zip code &




plus4, locale-Match
locale (street address) matches info sent for





ANI but +4 does not match


025
Verify
Billable; zip-Match, NoMatch-
Passed all billable checks; BNA Zip code




plus4, NoMatch-locale
matches info sent for ANI but locale (street





address) & +4 does not match


026
Verify
Billable; NoMatch-zip, plus4-
Passed all billable checks; BNA +4 and




Match, locale-Match
locale (street address) matches info sent for





ANI but Zip does not match


027
Verify
Billable; NoMatch-zip, plus4-
Passed all billable checks; BNA +4 matches




Match, NoMatch-locale
info sent for ANI but locale (street address)





and Zip does not match


028
Verify
Billable; NoMatch-zip, NoMatch-
Passed all billable checks; BNA locale




plus4, locale-Match
(street address) matches info sent for ANI





but ZIP and +4 does not match


029
Verify
Billable; NoMatch-zip, NoMatch-
Passed all billable checks; BNA does not




plus4, NoMatch-locale
match zip, +4 or locale (street address)





sent for ANI


030
Good
Address & Zip Match



031
Verify
Address Match, Zip No Match



032
Verify
Address Match, Zip Service





Unavailable



033
Verify
Address No Match, Zip Match



034
Verify
Address No Match, Zip No Match



035
Verify
Address No Match, Zip Service





Unavailable



036
Verify
Address Service Unavailable, Zip





Match



037
Verify
Address Service Unavailable, Zip





No Match



038
Verify
Address Service Unavailable, Zip





Service Unavailable








AREA CODE CHANGE INDICATOR










110
Update
Indicates there has been an area
Code is sent in addition to the validation




code change for this NPA/NXX
response codes. New phone number is





appended to record. Provided to update





the account with the correct BTN.







MISCELLANEOUS










120
Verify
BTN and ANI do not match
For use where BTN and ANI are passed





and do not match.


121
Verify
BTN or ANI are missing from
For use where BTN and ANI is missing




record
from record







UNBILLABLE CODES


OFFNET










130
Unbillable
NPA/NXX found in OFFNET -
Area code/exchange (NPA/NXX)




GLOBAL
combination resides in OFFNET DB.





OFFNET is a territory where the LEC





(Local Exchange Carrier) is unable to





provide 3rd party presentation in to its





envelope.


131
Unbillable
NPA/NXX found in OFFNET -
Area code/exchange (NPA/NXX)




CLIENT SPECIFIC
combination resides in OFFNET DB





specific for this Client id.


132
Unbillable
NPA/NXX found in OFFNET -
Area code/exchange (NPA/NXX)




PRODUCT
combination resides in OFFNET DB





specific for this product type.


133
Unbillable
NPA/NXX NOT VALID
Area code/exchange is not a valid area





code exchange







CLEC (CLECs are unable to provide 3rd party bill presentation in their envelopes.)










140
Unbillable
Line number (NPA/NXX-XXX) in
BTN has been ported to a CLEC




CLEC Territory
(competitive local exchange carrier).


141
Unbillable
NPA/NXX not ON NET
BTN has been ported to a CLEC





(competitive local exchange carrier) and is





not billable.


142
Unbillable
Line number OCN in CLEC OCN
Operating Company number for this BTN




table
was found on CLEC OCN table. The





number is not billable.


143
Unbillable
Line number RAO in CLEC RAO
Regional Accounting Office number for




table
this BTN was found on CLEC RAO table.





This BTN is not billable.







42 BLOCK (4250s Only)










150
Unbillable
Line Number has a block for 4250
Consumer has requested a block for all




records
MRCs (monthly recurring charges) from





being billed to this phone number.







BLOCK & CANCEL










160
Unbillable
GLOBAL - Line number has been
Consumer requested block to stop all




blocked to stop all charges.
charges from being billed to this number.


161
Unbillable
CLIENT - Line number has a
Consumer requested a block to stop




block to stop all charges from this
charges from being billed or to cancel




Client id.
service for this phone number from this





Client id.







UNBILLS










170
Unbillable
Line number is Unbillable.
Line number has been returned from the





Local Telephone companies within the last





6 months as unable to be billed.







LIDB FAILURE










180
Unbillable
Line number failed LIDB check -
Line Number has been returned from




GENERAL
LIDB as unbillable.


181
Unbillable
Vacant NPA NXX
No working line #s in NPA NXX


182
Unbillable
No Incoming Calls
Line # cannot accept incoming calls


183
Unbillable
Denied ANI
Auto decline of all attempts from this ANI


184
Unbillable
Calling Card block
Auto decline of Calling Card number


185
Unbillable
Collect Call Block
Auto decline of Collect calls to this number


186
Unbillable
Third Party Call Block
Auto decline all Third Party billed calls to





this number


187
Unbillable
Credit Card Block
Auto decline of charges billed to Credit





Card


188
Unbillable
Group Number Block
Auto decline of attempts from this group.


189
Unbillable
Audiotext Bock
Number does not allow audiotext calls.


190
Unbillable
Excessive Calling Card PIN hits
Threshold for calling card attempts has





been exceeded.


191
Unbillable
Line Number Block
Auto decline of all charges to this number


200
Unbillable
Excessive Use - BTN
BTN has exceeded threshold


201
Unbillable
Excessive Use DN
DN has exceeded threshold


202
Unbillable
Excessive Use - ANI
ANI has exceeded threshold


203
Unbillable
Excessive USE - Calling Card Pin
Calling Card Pin has exceeded threshold


220
Unbillable
Feature Group A
Local telephone switch is Feature Group A


221
Unbillable
PBX line
Line # is a PBX line


222
Unbillable
WATS line
Line # is a WATS line


223
Unbillable
Hotel/Motel Auto Quote w/ tax
Hotel/Motel Auto Quote w/ tax


224
Unbillable
Hotel/Motel Auto quote w/o tax
Hotel/Motel Auto quote w/o tax


225
Unbillable
Dormitory line
Line # belongs to a dorm


226
Unbillable
Hospital line
Line number belongs to a hospital


227
Unbillable
Centrex line
Line number belongs to CENTREX


228
Unbillable
Alternate Service Provider
Line # belongs to an alternate service





provider


229
Unbillable
POTS line (collect or third party
Line # is plain old telephone service lines




calls)
for business or residential


230
Unbillable
Pager #
Line number belongs to pager


231
Unbillable
PCS/Mobile/Cellular #
Line number belongs to a wireless





provider


240
Unbillable
Line was disconnected w/o
Line # was disconnected w/o a referral




referral
number


241
Unbillable
Line Number changing
Line is not connected yet.


242
Unbillable
not used



243
Unbillable
DISCO w/o referral
Line number has been removed from





service w/o referral


244
Unbillable
Temp DISCO
Line number has been removed from





service temporarily


245
Unbillable
DISCO with referral
Line number has been disconnected w/





referral or Operator takes calls


246
Unbillable
Temp DISCO w/ referral
Line number has been removed from





service temporarily w/ referral


250
Unbillable
POTS line rating on rate plan
POTS line is on a rate plan for business or





residential message rate 1 or 2 or flat rate


300
Unbillable
Public - Incompatible interface
Public phone with incompatible interface


301
Unbillable
LEC Public Standard PreP OT
LEC Public phone standard interface;





prepay overtime


302
Unbillable
LEC Public Alternate
LEC Public phone alternate interface;





functions controlled by set


303
Unbillable
LEC Public Standard PP OT
LEC Public phone standard interface;





postpay overtime


304
Unbillable
IC Public
IC Public Phone - Alternate Interface


305
Unbillable
IC Public Standard
IC Public Phone - Standard Interface


306
Unbillable
LEC Public Special - PP OT
LEC Public Phone- Special billing post





paid OT


307
Unbillable
LEC Public Special - PreP OT
LEC Public Phone - Special Billing; Pre pay





OT


308
Unbillable
LEC Semi Public
LEC Semi Public Phone


309
Unbillable
LEC Semi Public Phone (no
LEC Semi Public Phone does not allow




collect or 3rd Party calls)
collect or 3rd party calls to this number


310
Unbillable
LEC Prepaid Card
LEC Prepaid Card Telecommunications





station


311
Unbillable
IPP (fka COCOT) Standard
Payphone Standard




interface



312
Unbillable
IPP (fka COCOT) Alternate
Payphone - Alternate




interface



313
Unbillable
Coinless (non IPP fka COCOT)
Coinless Pay phone


314
Unbillable
Coinless (IPP fka COCOT)
Coinless payphone


315
Unbillable
Prison (non IPP fka COCOT)
Prison payphone


316
Unbillable
Prison (IPP fka COCOT)
Prison Payphone


450
Unbillable
BNS: Voice Quote - without tax
Charge quotes without tax


451
Unbillable
BNS: Voice Quote - with tax
Charge quotes with tax







CREDIT CARD RESPONSE CODES










000
Approved
Credit card approved



501
Decline/Error
User authentication Failed



502
Decline/Error
Invalid tender
Your merchant bank account does not





support the following credit card type that





was submitted


503
Decline/Error
Invalid transaction type
Transaction type is not appropriate for this





transaction. For example, you cannot





credit an authorization-only transaction.


504
Decline/Error
Invalid amount



505
Decline/Error
Invalid merchant information
Processor does not recognize your





merchant account information. Contact





your bank account acquirer to resolve this





problem.


512
Decline/Error
Declined
Please check the credit card number and





transaction information to make sure they





were entered correctly. If this does not





resolve the problem, have the customer





call the credit card issuer to resolve.


513
Decline/Error
Referral
Transaction was declined but could be





approved with a verbal authorization from





the bank that issued the card. Submit a





manual Voice Authorization transaction





and enter the verbal auth code


519
Decline/Error
Original transaction ID not found
The transaction ID you entered for this





transaction is not valid.


520
Decline/Error
Cannot find the customer





reference number



522
Decline/Error
Invalid ABA number



523
Decline/Error
Invalid account number
Please check credit card number and re-





submit.


530
Decline/Error
Account Lookup information
Account provided found in system,




Mismatch
however, unique key provided does not





match unique key in system.


531
Decline/Error
Account does not exist
Account provided not found in system


542
Decline/Error
Invalid expiration date
Please check and re-submit


525
Decline/Error
Transaction type not mapped to





this host



526
Decline/Error
Invalid vendor account



527
Decline/Error
Insufficient partner permissions



528
Decline/Error
Insufficient user permissions



550
Decline/Error
Insufficient funds available



551
Decline/Error
Invalid transaction returned from





host



552
Decline/Error
Processor not available



553
Decline/Error
Credit error
Please make sure you have not already





credited this transaction, or that this





transaction ID is for a creditable





transaction. (For example, you cannot





credit an authorization.)


554
Decline/Error
Void error
Please make sure the transaction ID





entered has not already been voided. If





not, then look at the Transaction Detail





screen for this transaction to see if it has





settled. (The Batch field will be set to a





number greater than zero if the transaction





has been settled). If the transaction has





already settled, your only recourse is a





reversal (credit a payment or submit a





payment for a credit).


555
Decline/Error
Capture error
Only authorization transactions can be





captured


556
Decline/Error
Failed AVS check
Address and Zip code do not match


557
Decline/Error
Cannot exceed sales cap
For ACH transactions only


558
Decline/Error
CVV2 Mismatch



800
Unbillable
LNP Only Look-Up, number was
LNP Only Look-Up, number was found in the




found
LNP GTT database as ported.


801
Unbillable
LNP Only Look-Up, number was not
LNP Only Look-Up, number was not found in




found
the LNP GTT database, not ported.


802
Unbillable
LNP Only Look-Up, the NPA/NXX is
LNP Only Look-Up, the NPNXX is not a




not a portable range.
portable range.







SYSTEM DOWN










994
Resubmit
Message Format Error
Message received in invalid or





unrecognized format.


995
Resubmit
Time out
Session timed out.


996
Resubmit
Connection Failure
Unable to connect.


997
Resubmit
Subsystem Failure
Subsystem, such as LIDB, Credit Card, etc,





not available.


998
Resubmit
Network Failure
Network Not Available


999
Resubmit
System Down
System Unavailable









As mentioned above, the system 10 may translate the LIDB codes into modified verification codes as shown in Table 2. These modified validity codes are then mapped or translated. Table 3 below provides a list of the modified validity codes which are generated following the mapping carried out by the processor module 54 to translate LIDB codes to the modified verification codes set out in Table 1.







TABLE 3







LIDB/LNP SOURCE TRANSLATIONS for ISP:













Resp.
Resp.







Type
Code

LIDB

rtfc



In
In
ACTION
ADMIN?
Description
type
Code Out





APP
000
Approved

Calling card has an Unrestricted PIN.
G1
000


APP
001
Approved

Calling card has a Restricted PIN. The
g1
000






switch must verify that the DNI matches the








first 10 digits of the calling card before








placing the call.




APP
004
Approved

Collect call - No verification is required.
G1
000


APP
005
Approved

Third-party call - No verification is
G1
000






required.




APP
006
Approved

There is a system error.
S
999


APP
008
Approved

Communications Link Tests “Good.”
S
999


APP
010
Approved

Commercial credit card is approved and the
G1
000






zip code matches, if the zip code was sent.




APP
011
Approved
Y
Bill-to number has an Admin. Override to
G1
000






automatically approve the transaction.








(Admin. Reply)




APP
012
Approved

Originating number (ANI) has an Admin.
G1
000






Override to automatically approve the








transaction. (Admin. Reply)




APP
013
Approved

Dialed number (DNI) has an Admin
G1
000






Override to automatically approve the








transaction. (Admin. Reply)




APP
014
Approved

Group number has an Admin. Override to
G1
000






automatically approve the transaction.








(Admin. Reply)




APP
015
Approved

Commercial credit card is approved but the
CC
500






zip code check is unavailable.




APP
016
Approved

Commercial credit card is approved but the
CC
501






zip code check is unavailable. Retry later.




APP
017
Approved

Commercial credit card is approved but the
CC
502






zip code check is not supported.




APP
018
Approved

Commercial credit card is approved and the
CC
503






address matches but the zip code does not








match.




APP
019
Approved

Commercial credit card is approved and the
CC
504






address and the zip code match.




APP
020
Success

LNP Only Look-Up, number was found in
LNP
800






the LNP GTT database as ported.




APP
021
Success

LNP Only Look-Up, number was not found
LNP
801






in the LNP GTT database, not ported.




CON
050
Verify

Collect call number has no block. Verify
o1
000






acceptance of the charge.




CON
051
Verify

Third-party call number has no block.
O1
000






Verify acceptance of the charge.




CON
053
Denied

Unable to authorize, Automatic Code
S
999






Gapping is in effect at the LIDB. Every








third query is dropped by the LIDB.




CON
054
Denied
Y
Excessive Use - The bill-to number exceeded
G3
000






the high limit threshold in the Admin. fraud








control system. (Admin. Reply)




CON
055
Denied
Y
Excessive Bad PIN Attempts - The threshold
O2
000






for bad PIN attempts for the calling card








was exceeded in the Admin. fraud control








system. (Admin. Reply) This is the same as








reply code 309.




CON
060
Conditional
Y
Low Limit Warning - The bill-to number
G3
000






exceeded the low limit threshold in the








Admin. fraud control system. (Admin.








Reply)




CON
061
Conditional
Y
Low Limit Warning - The dialed number
G3
000






exceeded the low limit threshold in the








Admin. fraud control system. (Admin.








Reply)




CON
062
Denied
Y
Excessive Use Dialed - The dialed number
G3
000






exceeded the high limit threshold in the








Admin. fraud control system. (Admin.








Reply)




CON
063
Conditional
Y
No Host Still Billable - There is no LIDB
G2
180






check available, but the Customer has a








billing agreement with this LEC. (Admin.








Reply)




CON
064
Approved
Y
Commercial credit card is approved but the
CC
505






zip code and the address do not match.




CON
065
Conditional
Y
Low Limit Warning - The ANI exceeded the
G3
000






low limit threshold in the Admin. fraud








control system. (Admin. Reply)




CON
066
Denied
Y
Excessive Use ANI - The ANI exceeded the
G3
000






high threshold in the Admin. fraud control








system. (Admin. Reply)




CON
070
Approved

Calling card has no service denial in the
G1
000






Card Service Denial Indicator field. Calling








card calls may be billed to this card number.




CON
071
Approved

Calling card has no service denial in the Pin
G1
000






Service Denial Indicator field. Calling card








calls may be billed to this card number.




CON
080
Verify

Collect calls - Accept intralata, Reject
O1
000






interlata collect calls. Recommend verify








acceptance of the charge.




CON
081
Verify

Third-party calls - Accept intralata, reject
O1
000






interlata third-party calls. Recommend








verify acceptance of the charge.




CON
082
Verify

Collect calls - Accept intralata, verify
O1
000






interlata collect calls. Recommend verify








acceptance of the charge.




CON
083
Verify

Third-party calls - Verify intralata, reject
O1
000






interlata third-party calls. Recommend








Verify acceptance of the charge.




CON
084
Verify

Collect call - Verify acceptance of the charge
O1
000






by an Operator.




CON
085
Verify

Third-party call - Verify acceptance of the
O1
000






charge by an Operator.




CON
086
Verify

Collect call - Accept intralata charge, verify
O1
000






interlata charge with Operator.




CON
087
Verify

Third-party calls - Verify intralata charge
O1
000






with operator, reject interlata charge with








Operator.




CON
088
Verify

Collect Calls: POTS Line
G5
000






(Business/Residential)




CON
089
Verify

Third-Party Calls: POTS Line
G5
000






(Business/Residential)




CON
090
Verify

BNS: Centrex Line, Collect calls - Some
G4
000






LECs allow billing to this type of line,








others do not. Verify Acceptance.




CON
091
Verify

BNS: POTS Line - Residential - Message rate 1
G9
000


CON
092
Verify

BNS: POTS Line - Residential - Message rate 2
G9
000


CON
093
Verify

BNS: POTS Line - Business - flat rate
G9
000


CON
094
Verify

BNS: POTS Line - Business - message rate 1
G9
000


CON
095
Verify

BNS: POTS Line - Business - message rate 2
G9
000


CON
096
Verify

BNS: POTS Line - Residential - flat rate
G9
000


DENY
100
Denied

Message Format Error Message
S
994


DENY
100
Denied

Message Format Error- Date format
S
994


DENY
100
Denied

Message Format Error-Header Message
S
994






Error




DENY
100
Denied

Message Format Error- Merchant ID Error
S
994


DENY
100
Denied

Message Format Error-No End of Header
S
994






Indicator




DENY
100
Denied

Message Format Error-Header Data
S
994






Indicator, did not contain data in each field








of the message That was represented by the








message text map field




DENY
100
Denied

Message Format Error-PIN not numeric
S
994


DENY
100
Denied

Message Format Error-Terminating Error
S
994






(commercial credit card only




DENY
100
Denied

Message Format Error-Terminating
S
994






Number not numeric




DENY
100
Denied

Message Format Error-Originating Number
S
994






not Numeric




DENY
100
Denied

Message Format Error-Charge Number not
S
994






Numeric




DENY
100
Denied

Message Format Error-No End Header
S
994






Indicator




DENY
101
Denied

Message Format Error Invalid
S
994






Customer/Terminal ID Number




DENY
102
Denied

Message Format Error Invalid Message
S
994






Type




DENY
103
Denied

Message Format Error Invalid Transaction
S
994






Type




DENY
104
Denied

Message Format Error Invalid Sequence
S
994






Number




DENY
105
Denied

Message Format Error Invalid Data
S
994






Indicator




DENY
105
Denied

Message Format Error- Header Data
S
994






Indicator




DENY
107
Denied

Bad PIN format. PINs must be equal to or
S
994






higher than 2000.




DENY
200
Denied

Calling card blocked, missing customer
S
994






record - There is no record of that calling








card number in the database.




DENY
201
Denied

BNS, missing customer record - There is no
S
994






record of that line number in the database.




DENY
202
Denied

Missing BNG - There is no record of that
S
994






NPANXX in the database.




DENY
203
Denied

Non-billable NXX - DPC table failure. The
G2
180






NPANXX does not have routing or allow








billing, e.g. cellular. (LIDB or Admin.








Reply)




DENY
204
Denied

Calling card blocked, screened data - A
O2
000






screening mechanism is in place at the LIDB








that does not allow charges to this calling








card.




DENY
205
Denied

Protocol converter problem - There is a
S
999






problem with the SS7 protocol converter.




DENY
206
Denied

BNS & No Calling Card Calls - No Host,
o2
180






Nonparticipating Group. This NPANXX








exists but there is no LIDB host. (LIDB or








Admin. Reply)




DENY
207
Denied

LIDB Access Denied because no queries
S
999






should be sent to this LIDB destination.








(Admin. Reply)




DENY
208
Denied

Calling card blocked, Screened Data on PIN
O2
000






(Pin Service Denial Indicator) - A screening








mechanism is in place at the LIDB that does








not allow charges to this PIN.




DENY
209
Denied

External SS7 Problem - There is a format
S
999






problem in the SS7 network




DENY
210
Denied

Calling card blocked, screened data - A
O2
000






screening mechanism is in place at the LIDB








that does not allow charges to this calling








card.




DENY
211
Denied

Calling card is blocked because it has a bad
O2
000






PIN or the PIN does not match database








information.




DENY
211
Denied

Unexpected Data Value, Calling card
O2
000






blocked, Bad PIN - This means a bad PIN








was used or there is no PIN on file.




DENY
212
Denied

Calling card blocked, PIN Excessive Use at
G3
000






LIDB Owner. - The PIN exceeded the high








threshold in the LIDB fraud control system




DENY
213
Denied

Vacant BNG - There are no working lines in
G2
181






the NPANXX.




DENY
214
Denied

No Collect calls - Collect calls are not
O2
000






allowed to this line number.




DENY
215
Denied

No Third-party calls - Third-party calls are
O2
000






not allowed to this line number




DENY
216
Denied

BNS: LEC Public - Standard Interface
G10
303






(functions controlled by the network) -








Postpay Overtime




DENY
217
Denied

BNS: Coinless (non IPP fka COCOT)
G10
313


DENY
218
Denied

BNS: semi-public phone - No Collect or
G10
309






Third-party calls are allowed to this line








number.




DENY
219
Denied

Spare - This LIDB response is not in use at
AV
180






this time.




DENY
220
Denied

Time-out, No response from Host - A
S
180






response was not received from the host








database within 4 seconds for a Telco query








or 12 seconds for a Bank card query. (LIDB








or Admin. Reply)




DENY
221
Denied

BNS Data unavailable, Error Message, No
S
180






Host - No collect or third-party calls should








be allowed to this line number.




DENY
222
Denied

Calling card Data unavailable, Error
S
180






Message, No Host - No calling card calls








should be allowed to this line number.




DENY
223
Denied

BNS & Calling card, screened response
O2
000






LIDB - A screening mechanism is in place at








the LIDB that does not allow charges to this








account number.




DENY
224
Denied

LIDB Misroute - The query was routed to
S
999






the wrong LIDB.




DENY
225
Denied

Reject, Reroute - The LIDB could not read
S
994






the format of the query.




DENY
226
Denied

Unexpected Component - The LIDB cannot
S
994






interpret the format of the query.




DENY
227
Denied

UDTS, SS7 Network problem - There is an
S
999






SS7 network problem.




DENY
228
Denied

BNS: Personal Communication Service
G8
231






(PCS)




DENY
229
Denied

BNS: Mobile
G8
231


DENY
230
Denied

Not Billable - The Customer does not have a
G2
180






billing arrangement with the LEC for this








NPANXX (OCN On-Net Screening).




DENY
231
Denied

BNS: LEC Prepaid Telecommunications
G10
310






Card Station.




DENY
232
Denied

Feature Group A (FGA)
G4
000


DENY
233
Denied

BNS: LEC Public - Alternate Interface
G10
302






(functions controlled by set)




DENY
234
Denied

BNS: LEC Public - Special Billing - Postpay
G10
306






Overtime (functions controlled by the








network)




DENY
235
Denied

BNS: LEC Public - Special Billing - Prepay
G10
307






Overtime (functions controlled by the








network)




DENY
236
Denied

BNS: Public - Incompatible Network
G10
300






Interface (interface other than standard or








alternate)




DENY
237
Denied

BNS: IC Public - Alternate Interface
G10
304


DENY
238
Denied

BNS: IPP (fka COCOT) - Standard Interface

311


DENY
239
Denied

BNS: Pager
G8
230


DENY
241
Denied

General, Reject - The LIDB could not read
S
994






the format of the query.




DENY
242
Denied

Invoke, Reject - The LIDB could not read the
S
994






format of the query.




DENY
243
Denied

Return Result, Reject - The LIDB could not
S
994






read the format of the query.




DENY
244
Denied

Return Error, Reject - The LIDB could not
S
994






read the format of the query.




DENY
245
Denied

Transaction Portion, Reject - The LIDB
S
994






could not read the format of the query.




DENY
246
Denied

BNS: Vacant Number - There is no line
G2
180






number assigned.




DENY
247
Denied

BNS: Disconnected without referral - The
G6
240






line number was disconnected with no








referral to a new line number.




DENY
248
Denied

BNS: Changed to non-published number -
o5
000






The line number was changed to a non-








published number.




DENY
250
Denied

No Collect Calls, Screened Data - A
O2
000






screening mechanism is in place at the LIDB








that does not allow charges to this line








number.




DENY
251
Denied

No Third-party calls, Screened Data - A
O2
000






screening mechanism is in place at the LIDB








that does not allow charges to this line








number.




DENY
252
Denied

BNS: Screened Data - A screening
G7
191






mechanism is in place at the LIDB that does








not allow charges to this line number.




DENY
253
Denied

BNS: Screened Data - A screening
G7
191






mechanism is in place at the LIDB that does








not allow charges to this line number.




DENY
254
Denied

BNS & No Calling Card, Unavailable
O2
411






network resource - This line or card number








is not in the database.




DENY
255
Denied

BNS: Screened Data - A screening
G7
191






mechanism is in place at the LIDB that does








not allow charges to this line number.




DENY
256
Denied

BNS: Being changed - The line number is
G6
241






being changed; it may not yet be connected.




DENY
257
Denied

BNS: May not yet be connected - The line
G6
243






number may be new; it may not yet be








connected.




DENY
258
Denied

BNS: Temporarily disconnected - The line
G6
244






number is temporarily disconnected.




DENY
259
Denied

BNS: Disconnected, calls being taken by
G6
245






operator - The line number is temporarily








disconnected, the operator is taking calls.




DENY
260
Denied

BNS: Temporarily removed from service -
G6
244






The line number is temporally removed








from service.




DENY
261
Denied

BNS: Not in service for incoming calls - This
G2
182






line number cannot accept incoming calls.




DENY
262
Denied

BNS: Temporarily disconnected at customer
G6
245






request without referral - The line number








is temporarily disconnected at the request








of the customer without referral.




DENY
263
Denied

BNS: Temporarily disconnected at customer
G6
246






request with referral - The line number is








temporarily disconnected at the request of








the customer with referral.




DENY
264
Denied

BNS: Changed with referral to new number -
o5
000






The line number was changed. A referral








to another line number is in place.




DENY
265
Denied

Calling card blocked, PIN Nonpayment -
O2
000






The calling card is blocked because of








nonpayment.




DENY
266
Denied

Calling card blocked, Service Restriction on
O2
000






PIN - There is a service restriction on this








PIN.




DENY
267
Denied

Calling card blocked, no PINs assigned.
O2
000






There is no PIN assigned to this calling








card/line number.




DENY
268
Denied

Calling card blocked, service denial - There
O2
000






is a service restriction on this calling card.




DENY
269
Denied

Calling Card - The calling card is a CIID
O2
000






(proprietary card) for which there is no








host.




DENY
270
Denied

BNS: Unexpected Data Value - No Collect
S
994






or Third-Party Calls are allowed.




DENY
272
Denied

LIDB/CCC Response Time-out - A response
S
180






was not received from the host database








within 4 seconds for a Telco query and 12








seconds for a Bank query.




DENY
273
Denied

No Collect Calls at Customer Request - The
O2
000






end user customer requested the block for








collect calls to this line number.




DENY
274
Denied

BNS & No Calling Card Calls: Screened
O2
000






data.




DENY
275
Denied

BNS: Hotel/Motel Auto Quote - with tax
G4
000


DENY
276
Denied

BNS: Dormitory Line
G4
225


DENY
277
Denied

BNS: Hotel/Motel Auto Quote - without tax
G4
000


DENY
278
Denied

BNS: PBX Line
G4
221


DENY
279
Denied

BNS: Prison (IPP fka COCOT)
G10
316


DENY
280
Denied

BNS: WATS Line
G4
222


DENY
281
Denied

No Third-party calls at Customer Request -
O2
000






The end user customer requested the block








for third-party calls to this line number.




DENY
282
Denied

BNS: LEC Public - Standard interface -
G10
301






Prepay Overtime




DENY
283
Denied

BNS: Coinless (IPP fka COCOT)
G10
314


DENY
284
Denied

BNS: IC Public - Standard Interface
G10
305


DENY
285
Denied

BNS: Voice Quote - without tax
o6
450


DENY
286
Denied

BNS: Voice Quote - with tax
o6
451


DENY
287
Denied

BNS: IPP (fka COCOT) - Alternate Interface
G10
312


DENY
288
Denied

BNS: Hospital
G4
226


DENY
289
Denied

BNS: Prison (non-IPP fka COCOT)
G10
315


DENY
290
Denied

BNS: LEC Semi-Public
G10
308


DENY
291
Denied

BNS: Subsystem Congestion
S
180


DENY
292
Denied

BNS: Subsystem Failure
S
180


DENY
293
Denied

BNS: No translation for address of such
S
180






nature




DENY
294
Denied

BNS: Unequipped User
S
999


DENY
295
Denied

BNS: Network Failure
S
180


DENY
296
Denied

BNS: Network congestion
S
999


DENY
297
Denied

BNS: Cellular (cellular is distinct from
G8
231






mobile)




DENY
298
Denied

BNS and Calling Card - Although the
G4
228






NPANXX belongs to SWBT the end-user








account number is no longer is a SWBT








customer. The line number now belongs to








another local service provider.




DENY
299
Failure

LNP Only Look-Up, the NPANXX is not a
LNP
000






portable range.




DENY
301
Denied
Y
Denied Originating Number (ANI) - The
G2
183






ANI has an Admin. block to automatically








decline all attempts from this line number.








(Admin. Reply)




DENY
302
Denied
Y
Terminating Number (DNI) has an Admin.
G2
182






block to automatically decline all attempts








to this line number. (Admin. Reply)




DENY
303
Denied
Y
Calling card has an Admin. block to
G2
000






automatically decline all attempts to this








line number. (Admin. Reply)




DENY
304
Denied
Y
Collect Number has an Admin. block to
G2
000






automatically decline all attempts to this








line number. (Admin. Reply)




DENY
305
Denied
Y
Third Party Number has an Admin. block to
G2
000






automatically decline all attempts to this








line number. (Admin. Reply)




DENY
306
Denied
Y
Commercial credit card has an Admin.
G2
000






block to automatically decline all attempts








to this line number. (Admin. Reply)




DENY
307
Denied
Y
Group Number has an Admin. block to
G2
000






automatically decline all attempts from this








group. (Admin. Reply)




DENY
308
Denied
Y
Global Negative Database Block - There is
G2
000






an Admin. block in the Global Negative








Database to this line number for the








Audiotext Industry. (Admin. Reply)




DENY
309
Denied
Y
Excessive calling card PIN hits - The
G2
000






threshold for bad PIN attempts for a calling








card was exceeded in the Admin. fraud








control system (Admin. Reply). This is the








same as reply code 055.




DENY
400
Denied

Commercial credit card, Invalid

506






Commercial credit card - This is not a valid








commercial credit card account number. It








failed the MOD 10 check. Also an invalid








amount, invalid date or a format error may








cause this response. (Host or Admin.








Reply)




DENY
401
Denied

Commercial credit card, Call issuer - The

507






authorization attempt triggered a flag in the








fraud control system of the issuing bank,








Banknet or VISAnet.




DENY
402
Denied

Commercial credit card, Confiscate card -

508






No billing is allowed to this account








number. If possible confiscate this card.




DENY
403
Denied

Commercial credit card, Authorization

509






Declined - No billing is allowed to this








account number.




DENY
404
Denied

Commercial credit card, Unable to Validate

510






Account Number - There is problem in








authorizing this account number.




DENY
405
Denied

Commercial credit card, Card expired - No

511






billing is allowed to this account number








because the card has expired




DENY
406
Denied

Commercial credit card - Invalid Merchant

512






ID




DENY
408
Denied

Commercial credit card, Invalid card and

513






Address (zip code) - Both the account








number and the address or zip code are








invalid. Do not allow billing to this account








number.




DENY
409
Denied

Commercial credit card, System Problem -

514






There is a technical problem with the








authorization system of the issuing bank,








Banknet or VISAnet.




DENY
420
Denied

Commercial credit card, Over withdrawal

515






limit - This account has exceeded the








withdrawal threshold in the authorization








system of the issuing bank




DENY
421
Denied

Commercial credit card, Over credit limit -

516






This account has exceeded the credit








threshold in the authorization system of the








issuing bank




DENY
422
Denied

Commercial credit card, Lost card,

517






Confiscate - This account number was








reported lost. No billing is allowed to this








account number. If possible confiscate this








card.




DENY
423
Denied

Commercial credit card, Stolen card,

518






Confiscate card - This card was reported








stolen. No billing is allowed to this account








number. If possible confiscate this card.




DENY
424
Denied

Commercial credit card, Invalid Pin - This

519






means a bad PIN was used.




DENY
425
Denied

Commercial credit card, Allowable Number

520






of PIN Tries Exceeded - The threshold for








bad PIN attempts for a calling card was








exceeded in the authorization system of the








issuing bank, Banknet or VISAnet.




DENY
426
Denied

Duplicate transaction. The Authorization

521






host considers this a duplicate transaction.









In the embodiment of the invention depicted in the drawings, regardless of the type of service provider or the type of validation request, clients or vendors may need a profile so that the process or method carried out by the system 10 knows how to treat the request. The client or vendor profile may be set up in a database, which includes the indicators that are set for the type and tests for each request, which will be subsequently received from the vendor.
The first table shows the operations in the BTN test descriptions process. In one exemplary embodiment, a set of core tests is run for each client. Additionally, clients may have some configuration options to identify the tests that best fit their program.










BILLABLE BTN TESTs









PROCESS
TESTs
PURPOSE





VAL/Pre-bill
Client profile
Client profile for each id for BTN validation process test flags.


VAL only
ANI = BTN
Determines if originating number = BTN input by caller.


VAL/Pre-bill
Invalid # OFFNET
Ids Invalid NPAs & NXXs


VAL/Pre-bill
Global OFFNET
Ids (NPA)NXX & OCN combinations where there is not a B&C




agreement


VAL/Pre-bill
Product OFFNET
Ids (NPA)NXX & OCN combinations where the traffic type is not




approved to bill (7/24/01: MRC only for NECA and Illuminet Only)


VAL/Pre-bill
Client OFFNET
Ids (NPA)NXX & OCN combinations where there the Client id




(7###) is not approved to bill


VAL/Pre-bill
Special Calling Card
Ids (NPA)NXX & OCN combinations of special calling card #s for



OFFNET
non-calling card traffic that are unable to be billed


VAL/Pre-bill
Plan OFFNET
Ids (NPA)NXX & OCN combinations where a Client Plan is not




approved to bill


VAL/Pre-bill
ONNET
Ids (NPA)NXX & OCN combinations where there are B&C




agreements


VAL/Pre-bill
CLEC
Ids (NPA)NXX-xxxx's are not billable due to CLEC for all Clients.


VAL/Pre-bill
4250 BLOCK
Ids (NPA)NXX-xxxx's that have a 4250 billing block




(for MRC only)


VAL/Pre-bill
UNBILL
Ids (NPA)NXX-xxxx's that have unbilled previously for all Clients


VAL/Pre-bill
Block & Cancel -
Ids (NPA)NXX-xxxx's that requested a Block and/or Cancel; usually



GLOBAL
institutional


VAL/Pre-bill
Block & Cancel -
Ids (NPA)NXX-xxxx's that requested a Block and/or Cancel for a



Client Specific
particular Client id


VAL/1st + n
Val Code Cache
Ids (NPA)NXX-xxxx & Return Code combinations for previous


Pre-bill

request


VAL/1st Pre-
LIDB Validity Test
To determine the billable status of the return code from the LIDB


bill

dip


VAL/1st Pre-
LIDB CLEC RAO
Ids RAOs that belong to CLECs


bill




VAL/1st Pre-
LIDB CLEC OCN
Ids known CLEC OCNs


bill




VAL/1st Pre-
LIDB State Specific
To determine if the returned LIDB code is a state specific code and


bill
Conversion
then a conversion to the billable OCN for the ONNET check


VAL/1st Pre-
LIDB ONNET
Ids billable (NPA)NXX & returned OCN combinations


bill




ALL
VAL Trans Log
Log of each validation request and response by Client ID



















BTN CREDIT SCORING









PROCESS
TESTs
PURPOSE





VAL/Pre-bill
AREA CODE Change
Provides the new area code for the line number while in



indicator
permissive dialing period.


Val
ZIP MATCH
ZIP matches zip codes for (NPA) NXX (not in production as of




6/01)


VAL/Pre-bill
ANI WATCH -
(NPA)NXX-xxxx's where there a refund/chargeback has been



CLIENT
issued previously for this Client ID



(SOURCE: all)



VAL/Pre-bill
ANI WATCH -
(NPA)NXX-xxxx's where there a refund has been issued



CLIENT
previously for this Client ID



(SOURCE: client)



VAL/Pre-bill
ANI WATCH -
(NPA)NXX-xxxx's where there a chargeback/bad debt has been



CLIENT
issued previously for this Client ID



(SOURCE:




ebi/telco)



VAL/Pre-bill
ANI WATCH -
(NPA)NXX-xxxx's where there a refund/chargeback/bad debt has



GLOBAL
been issued previously from CLIENT, ebi or telco



(SOURCE: all)



VAL/Pre-bill
ANI WATCH -
(NPA)NXX-xxxx's where there a refund/chargeback/bad debt has



PRODUCT
been issued previously for the same product



(SOURCE: all)



VAL
Address
Not Available



Verification



















TEST BEFORE FIRST BTN BILLING









PROCESS
TESTs
PURPOSE





VAL/Pre-bill
LEC CARE FEED
Determines if the ILEC owns




the Acct. for billing


VAL/Pre-bill
Biz vs Res
Determines the commercial or




consumer status for credit score



















Example TESTs









PROCESS
TESTs
PURPOSE





VAL/Pre-bill
Threshold by Client
Determines whether the BTN has met




a Client specific threshold


VAL/Pre-bill
LEC PROV feed
To determine if LEC owns Acct


VAL/Pre-bill
Credit Check
Credit header files check from




Credit source


VAL/Pre-bill
New within 90 days
Determines if BTN is less




than 90 days old; affects




credit score









ON/OFFNET Family Tables (Billing Coverage)

The OFFNET table family contains OCN & NPA_NXX combinations where billing is not approved. If found, the BTN does not continue on the validation path.
The ONNET table determines if an NPA_NXX & OCN combination can be found among the billable combinations. In this case a match allows the BTN to move further on the validation path. A no match will return a failure.
The CLEC table consists of CLECs that the proprietor, or user of the system 10, does not have billing contracts with. This table is specific to the line number. Sources dictate the fields that will be present for the record. A match here is considered a fail and does not continue.
The 4250 Block table consists of specific line numbers that cannot be billed for 4250-01 record types. A match in this table stops the validation movement.
Bill Control Family Tables
The Unbills or unbillable table holds all the BTNs that have been sent to a subscribers' bill page but could not be placed on the bill page for various reasons. A match here halts the validation sequence for the subject BTN.
Block and cancel tables identify BTNs that have requested a permanent or a Client specific block for billing. A match sends a failed response.
Validation Cache is a table that holds responses in order not to process duplicates (e.g. Submit pressed 10 times). A match here will return the code stored from a previous request.
LIDB Family Tables
LIDB is a third party that supplies information to the phone line number level. The goal is to test and store as many relevant fields as can be requested in a transaction.
The LIDB Validity Table translates the LIDB code into a billable or non-billable response according to predefined business rules. A fail here will halt the validation for the request.
The State specific table is a conversion from a true OCN to a known State Specific OCN that is billable. A match here will trigger the conversion, the BTN continues in the validation process.
The transaction log is the history of each transaction request and response that is processed through the validation system.
The TPM indicates that an NPA is in the permissive dialing period. A match here appends the record with the updated number for a record update.
The ANI Watch has BTNs that have been given an adjustment for charges by the Client, proprietor or user of the system 10 or the Telco. This is to help the client determine the credit score for the BTN.
Unlike the conventional use of the LIDB database that uses the LIDB data to obtain information on a destination/termination or recipient location or subscriber unit, the system 10, in one exemplary embodiment, uses the industry standard LIDB database to obtain relevant information on the initiating subscriber line. The subscriber line reference data obtained from the LIDB database is then processed to generate modified validity codes, which provide a vendor with data to facilitate deciding whether or not a transaction should be processed. The LIDB/LNP database may be queried as if a collect call event is occurring and a call is thus mimicked. The processing of the transaction, in one exemplary embodiment, involves communicating the relevant transaction data to a folder of the subscriber with a relevant Telco. The method of, and system 10 for, validating the billing account associated with the subscriber line allows, for example, a subscriber line to be used to validate and conclude a transaction instead of using a conventional payment techniques such as a credit card, debit card, bank account details or the like.
A current industry-wide problem is the lack of ability of a service provider to identify when a line subscriber has switched his service to a CLEC since the service provider may not have an existing billing arrangement with such a CLEC and may also not have a source for the BNA to allow for a direct billing solution. LNP databases were originally established for the purpose of directing call routing activities among facilities-based carriers and most telephone numbers ported to a CLEC do not involve a facility change (i.e. the CLEC is simply reselling the incumbent LEC's facilities). This means that, for billing decision purposes, LNP queries may provide an incorrect response.
In one embodiment of the present invention, the LNP queries have been enhanced by analyzing and interpreting other field elements included within the query response. Specifically, certain values or, in some cases, the absence of certain values, in the Operating Company Number (“OCN”) and/or the Regional Accounting Office (“RAO”) fields, allows further accuracy in the validation response. While the definitions of the OCN and RAO field elements can be obtained from industry sources, their interpreted use in the validation process is unique to the present invention. Use of these additional data elements can improve the reliability of the validation event.
In addition, the present invention may include supplementing LNP results with CARE queries in LEC regions where LNP results are inadequate and CARE costs are not otherwise prohibitive based on the retail price of the underlying service. CARE may provide a reliable result on CLEC-ported numbers since its basic purpose is to provide subscriber account information (such as billing name and address). Once a number is ported to a CLEC, the incumbent LEC no longer has subscriber responsibility and will, therefore, return an “unavailable” response, even if the LEC's dial-tone facility is still being utilized. This negative response is then used to generate a “deny” status on the subscriber based on the current lack of CLEC billing support.
The exemplary embodiment of the present invention may supplement the validation process through the use of internal databases built from information gathered throughout the billing and collection process and process logic gleaned from previous billing experience.
It is important to appreciate that all of the operations in the method executed by the system 10 need not be executed in real-time. In one exemplary embodiment, after the approval code 000 has been generated by the system 10 at operation 134, the system 10 terminates its pre-validation check routine as shown at operation 136. At this point the system 10 may merely provide pre-validation data or verification data to indicate to the vendor 12 whether or not the subscriber line is billable. Thus the system 10 may, in a first interaction with the vendor 12 provide pre-validation data, and in a second interaction process billing information. During the processing of billing information the validation process may once again be executed. In certain embodiments, the first interaction may be in the form of a registration process during which the validation procedure is carried out to register a subscriber line. The vendor may then conduct numerous transactions with subscriber and subsequent validation checks on the subscriber line may then only be carried out on a periodic basis.
After the validation code has been sent to the vendor 12, and the pre-validation procedure has been completed, the system 10 then carries out the fraud checks on a non real-time basis (usually during the next 48 to 72 hours) as shown in operations 140 to 144. The information obtained during the fraud control check, if necessary, is used to update the various databases. In particular, after a BTN has been successfully validated but before a billing event takes place, the CARE investigation operations 140 to 144 may be executed. In the exemplary embodiment, the system 10 is arranged to interrogate off-site CARE databases and the results of the enquiry are stored in the CARE database 46. Checks on the data received from the CARE databases are then performed; whereafter one or more of the other databases may be updated with the results. For example, the CARE database may be updated with new within 90 days information, business indicator information, or the like. In the exemplary embodiment, CARE codes 2618 and 2619 indicate that the BNA is not available and that the LEC no longer owns the account.
The updating of the databases following the CARE investigation may allow enhanced future checks by the system 10 in a subsequent pre-validation procedure or subsequent registration validation event. The updated information may be provided to the vendor 12. However, if the BTN information returned from the CARE database does not meet predefined criteria, the other databases of the system 10 may not be updated.
In the embodiment described above, information on the subscriber line 17 is forwarded by the service provider or vendor 12 to the system 10 for validation. However, in other embodiments of the invention, the consumer or customer 11 may call the system 10 directly, as shown by line 150 in FIG. 5, and the ANI may then be obtained by the system 10 directly from the customer 11 and not indirectly from the vendor 12. Further subscriber line data, e.g. BTN, address of the customer 11 and so on, may then also be obtained directly from the customer 11. For example, the customer 11 may have appropriate software installed on his/her PC which allows the customer 11 to dial into the system 10 in an automated fashion should he/she wish to charge any requested goods or services to his/her subscriber account. The system 10 would then validate the subscriber line number 17 using the method described above. The system 10 then typically communicates a validation code (e.g. corresponding to approval or non-approval) to the vendor 12 as shown by line 152. The vendor 12 would then conclude the transaction with the customer 11 if the subscriber line has been validated.
The proprietor or user of the system 10 may function as a type of clearing house. In particular, the proprietor or user of the system 10 may be responsible or accountable for payment for the goods or services for each transaction to the service provider or vendor 12 and, in turn, receive payment from the Telco 13. As mentioned above, the system 10 may update the telephone bill or account of the subscriber in an automated fashion (see line 154) and the account that the subscriber or customer 11 receives (see FIG. 6 and line 156 in FIG. 5) includes the charges for the goods and/or services provided by the vendor 12. The customer 11 may pay the Telco 13 (see line 155), the Telco 13 may pay the system 10 (see line 156), and the system 10 may pay the vendor 12 (see line 160). It is important to appreciate that these payments need not take place at the same time. In one exemplary embodiment, the payments between the Telco and the system 10, and the system 10 and vendor 12, take place periodically in a batch fashion.
FIG. 7 shows a diagrammatic representation of machine in the exemplary form of a computer system 600 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed.
The computer system 600 includes a processor 602, a main memory 604 and a static memory 606, which communicate with each other via a bus 608. The computer system 600 may further include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 600 also includes an alpha-numeric input device 612 (e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a disk drive unit 616, a signal generation device 618 (e.g., a speaker) and a network interface device 620.
The disk drive unit 616 includes a machine-readable medium 622 on which is stored a set of instructions (software) 624 embodying any one, or all, of the methodologies or functions described herein. The software 624 is also shown to reside, completely or at least partially, within the main memory 604 and/or within the processor 602. The software 624 may further be transmitted or received via the network interface device 620. For the purposes of this specification, the term “machine-readable medium” shall be taken to include any medium that is capable of storing, encoding or carrying a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.
Thus, a method and system to validate data associated with a subscriber line of a telecommunication network have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

## Claims

1. An identity verification method, the method comprising:
obtaining automatic number identification (ANI) data or billing telephone number (BTN) data associated with a subscriber line of a telecommunications network;
obtaining identification data associated with a subscriber, said identification data being different from the ANI data or the BTN data;
searching a first database using the ANI data or the BTN data to determine first reference subscriber data;
searching a second database using the identification data to determine second reference subscriber data;
comparing the first reference subscriber data to the second reference subscriber data; and
verifying an identity of the subscriber if the first reference subscriber data corresponds to the second reference subscriber data.

2. The identity verification method of claim 1, wherein the obtaining of the ANI data or the BTN data comprises obtaining the ANI data or the BTN data from a merchant of goods or services.

3. The identity verification method of claim 1, wherein the obtaining of the identification data associated with a subscriber comprises obtaining the identification data from a merchant of goods or services.

4. The identity verification method of claim 1, wherein the obtaining of the ANI data or the BTN data, and the identification data, comprises obtaining the ANI data or the BTN data, and the identification data, from a merchant, the merchant being in the process of selling goods or services to the subscriber.

5. The identity verification method of claim 1, wherein the identification data is a ZIP code.

6. The identity verification method of claim 5, wherein the second database is a ZIP data source.

7. The identity verification method of claim 1, wherein the identification data is address data.

8. The identity verification method of claim 7, wherein the second database is an address data source.

9. The identity verification method of claim 1, wherein the first database is a line identification database (LIDB).

10. The identity verification method of claim 1, wherein the second database is distinct from the first database.

11. The identity verification method of claim 1, wherein the second reference subscriber data comprises an address of the subscriber.

12. The identity verification method of claim 1, wherein the comparing of the first reference subscriber data to the second reference subscriber data comprises determining whether a match exists within a predefined range or geographic area.

13. The identity verification method of claim 1, wherein the verifying of the identity of the subscriber comprises verifying the identity of the subscriber if the first reference subscriber data corresponds to the second reference subscriber data within a predetermined range.

14. The identity verification method of claim 1, further comprising providing a verification status notification to a merchant.

15. The identity verification method of claim 1, wherein the searching of the first database further comprises using the ANI data to determine the BTN data.

16. The identity verification method of claim 1, further comprising:
receiving a transaction amount to be charged to an account associated with the subscriber line; and
in response to the verifying of the identity of the subscriber, approving the transaction.

17. The identity verification method of claim 1, wherein the first reference subscriber data and the second reference subscriber data are in a form of one or more LIDB codes.

18. The identity verification method of claim 17, further comprising generating modified codes from the one or more LIDB codes.

19. The identity verification method of claim 18, further comprising arranging the modified codes into a billable group and a non-billable group.

20. The identity verification method of claim 1, further comprising, prior to the searching, ascertaining if the ANI data or the BTN data corresponds to a billable subscriber line.

21. The identity verification method of claim 20, wherein the ascertaining comprises checking if an area code associated with the line data has changed and checking if the ANI data or the BTN data are missing from the record.

22. The identity verification method of claim 20, wherein the ascertaining comprises interrogating a network database with the ANI data to determine if the subscriber line is a billable subscriber line, and, if so, generating a decline status or an approved status in response to the interrogation.

23. The identity verification method of claim 20, wherein the ascertaining comprises searching a threshold database to determine whether an account associated with the subscriber line has reached a maximum monetary amount.

24. The identity verification method of claim 20, wherein the ascertaining comprises searching an off network (OFFNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the OFFNET database.

25. The identity verification method of claim 20, wherein the ascertaining comprises searching an on network (ONNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the ONNET database.

26. The identity verification method of claim 20, wherein the ascertaining comprises searching a competitive local exchange carrier (CLEC) database to determine whether the ANI data or the BTN data is known to have ported to a CLEC and whether transactions cannot be billed to an account associated with the subscriber line.

27. The identity verification method of claim 20, wherein the ascertaining comprises searching a 42 BLOCK database to determine whether a billing block has been imposed on the subscriber line.

28. The identity verification method of claim 20, wherein the ascertaining comprises searching a block and cancel database to determine whether a request has been made to prevent further transactions from being billed to an account associated with the subscriber line.

29. The identity verification method of claim 20, wherein the ascertaining comprises searching an unbilled database to determine whether there is a history of unbillable bills associated with the subscriber line.

30. The identity verification method of claim 20, wherein the ascertaining comprises searching an unpaid bills database to determine whether there is a history of unpaid bills associated with the subscriber line.

31. The identity verification method of claim 1, further comprising, after determining of the first reference subscriber data, using the first reference subscriber data to search a regional account office (RAO) database to determine whether the RAO is billable.

32. The identity verification method of claim 1, further comprising, after determining the first reference subscriber data, receiving an operating company number (OCN) from the first database, and determining whether the OCN corresponds to a known competitive local exchange carrier (CLEC), and determining whether the OCN corresponds to an off network (OFFNET) CLEC.

33. The identity verification method of claim 1, further comprising, after determining the first reference subscriber data, using the first reference subscriber data to determine if a new Numbering Plan Area (NPA)/NXX and an operating company number (OCN) combination for the subscriber line are guidable to a correct telephone company for billing.

34. The identity verification method of claim 1, further comprising interrogating a customer account record exchange (CARE) database.

35. The identity verification method of claim 34, further comprising receiving, from the CARE database, a billing name and address (BNA) associated with the subscriber line.

36. The identity verification method of claim 1, further comprising interrogating an ANI watch database to determine whether an account associated with the subscriber line has been previously adjusted.

37. The identity verification method of claim 36, wherein the interrogating of the ANI watch database comprises ascertaining ANI watch database a request has been made by the subscriber for financial credit.

38. The identity verification method of claim 36, wherein the interrogating of the ANI watch database comprises obtaining data associated with a written-off amount for charges that were billed to an account associated with the subscriber line.

39. The identity verification method of claim 1, further comprising determining whether the subscriber line is associated with a business line indicator.

40. The identity verification method of claim 1, further comprising determining whether the subscriber line has been in service for less than a predetermined amount of time.

41. The identity verification method of claim 1, wherein the method is performed in real-time.

42. The identity verification method of claim 1, further comprising:
receiving a monetary amount from a merchant of a sales transaction between the merchant and the subscriber; and
electronically billing the amount to an account associated with the subscriber line.

43. An identity verification method, the method comprising:
obtaining automatic number identification (ANI) data or billing telephone number (BTN) data associated with a subscriber line of a telecommunications network;
obtaining identification data associated with a subscriber, where said identification data is different from the ANI data or the BTN data;
requesting a search of a first database using the ANI data or the BTN data to determine first reference subscriber data;
requesting a search of a second database using the identification data and the first reference subscriber data to determine second reference subscriber data;
comparing the first reference subscriber data to the second reference subscriber data; and
verifying an identity of a subscriber based on the second subscriber data corresponding to the first reference subscriber data.

44. The identity verification method of claim 43, wherein the obtaining of the ANI data or the BTN data and of the identification data comprises obtaining the ANI data or the BTN data and the identification data from a merchant, the merchant being in a process of selling goods or services to the subscriber.

45. The identity verification method of claim 43, wherein the identification data is a ZIP code and the second database is a ZIP data source.

46. The identity verification method of claim 43, wherein the identification data is address data and the second database is an address data source.

47. The identity verification method of claim 43, wherein the second database is distinct from the first database.

48. The identity verification method of claim 43, wherein the second reference subscriber data comprises an address of the subscriber.

49. The identity verification method of claim 43, wherein the verifying of the identity of the subscriber comprises verifying whether the first reference subscriber data corresponds to the second reference subscriber data within a predetermined range.

50. The identity verification method of claim 43, further comprising providing a verification status notification to a merchant.

51. The identity verification method of claim 43, wherein the searching of the first database further comprises using the ANI data to determine the BTN data.

52. The identity verification method of claim 43, further comprising:
receiving a transaction amount to be charged to an account associated with the subscriber line; and
in response to the verifying of the identity of the subscriber, approving a transaction associated with the transaction amount.

53. The identity verification method of claim 43, further comprising, prior to the searching, ascertaining whether the BTN data or the ANI data corresponds to a billable subscriber line.

54. The identity verification method of claim 53, wherein the ascertaining comprises:
determining whether an area code associated with the subscriber line has changed; and
determining whether the ANI data or the BTN data are missing from a record.

55. The identity verification method of claim 53, wherein the ascertaining comprises:
interrogating a network database with the ANI data to determine whether the subscriber line is a billable subscriber line; and
if the subscriber line is a billable subscriber line, selectively generating an approved status.

56. The identity verification method of claim 53, wherein the ascertaining comprises searching a threshold database to determine whether an account associated with the subscriber line has reached a maximum monetary amount.

57. The identity verification method of claim 53, wherein the ascertaining comprises searching an off network (OFFNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the OFFNET database.

58. The identity verification method of claim 53, wherein the ascertaining comprises searching an on network (ONNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the ONNET database.

59. The identity verification method of claim 53, wherein the ascertaining comprises searching a competitive local exchange carrier (CLEC) database to determine whether the ANI data or the BTN data is known to have ported to the CLEC.

60. The identity verification method of claim 53, wherein the ascertaining comprises searching a 42 BLOCK database to determine whether a billing block has been imposed on the subscriber line.

61. The identity verification method of claim 53, wherein the ascertaining comprises searching a block and cancel database to determine whether a request has been made to prevent further transactions from being billed to an account associated with the subscriber line.

62. The identity verification method of claim 53, wherein the ascertaining comprises searching an unbilled database to determine if there is a history of unbillable bills associated with the subscriber line.

63. The identity verification method of claim 53, wherein the ascertaining comprises searching an unpaid bills database to determine if there is a history of unpaid bills associated with the subscriber line.

64. The identity verification method of claim 43, further comprising, in response to determining the first reference subscriber data, using the first reference subscriber data to search a regional account office (RAO) database to determine whether the RAO database is billable.

65. The identity verification method of claim 43, further comprising, in response to determining the first reference subscriber data, receiving an operating company number (OCN) from the first database, and determining if the OCN corresponds to a known competitive local exchange carrier (CLEC) and whether the OCN corresponds to an off network (OFFNET) CLEC.

66. The identity verification method of claim 43, further comprising, in response to determining the first reference subscriber data, using the first reference subscriber data to determine whether a new Numbering Plan Area (NPA)/NXX, and an operating company number (OCN) combination for the subscriber line are guidable to a correct telephone company for billing.

67. The identity verification method of claim 43, further comprising interrogating a customer account record exchange (CARE) database.

68. The identity verification method of claim 67, further comprising receiving, from the CARE database, a billing name and address (BNA) associated with the subscriber line.

69. The identity verification method of claim 43, further comprising interrogating an ANI watch database to determine whether an account associated with the subscriber line has been previously adjusted.

70. The identity verification method of claim 69, wherein the interrogating comprises ascertaining whether previous requests have been made by the subscriber for financial credit.

71. The identity verification method of claim 69, wherein the interrogating comprises obtaining data associated with written-off amounts for charges that were billed to an account associated with the subscriber line.

72. The identity verification method of claim 43, further comprising determining whether the subscriber line is associated with a business line indicator.

73. The identity verification method of claim 43, further comprising determining whether the subscriber line has been in service for less than a predetermined amount of time.

74. The identity verification method of claim 43, wherein the method is performed in real-time.

75. The identity verification method of claim 43, further comprising:
receiving a monetary amount from a merchant, the merchant being associated with a sales transaction between the merchant and the subscriber; and
electronically billing the monetary amount to an account associated with the subscriber line.

76. An identity verification method, comprising:
obtaining, from a merchant, first identification data and second identification data, the first identification data and the second identification data being associated with a subscriber;
transmitting a first request for a search of a first database using the first identification data;
receiving first reference subscriber data in response to the first request;
transmitting a second request for a search of a second database using the first reference subscriber data and the second identification data;
receiving second reference subscriber data in response to the second request;
comparing the first reference subscriber data to the second reference subscriber data; and
verifying an identity of the subscriber based on the first reference subscriber data corresponding to the second subscriber data.

77. The identity verification method of claim 76, wherein the first identification data is a billing telephone number (BTN) associated with a subscriber line of a telecommunications network.

78. The identity verification method of claim 76, wherein the second identification data is a ZIP code or address data associated with the subscriber.

79. The identity verification method of claim 76, wherein the second database is distinct from the first database.

80. The identity verification method of claim 76, wherein the second reference subscriber data comprises an address of the subscriber.

81. The identity verification method of claim 76, wherein the verifying of the identity of the subscriber comprises determining whether the first reference subscriber data corresponds to the second reference subscriber data within a predetermined range.

82. The identity verification method of claim 76, further comprising providing a verification status notification to the merchant.

83. The identity verification method of claim 76, further comprising, prior to the searching, determining whether an area code associated with data subscriber line has changed and determining whether a billing telephone number (BTN) associated with a subscriber line of a telecommunications network is missing from a record.

84. The identity verification method of claim 76, further comprising:
prior to the searching, interrogating a network database with a billing telephone number (BTN) associated with a subscriber line of a telecommunications network to determine whether the subscriber line is a billable subscriber line; and
if the subscriber line is a billable subscriber line, selectively generating an approved status.

85. The identity verification method of claim 76, further comprising, prior to the searching, interrogating a threshold database to determine whether an account associated with a subscriber line has reached a maximum monetary amount that may be charged to an account associated with the subscriber line.

86. The identity verification method of claim 76, further comprising, prior to the searching, interrogating an off network (OFFNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of a subscriber line is present in the OFFNET database.

87. The identity verification method of claim 76, further comprising, prior to the searching, interrogating an on network (ONNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of a subscriber line is present in the ONNET database.

88. The identity verification method of claim 76, further comprising, prior to the searching, interrogating a competitive local exchange carrier (CLEC) database to determine whether a billing telephone number (BTN) associated with a subscriber line of a telecommunications network is known to have ported to the CLEC.

89. The identity verification method of claim 76, further comprising, prior to the searching, interrogating a 42 BLOCK database to determine whether a billing block has been imposed on a subscriber line associated with the subscriber.

90. The identity verification method of claim 76, further comprising, prior to the searching, interrogating a block and cancel database to determine whether a request has been made to prevent further transactions from being billed to an account associated with a subscriber line associated with the subscriber.

91. The identity verification method of claim 76, further comprising, prior to the searching, interrogating an unbilled database to determine whether there is a history of unbillable bills associated with a subscriber line associated with the subscriber.

92. The identity verification method of claim 76, further comprising, prior to the searching, interrogating an unpaid bills database to determine whether there is a history of unpaid bills associated with a subscriber line associated with the subscriber.

93. The identity verification method of claim 76, further comprising using the first reference subscriber data to search a regional account office (RAO) database to determine if the RAO database is billable.

94. The identity verification method of claim 76, further comprising, after determining the first reference subscriber data, receiving an operating company number (OCN) from the first database, and determining whether the OCN corresponds to a known competitive local exchange carrier (CLEC) or whether the OCN corresponds to an off network (OFFNET) CLEC.

95. The identity verification method of claim 76, further comprising using the first reference subscriber data to determine whether a new Numbering Plan Area (NPA)/NXX, and an operating company number (OCN) combination for a subscriber line associated with the subscriber are guidable to a correct telephone company for billing.

96. The identity verification method of claim 76, further comprising interrogating a customer account record exchange (CARE) database.

97. The identity verification method of claim 76, further comprising determining whether a subscriber line associated with the subscriber is associated with a business line indicator.

98. The identity verification method of claim 76, further comprising determining whether a subscriber line associated with the subscriber has been in service for less than a predetermined amount of time.

99. The identity verification method of claim 76, wherein the method is performed in real-time.

100. The identity verification method of claim 76, further comprising:
receiving a monetary amount from a merchant, the merchant being associated with a sales transaction between the merchant and the subscriber;
and electronically billing the monetary amount to an account associated with a subscriber line associated with the subscriber.

101. A non-transitory machine-readable medium for storing a set of instructions that, when executed by a machine, cause the machine to:
obtain automatic number identification (ANI) data or billing telephone number (BTN) data associated with a subscriber line of a telecommunications network;
obtain identification data associated with a subscriber, said identification data being different from the ANI data or the BTN data;
request a search of a first database using the ANI data or the BTN data to determine first reference subscriber data;
request a search of a second database using the identification data and the first reference subscriber data to determine second reference subscriber data;
compare the first reference subscriber data to the second reference subscriber data; and
verify an identity of the subscriber based on the comparison.

102. An identity verification system comprising:
a network interface device to receive:
automatic number identification (ANI) data or billing telephone number (BTN) data associated with a subscriber line of a telecommunications network, and
identification data associated with a subscriber, said identification data being different from the ANI data or the BTN data;

a processor to execute instructions stored in memory, the instructions comprising:
requesting a search of a first database using the ANI data or the BTN data to determine first reference subscriber data,
requesting a search of a second database using the identification data and the first reference subscriber data to determine second reference subscriber data,
comparing the first reference subscriber data to the second reference subscriber data, and
verifying an identity of the subscriber based on the comparison.

103. The identity verification system of claim 102, wherein network interface device is to receive the ANI data, the BTN data, and the identification data from a remotely located merchant.

104. The identity verification system of claim 102, wherein the first database and the second database are remotely located from the network interface device and the processor.

105. The identity verification system of claim 102, wherein the processor is to execute the instructions stored in memory in real-time.

106. The identity verification system of claim 102, wherein the processor is to execute instructions to search one or more remote databases selected from the group consisting of a competitive local exchange carrier (CLEC) database, a 42 BLOCK database, a Block and Cancel database, an unpaid bills database, an off network database, an on network database, an address verification database, a regional account office (RAO) database, an operating company number (OCN) database, a customer account record exchange (CARE) database.

107. A method to determine billability of a subscriber line, the method comprising:
obtaining automatic number identification (ANI) data or billing telephone number (BTN) data associated with the subscriber line;
using the ANI data or the BTN data to determine whether the subscriber line is billable by performing one or more searches selected from a group consisting of:
searching a threshold database to determine whether an account associated with the subscriber line has reached a maximum monetary amount that may be charged to the account;
searching an off network (OFFNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the OFFNET database;
searching an on network (ONNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the ONNET database;
searching a competitive local exchange carrier (CLEC) database to determine whether the ANI data or the BTN data are known to have ported to a CLEC;
searching a 42 BLOCK database to determine whether a billing block has been imposed on the subscriber line;
searching a block and cancel database to determine whether a request has been made to prevent further transactions from being billed to an account associated with the subscriber line;
searching an unbilled database or an unpaid bills database to determine whether there is a history of unpaid bills or unbillable bills associated with the subscriber line; and

notifying the merchant if the subscriber line is not billable.

108. The method of claim 107, further comprising:
obtaining, from the merchant, identification data associated with the subscriber, said identification data being different from the ANI data or the BTN data;
if the subscriber line is billable:
searching a first database using the ANI data or the BTN data to determine first reference subscriber data;
searching a second database using the identification data to determine second reference subscriber data;
determining whether the first reference subscriber data corresponds to the second reference subscriber data; and

notifying the merchant that the identity of the subscriber has been verified, if the first reference subscriber data corresponds to the second reference subscriber data.

109. A system comprising:
a network interface device to obtain from a merchant automatic number identification (ANI) data or billing telephone number (BTN) data associated with a subscriber line of a telecommunications network;
a processor configured to execute instructions stored in memory, the instructions comprising:
using the ANI data or the BTN data to determine whether the subscriber line is billable by performing one or more searches selected from a group consisting of:
searching a threshold database to determine whether an account associated with the subscriber line has reached a maximum monetary amount that may be charged to the account;
searching an off network (OFFNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the OFFNET database;
searching an on network (ONNET) database to determine whether an industry standard Numbering Plan Area (NPA), an NXX, or an operating company number (OCN) of the subscriber line is present in the ONNET database;
searching a competitive local exchange carrier (CLEC) database to determine whether the ANI data or the BTN data is known to have ported to a CLEC;
searching a 42 BLOCK database to determine whether a billing block has been imposed on the subscriber line;
searching a block and cancel database to determine whether a request has been made to prevent further transactions from being billed to an account associated with the subscriber line;
searching an unbilled database or an unpaid bills database to determine whether there is a history of unpaid bills or unbillable bills associated with the subscriber line; and

notifying the merchant via the network interface device if the subscriber line is not billable.