CA2474663A1 - Method of creating a transaction related record - Google Patents

Abstract

The invention regards a method of creating a transaction related record and includes communicating (26) selection data to a remote user terminal (24) wherein the selection data provides a user with an option to select payment for the transaction from one of a credit card (30), a telephone, and a bank account (32). The method monitors which particular account type the user selects and receives account data associated with the particular account. Thereafter, account data and an account type identifiers that identifies the account type selected by the user is included in a transaction record (28). The transaction record is then communicating to transaction processing equipment. The invention extends to transaction processing system and to merchant network equipment (2) and transaction processing equipment.

Description

METHOD OF CREATING A TRANSACTION RELATED RECORD
FIELD OF THE INVENTION
[0001]The present invention relates generally to the field of financial transaction records and, more specifically, to method of, and merchant network equipment for, creating a transaction related record. The invention also relates to a method of, and transaction processing equipment for, processing a transaction between a purchaser and a merchant.
BACKGROUND OF THE INVENTION

[0002] Merchants concluding transactions with purchasers via the Internet typically verify financial instrument information prior to finalizing the transaction. For example, if the purchaser wishes to pay using a credit card, the merchant typically obtains details of the credit card from the purchaser and verifies the transaction via a credit card gateway prior to finalizing the transaction. Likewise, if the purchaser wishes to pay using funds in a bank account, the merchant typically first verifies the transaction via an Automated Clearing House Network (ACH) prior to finalizing the transaction. It will thus be appreciated that the merchant is required to communicate different standard records for verification dependent on the type of financial instrument that the user selects, and the merchant is also required to deal with a different facility.
For the purposes of this specification, the application of the invention to the Internet should be predominantly, but not exclusively, borne in mind.
SUMMARY OF THE INVENTION

[0003]According to the invention, there is provided a method of creating a transaction related record, the method including:
communicating selection data to a remote user terminal, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account;

monitoring which particular account type the user selects;
receiving account data associated with the particular account; and including the account data in a transaction record for communication to transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.

[0004] Further in accordance with the invention, there is provided merchant network equipment, which includes:
a communication module to communicate selection data to a plurality remote user terminals via a communication network, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account, and receive account data associated with a particular account type which the user selects; and a processor module to include the account data°in a transaction record for communication to centralized transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.

[0005] Still further in accordance with the invention, there is provided a method of processing a transaction between a merchant and a purchaser, the method including:
receiving a transaction record from merchant network equipment;
identifying from the transaction record an account type selected from the group including credit card, a telephone and a bank, account;
creating a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and communicating the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house (ACH) when the selected account type is a bank account.

[0006] Still further in accordance with the invention, there is provided transaction processing equipment for processing a transaction between a merchant and a purchaser, the processing equipment including:

a merchant communication module to receive a transaction record from merchant network equipment;
a processor module to identify from the transaction record an account type selected from the group including credit card, a telephone and a bank, account and, create a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and a financial service communication module to communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network (ACH) when the selected account type is a bank account.
[0007] The invention extends to a transaction processing system, which includes:
merchant network equipment including:
a user communication module to communicate selection data to a plurality remote user terminals via a communication network, the selection data providing a purchaser with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account, and receive account data associated with a particular account type which the purchaser selects; and a processor module to include the account data in a transaction record which includes an account type identifier that identifies the account type selected by the user; and transaction processing equipment connected to the merchant network equipment via a communication network, the transaction processing equipment including:
a merchant communication module to receive a transaction record from the merchant network equipment;
a processor module to identify from the transaction record an account type selected by the purchaser and, create a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and a financial service communication module to communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network (ACH) when the selected account type is a bank account.

[0008] Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS

[0009]The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:
Figure 1 shows a schematic block diagram of a prior art system for processing a transaction concluded via the Internet;
Figure 2 shows a schematic representation of a system, in accordance with the invention, for processing a transaction via the Internet;
Figure 3 shows a schematic block diagram of transaction processing equipment, in accordance to the invention;
Figure 4 shows a schematic diagram of the interaction between various participants in the transaction processing system;
Figures 5 to 8 show schematic representations of exemplary screen layouts provided by merchant network equipment, also in accordance with the invention, to a user terminal;
Figure 9 shows a schematic operational flow diagram of the transaction processing equipment;
Figure 10 shows a schematic block diagram of a validation system for validating a transaction requested by a purchaser to be billed to a telephone account;
Figure 11 shows a schematic flow diagram of the system of Figure 9;
Figures 12 to 14 show more detail schematic diagrams of certain steps of the flow diagram of Figure 11;
Figure 15 shows a schematic operational diagram of the transaction processing equipment during a billing cycle for a particular transaction;

Figure 16 shows a schematic flow diagram of a billing process using a hybrid transaction record; and Figure 17 shows a schematic block diagram of computer equipment that may be used to implement the user terminal, merchant network equipment, and/or the transaction processing equipment.
DETAILED DESCRIPTION

[0010] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.

[0011] Referring to the drawings, reference numeral 20 generally indicates a prior art system for processing a transaction between a merchant 22 and a user or purchaser using a user terminal 24 (typically a personal computer or the like) via the Internet 26. When the user purchases goods and/or services via the Internet 26, the user is usually prompted to enter credit card or bank account details into the user terminal 24, which are then communicated via the Internet 26 to the merchant 22. Dependent upon the mode of payment selected, the merchant 22 then communicates a standard bank account authorization record, as commonly used in the industry, to a bank validation gateway 2~, or communicates a standard credit card authorization record to a credit card validation gateway 30. Usually, the merchant 22 first validates or checks whether or not the transaction can be processed by communicating with the bank validation gateway 28 or credit card validation gateway 30 and, if so, the merchant 22 may then obtain payment for the transaction via an appropriate bank 32. Thus, in the prior art, the merchant 22 is required to communicate a standard authorization record, either a standard credit card authorization record or a standard bank account authorization record, to a validation facility. Different records are thus communicated to different facilities dependent upon the particular payment method selected by the user.

[0012] Referring in particular to Figure 2 of the drawings, reference numeral 40 generally indicates a transaction processing system, in accordance with the invention. The system 40 includes merchant network equipment 42, also in accordance with the invention, provided at different remote merchants 50, and transaction processing equipment 44, also in accordance with the invention, which is configured to communicate with the merchant network equipment 42 via communication lines 46. In the embodiment depicted in the drawings, the communication lines 46 are shown as dedicated communication lines.
However, it is to be appreciated that the communication lines 46 may also form part of the Internet 26, as shown in broken lines in Figure 2. The merchant network equipment 42 is connected via an Internet interface 48, which defines a user communication module, to the Internet 26 so that the merchants 50 can, via the merchant network equipment 42, offer goods and/or services (cumulatively referred to as products) for sale to a variety of purchasers via the user terminals 52 connected to the Internet 26. The user terminals 52 may be conventional personal computers (PC's) or the like. As described in more detail below, a user may select a variety of different payment methods to purchase goods via the Internet 26 and.the merchant network equipment 42 then communicates a transaction record which includes an identifier identifying the particular type of payment method selected by the user to the transaction processing equipment 44. The transaction processing equipment 44 then creates a standard transaction record for communication to an appropriate validation and/or billing facility.

[0013] In particular, the transaction processing equipment 44 includes a processor module 64 including an application program interface (API) 65 which, as described in more detail below, extracts the relevant account data and account type identifiers from the transaction record received from the merchant 50 and creates an appropriate standard record. The standard record is then communicated via a financial service communication module 66 (see Figure 3) to one of a credit card validation facility 54 (see Figure 2), a telephone bill validation facility or system 56, a bank validation facility 58, a check clearing facility 60, and a direct billing facility 62. When the transaction processing equipment 44 receives a response from the relevant facility 54-62, the response is then communicated via the processor module 64 to the merchant 50. Accordingly, the processor module 46 may define a single API

that receives a single transaction record and creates a standard transaction record therefrom for communication to the relevant facility 54-62.

[0014]The transaction processing equipment 44 may include an automatic line number identification (ANI) module 68 (see Figure 3) that automatically identifies a subscriber line from which the user terminal 52 accesses the Internet 26. As described in more detail below, a telephone number associated with the subscriber line is used when the purchaser elects to effect payment for a transaction using a telephone account. The transaction processing equipment 44 creates one of a plurality of standard records suitable for one of, the facilities 54-62 and, accordingly, includes a standard record creation module 70 which then communicates the standard transaction record to the financial service communication module 66 as described above.
Further, the transaction processing equipment 44 includes a customer management system 72 which may function in a conventional fashion.

[0015] Referring in particular to Figure 4 of the drawings, reference numeral 80 generally indicates a further embodiment of a transaction processing system in accordance with the invention. The system 80 includes the components of the system 40 and, accordingly, like reference numerals have been used to indicate the same or similar features unless otherwise indicated.
In the system 80, a transaction processing facility 82 provides a one-stop transaction processing facility which a vendor or merchant 50 can use to authorize transactions, effect billing for transactions, and provide collection of funds for each transaction billed.

[0016]As mentioned above, a purchaser or user typically purchases goods and/or services from the merchant 50 using the user terminal 52. The merchant 50 using its merchant network equipment 42 communicates data, as shown by line 86, to the user terminal 52 that provides the user with an option to purchase goods and/or services using a plurality of different account types.

[0017] Once the user has selected the particular goods and/or services which he or she wishes to purchase (see line 84), the merchant network equipment 42 communicates a choice of payment method screen layout 88 (see Figure 5) for display on the user terminal 52. The screen layout 88 includes a credit card button 90, a bank account button 92, and a telephone bill button 94. This may also include additional payment options not shown in this drawing such as Direct Bill, WebBill or the like. The purchaser may then select which particular account type he or she wishes to use to effect payment for the purchase and, dependent upon which particular button is activated, a further screen layout is provided by the merchant network equipment 42. In particular, if the user activates the credit card button 90, a credit card information screen layout 96 (see Figure 6) is provided on the user terminal 52. The user then selects the particular type of credit card to be used, as shown at 98, and thereafter enters both credit card and billing address details as shown at 100.
If, however, the user activates the bank account button 92 thereby selecting to effect payment by the bank account, a bank account detail screen layout 102 (see Figure 7) is provided on the user terminal 52. The user then enters the appropriate data into the fields as shown at 104.

[0018] If the user wishes to charge the purchase to a telephone account or telephone bill, he or she activates the telephone bill button 94 and, in response thereto, a telephone detail screen layout 106 (see Figure 8) is provided on the user terminal 52. The telephone detailed screen layout 106 requires the user to enter his or her telephone number in field 108, as well as a customer code in field 110. The telephone number is user entered and is compared to the ANI.
If the ANI is not captured, then the telephone number is collected here and validated for its billing status. However, if the number is deemed billable, then the ANI is captured subsequently. The user is then required to confirm the telephone number by activating either the "YES" button 112 or the "NO" button 114. If the "NO" button 114 is activated, then the user is required to re-enter the telephone number in the field 108. If, however, the "YES" button 112 is activated the information is then communicated to the merchant network equipment 42.

[0019] Prior to finalizing any transaction, the merchant 50 typically requires validation of the particular account type that the user has selected to secure payment. Accordingly, the merchant 50 communicates a validation request, as shown by arrow 116 (see Figure 4) to the transaction .processing facility 82.
In a preferred embodiment, the request is in the form of the transaction record, as herein before described, which includes transaction type identification data as well as merchant identification data.

[0020]The transaction processing facility 82 then, via its transaction processing equipment 44, investigates an appropriate facility, e.g., the credit card validation facility 54, the phone bill validation facility 56, the bank validation facility 58, the check validation facility 60 or the direct bill validation facility 62. Accordingly, unlike the prior art, the system 80 allows the merchant 50 to validate a transaction using a single transaction processing facility 82 which, in turn, performs the necessary validations. The transaction processing equipment 44 then communicates validation data, as shown by arrow 118, to the merchant network equipment 42 of the merchant 50. The merchant network equipment 42 then communicates an appropriate response to the user terminal 52 dependent upon whether or not the transaction has been validated.
If the transaction has been validated, the transaction is then finalized between the merchant 50 and the purchaser and an appropriate communication is then forwarded to the transaction processing facility 82 to effect payment for the transaction, as described in more detail below.

[0021]Referring to Figure 9 of the drawings, reference numeral 120 generally indicates a schematic operational flow diagram of a validation process 120 which is carried out by the transaction processing equipment 44.
The validation process 120 is carried out in real-time and is invoked by the merchant 50 using its merchant network equipment 42 via a HTTP request as shown at step 122. The processor module 64, which runs the API 65, is configured to receive (using its merchant communication module 67) and identify a transaction record associated with any one of the account types which the user may select, analyzes the transaction record and identify which particular account type has been selected (see step 124). The transaction record includes an indicator defined by indication data, as shown below, to identify the account type chosen by the user:
Validation PurposelDescription , Indicator Type LEC Perform LEC Validation 01 Credit Card Pertorm Credit Card Authorization04 ACH Perform ACH Routing Number Check 05 [0022] This information is typically required on all validation requests.

[0023]When attempting to charge a transaction to a telephone account it is important to ensure that the local exchange carrier (LEC) has a billing arrangement with the transaction processing facility 82 as described in more detail below with reference to Figure 10.

[0024]An example of an HTTP validation request received by the transaction processing equipment 44 is as follows:
http://valid [0022] The parameters in the request are typically as follows:
ParameterValue TypeValue Description . required Key length Max Id numeric 4 Client ID yes valtype numeric 2 Validation Type yes - LEC, CC, ACH

Pass alphanumeric30 Password assigned no:
to client name alpha 30 Name no street1 alphanumeric30 Street no street2 alphanumeric30 Street no city alpha 30 City no state alpha 2 State no zip numeric 5 Zip no zip4 numeric 4 ZipPlus4 no [0023] In addition to the above information, the following account type dependent parameters must be passed in a validation request.
LEC Specific Validation Reauest:
[0024] In addition to the required parameters outlined above, the following parameters should be used when performing a LEC validation request.

Parameter Value Value Type Description required Key length Max Number to be validated, required ani numeric 10 yes or btn unless btn is present Number to be validated, required btn numeric 10 yes or unless ani is present ani dni numeric 10 no clientidnumeric 4 Ebillit assigned customeryes id [0025]An example of an HTTP validation request when the purchaser has selected a telephone account to pay for his or her purchases is as follows:
LEC Reguest Example:
http:/lvalidationurl/servhet?valtype=01 &
clientid=7000&ani=4083624000 [0026]An embodiment of a specific validation procedure, in which the subscriber line associated with the telephone account is validated, is described further on with reference to Figures 10-14.

[0027]The API 65 parses the transaction record an extracts the relevant identification data to determine the specific account type that the user has selected (see step 122). Once the account type has been identified (for example, 01 being for a telephone account, 04 being for a credit card account, and 05 being for an account requiring ACH type transaction), the API 65 extracts the telephone number associated with the subscriber line (ANI) unless a billing telephone number (BTN) is present in the record received from the merchant network equipment 42. The validation procedure is then carried out as shown at step 126 (see Figure 9). The transaction is then either approved or declined as shown in step 128 and an appropriate response is returned to the browser initiating the HTTP request at the merchant network equipment 42.
It is however to be appreciated that the validation inquiry using HTTP
protocol, may be effected by a user activating an appropriate hyper-link on a display screen of the user terminal 52 so that the validation process may take place via a direct communication 130 (see Figure 4) between the user terminal 52 and the transaction processing equipment 44 at the transaction processing facility 82. Typically, the response of the validation request is communicated to the merchant network equipment 42 and, accordingly as shown at step 132, the transaction processing equipment 44 may communicate a response to the browser of the merchant network equipment 42. The merchant network equipment 42 may then interpret or react upon the approval or declining of the transaction as the merchant 50 deems fit.

[0028] If the API 65 detects that the user has in fact selected a credit card type account for payment for the transaction, in which the transaction indicator data includes the indicator 04, the API 65 parses the transaction record received and creates a standard credit card inquiry record which is communicated to a conventional credit card gateway or validation facility 54.
As in the case of the telephone account, the request received from the merchant network equipment 42 is also in the form of a HTTP request which includes identification data indicating that the request is for a credit card validation. The data including in the HTTP request is typically as follows:
Credit Card Specific Validation Reauest:
[0025] In addition to the required parameters outlined above, the following parameters should be used when performing a Credit Card validation request.
Parameter' Value Value Type Description required Key length MaX

Type of transaction to process txtype alpha 1 A=Authorization, S=Sale, yes D=Delayed Capture, C=Credit, V=Void Indicates type of tender being used tender alpha 1 yes C=Credit Card Merchant account to use for transaction merchantAlphanumeric4 Variable length alpha-numericyes Merchant Account Number assigned by XYZ

Consumer's account number account numeric 16 yes Credit card number Cardholder's expiration date expdate date 4 yes MMYY 4-digit expiration date Transaction amount amt dollar 10 A decimal point separatesyes dollars from cents used only when submitting D, C, or V

transaction types origid alphanumeric20 yes Alpha-numeric number provided on initial transaction Used to perform AVS.

street alphanumeric50 yes Consumers street number Used to perform AVS.

zip numeric 5 yes Consumers zip code.

Subscriber ID

subid alphanumeric25 Account Number or ID assignedno to subscriber being charged Unique i<ey Used for mapping to a particular key alphanumeric25 no subscriber account. Used when XYZ

stores subscriber payment instrument (0026]An example of a credit card validation request from the merchant is as follows:
Credif Card Requesf Example:
"https://validationurl/servlet?id=Xx)CX&valtype=04&trxtype=A" +
"&tender=C&merchant=xxxx&account=5105105105105100&expdate=0402" +
"&amount=1.00&street=123 Street&zip=95121 &subid=101345&key=txyz001"
[0027]The details that are included in this record are provided by the user (see the display screen layout 96 in Figure 6). Accordingly, the API 65 converts an HTTP request, including indication data indicating the particular account type with which the request is associated, to a standard transaction record suitable for communication to the credit card validation facility 54 (see also Figure 2).
[0028] In addition to the required parameters set out above when the purchaser selects to pay for transaction using a bank account type, the validation request communicated by the merchant network equipment 42 to the transaction processing equipment 44 includes details of an ABA/routing number as well as a bank account number. Typically the record is as follows:
ACH Specific Validation Reauest:

[0029] In addition to the required parameters set out above, the following parameters should be used when performing a ACH validation request:
Parameter Value require Value Description Type Key length d Max routing numeric 9 9 digit ABA/Routing Yes Number account numeric 25 Bank Account Number Yes [0030]An example of the request received from the merchant network equipment 42 is as follows:
Credit Card Request Example:
"https://validationurl/servlet?id=XXXX&valtype=05&routing=00 00000000&account=123456789"

[0031]As in the cases above, the API 65 identifies the particular account type and creates a standard transaction record for communication to the ACH
facility 58 (see Figure 2).

[0032]Thus, in summary, the user has the option to select one of a plurality of different account types to effect payment for a transaction. Once the user has selected the particular account type then the merchant network equipment 42 communicates a transaction record to the transaction processing equipment 44 which then performs the particular validation request. Once a validation response has been received from the credit card validation facility 54, the phone bill validation facility 56, or the ACH facility 58, an appropriate transaction record is then communicated using HTTP techniques to the merchant network equipment 42. As discussed in more detail below, a storage flag may be set to store account information associated with the user at the transaction processing facility 44 so that, in future transactions, an account identifier need only be sent to the transaction processing facility 44 thereby to enhance security of the account information.

[0033]When responding to a validation request, the transaction processing equipment 44 typically includes a transaction record including the following fields:
Field PurposelDescription Field Values Response code returned to show response See Validation Response below success or failure of a transaction.

[0034]An example of a validation response communicated by the transaction processing equipment 44 to the merchant network equipment is as follows:
Validation Response Example: .
response 000 - transaction validated [0035]The following parameters are typically returned for each LEC specific (telephone account) validation request:
LEC Specific Validation Response:

[0036] In addition to the parameters outlined above, the following are exemplary parameters returned for each LEC specific validation request:
Parameter Value lengfih Value description required Type Ke MaX ,, y response numeric 3 Response code. yes newarecodenumeric 10 Full phone number with no new areacode permissivedat when new area code will be effective, numeric 8 no a format is yyyymmdd [0037]The follo~iving is an example of the response to the merchant 50.
LEC Response Example:
responselnewareacodelpermdate Credit Card Specific Validation Response:

[0038] In addition to the parameters outlined above, the following are exemplary parameters returned for each Credit Card specific validation request:

Field Purpose/Description Field Values fndicator Transaction Id/Number Alpha-numeric assigned by Transaction transid=
Id processor to credit number card transaction See EBI Batch Transaction Result Code of transaction result=
Result Processing Spec Response message returnedSee EBI Batch with Response Message respmsg=

transaction Processing Spec Transactions approved Alpha-numeric by the bank Authorization authcode=
Code will receive an authorizationnumber code AVS Address Match, No Match, Info not available Y, N, X avsaddr=

Response provided by bank Match, No Match, Info not available AVS Zip Response Y N, X avszip=

provided by bank [0039]An example of the response to the merchant 50 is as follows:
ACH Specific Validation Response:

[0040] In addition to the parameters outlined above the following are exemplary parameters returned for each ACH specific validation request:
Table 1 Field PurposelDescriptionField Values Indicator See EBI Batch Transaction Result Code of result=
Result transaction Processing Spec Credit Card Response Example:
responselrespmsg OOOlapproved [0041]Additionally, if the transaction is approved and the storage or originator flag is set, the purchaser account information is assigned a key which is sent back with the response. The account information is securely stored at the transaction processing facility 44.

[0042]As shown that step 138 (see Figure 9), if the transaction is not approved then an appropriate response is returned to the merchant 50 (see line 140 and step 132). If, however, the transaction is approved, the transaction processing equipment 44, if instructed to do so via the storage flag, may store account data associated with the particular account type selected by the user. In particular, the transaction validation request generated by the merchant network equipment 42 includes a subscriber or user identification (Subid) and a unique key for mapping stored account data to the specific user.
(see credit card specific validation request above). When the Subid and Key are present in the transaction record (see step 142) account data is stored (see step 144) at the transaction processing facility 82. If, however, the Subid and Key values are not provided, the transaction processing equipment 44 assumes that the account data is not to be stored and proceeds directly to step 132 as shown by arrow 146. The storage of the account data allows future transactions to be processed without communication of confidential account data but merely communication of the Subid and Key thereby providing enhanced security when transacting using the system 80.

[0043] Returning to Figure 4 of the drawings, once the transaction between the merchant 50 and the purchaser has been concluded, typically after a successful authorization or validation event as described above, a charge is then billed to the particular account type which the user or purchaser has selected. However, unlike the prior art systems 20 in which a merchant or vendor then communicates with multiple facilities as shown in Figure 1, the merchant 50 then via the merchant network equipment 42 communicates a single transaction or billing record to the transaction processing facility 82 which, in turn, creates an appropriate billing record for billing to the appropriate facility. Accordingly, the merchant 50 via its merchant network equipment 44 need communicate only with a single transaction processing facility 82 via its API 65. In order to process the billing, a comprehensive or all-in-one billing record is communicated to the transaction processing equipment 44.

[0044]An example of the all-in-one billing record which may be provided at the merchant or at the transaction processing facility 82. When direct communication 130 occurs and the customer management system is hosted at the transaction processing facility 82, then the billing cycles will be initiated at the transaction processing facility as follows:

All-in-One Billing Record [0045]After the successful authorization event, the charge will be billed to the consumer's payment of choice. Instead of interfacing with multiple formats and gateways, an all-in-one billing record allows the Merchant 50 to interface with one processing facility in a single record.

[0046]This file may be client provided or hosted at the transaction processing facility. If direct communication 130 occurs and the customer management system is hosted at the transaction processing facility, then the billing cycles will be initiated at the transaction processing facility 82.
Colum Field _...._ FieldValues REQ?

m ', Purposell7escription Transaction value with 01=LEC billing Y

02=Direct Billing 1 Value 03=Web Billing 04=Credit Card Processing 05=ACH/Check ~MMDD Format, date at start of transaction or 2 Date Y

billing date 1-character text field indicator Billing or Refund B=Billing 3 record Indicator Y
(LEC

R=Refund or Direct) 4 Amount 6-digit $$$$cc charge for the Y
billing or refund record Account Number or ID assigned to subscriber being Subscriber Y
Identifier charged 6 Subscriber Street Address of subscriber O
Street 7 Subscriber Zip code of subscriber O
Zip Unique Key used for mapping to a particular 8 Unique Key subscriber account. Used when O
XYZ stores subscriber payment instrument 9 Client ID 4 Digit Client ID number assignedY
by XYZ

Unique 10 character alphanumeric id assigned by Record Id Client to record. Used to reconcileO
submitted records.

In a direct billing scenario, billing data is processed by a billing system, and the output is to a physical paper invoice that is sent directly to the consumers billing address of record. In a web billing scenario, billing data is processed by a billing system, the output is to an electronic (or web-based) invoice. Notification of the bill is sent via email and the consumer who then accesses and pays the bill via a standard web browser with a credit card, bank account, check or the like.
In an ACH/Check billing scenario, billing data is processed by a billing system and the output is to a standard file format that is electronically transmitted through the Automated Clearing House Network. This transaction will either deduct from or credit to the consumers bank account for the amount specified within the sent transaction.

[0047]Additionally the following information is provided for each payment type.
LEC
~

11 ANI Origination Number Y

Billing Telephone 12 Billing Telephone Number Y

Number (BTN) DNIS or 13 Terminating Call record Terminating Number O

Number 3 Digit Rate Plan (Position 1 = 1-Flat, 2-Metered) 14 T a O
yp (Position 2-3 = unique rates) 15 Start Time HHMMSS Format O

16 Duration Actual "Off-Hook" time (MMMMSS O
format) Description Code 17 5 character alpha-numeric descriptionY
code zero (0) filled (LEC or Direct) CREpIT
CARP

18 Card Number Credit Card Number Opt*

19 Expiration Card Expiration Date (MMYY format)Opt*
Date A=Authorization S=Sale Credit Card ' 20 D=Delayed Capture Y

Transaction Type C=Credit V=Void Y=Yes 21 Process AVS Y

N=No Unique alpha-numeric transaction number 22 Transaction# Note: Required when submitting O
transaction types (field 17) D, C, or v Variable length alpha-numeric Merchant Account number 23 Merchant Account Y

assigned by EBI

ACHICHECK

24 Subscriber ' First & Last Name of subscriberY
Name Bank Routing Routing/ABA number at the individual or companies 25 Opt*

Number bank Bank Account Account number at the individual or companies bank that 26 O t p *.

Number is to be debited or credited 27 Check Number Check Number O

C=Checking 28 Account Type Opt*

S=Savings [0048] If the billing record is to go to the telephone bill, then the record follows the process set out in Figure 16 and ends up on the telephone bill of the purchaser.

(0049] If the request is to be billed via Credit Card or directly to the bank account and the Opt* indicators are .set, then the process takes the key to identify the account information in the database at the facility 82. After that, the records are sent to the appropriate gateway for inclusion on the bill page.

[0050]The all-in-one billing record defines a hybrid record in that, dependent upon its field values (which define a record type identifier), it may be associated with a plurality of different account types that are to be billed.
An example of the different account types that may be billed is shown above. In particular, when the record includes a "01" field value then an account at a LEC
is to be billed, a "02" field value then direct billing is to be carried out, "03" field value then web billing is to be effected, "04" then credit card processing is to be carried out, and "05" then ACHlcheck processing is to be carried out. It is to be appreciated that further field values may be included in other embodiments.
Thus, unlike the prior art systems 20 that communicate with different facilities for each different account type using different standard record types, the transaction processing facility 82 allows the merchant 50 to communicate a single record to a single facility which then processes the transaction.

[0051]When the transaction is billed to the particular account type selected by the user, the transaction processing facility 82 may, via the credit card gateway 54, in a conventional fashion debit the appropriate credit card account at the bank 32, as shown by lines 150 and 152 in Figure 4. The bank 32 would then send an appropriate credit card statement to the user, as shown by line 154 who, in responselthereto, is obliged to settle the account as shown by line 156. The transaction processing facility 82 pays the merchant 50 as shown by line 158 an amount equal to the.transaction amount less a fee or commission, and the transaction processing facility 82 receives payment for the transaction in the full amount from the bank 32 as shown by lines 160 and 162.

[0052] If, however, the user selects to pay for the transaction using a telephone account type, the transaction processing facility 82 bills the transaction directly into a telephone account, as shown by arrow 164, at a local telephone company 166. The telephone company 166, in return, sends a bill or telephone account 168 to the user which includes all transactions conducted by the user using the system 80 for any given period and, in response thereto, the user is required to settle the account with the telephone company 166 as shown by line 170. The telephone company 166, in turn, is responsible for paying the transaction processing facility 82 the full amount of the particular transaction or transactions as shown by line 172 and the transaction processing facility 82 then pays the merchant 50, as shown by line 158, an amount equal to the purchase price of the goods and/or services purchased less a particular commission or fee. In particular, the. transaction processing equipment 44, when billing a transaction, follows a billing process 173 as shown in Figure 15. Initially, the transaction processing equipment 44, as shown at step 174, receives an all-in-one billing file from the merchant network equipment 42. Each record within the file is then parsed to determine whether it is a telephone billing record, a credit card billing record, or an ACH
billing record as shown at step 176. Dependent upon the account type to which the transaction is to be billed, the process 173 proceeds along one of the three legs.

[0053] If the billing record is associated with a telephone account, an ANI
validation procedure 178 (substantially the same as the procedure shown at step 126 in Figure 9) is preformed. Thereafter, if the transaction is approved as shown at step 180, the transaction processing equipment 44 creates a conventional EMI transaction file and posts the file to the particular LEC for processing as shown at step 182.

[0054] If the billing record is associated with a credit card, the transaction processing equipment 44 processes the transaction, as shown at step 184 and inspects the billing record to determine if account identification data identified by the SUBID and KEY value is provided (see step 186). If no SUBID and KEY
value is provided in the transaction or billing record, the transaction processing equipment 44 uses the information from the billing record of the all-in-one file to process the transaction (see step 188) and, thereafter, performs real time credit card transaction with a payment gateway partner in a conventional fashion (see step 190). If, however, the SUBID and KEY values are provided, the transaction processing equipment 44 retrieves transaction information or account information from its database and uses this information to process the transaction (see step 192). Accordingly, the system 80 provides security enhancements in that the merchant network equipment 42 in any subsequent transactions need not provide confidential account data.

[0055] If, however, the client has selected to effect payment for the transaction using a bank account, the transaction processing equipment 44 then processes the billing record so that it is suitable to be sent to an ACH
system (see step 194) and, in a similar fashion to that described above, determines whether or not a SUBID and KEY value is provided in the billing record as shown in step 195. If no SUBID and KEY value is provided, the transaction processing equipment 44 then uses account information provided in the all-in-one billing record (see step 196) and thereafter creates an ACH
transaction file which is posted to an ACH processor partner (see step 198).
If, however, a SUBID and KEY value is provided, then the transaction processing equipment 44 retrieves confidential account information from its database (see step 197) and processes the transaction as shown at step 198. The ACH

transaction file may then, in a conventional fashion, be communicated to a secure FTP site.

[0056] Referring in particular to Figure 10 of the drawings, reference numeral 200 generally indicates a schematic block diagram of and exemplary validation module provided at the phone bill validation facility (which is typically provided at the transaction processing facility 82). The module 200 includes an application program interface (API) 201 that is connected to the transaction processing equipment 44. In addition, it is however to be appreciated that the API 201 may be connected to a variety of different hosts or clients which require validation of a subscriber line via which the remote terminals 52 carry out transactions for goods and/or services via the Internet 26.

[0057]The transaction processing equipment 40 communicates the telephone number of the subscriber line to the module 200 which then processes the information and provides a validation status, e.g. a code indicating a valid billable number or a code indicating that the line number is not a valid billable number (unbillable or non-billable). In particular, a plurality of codes associated with various statuses of the subscriber line is communicated to the transaction processing equipment 44 as described in more detail below.

[0058]The module 200 includes hardware and software to implement the invention. In particular, the module 200 includes a comparator module 218, a threshold database 220, an OFFNET database 222, an ONNET database 224, a competitive local exchange carrier (CLEC) database 226, a 42 BLOCK
database 228, a block and cancel database 230, an unbilled and/or unpaid bills database 232, line identification database (LIDB) short term cache 234, a validity check module 236, a regional account office (RAO) database 238, ari operating company number (OCN) database 240, an ONNET database 242, an.address verification database 244, customer account record exchange (CARE) results database 246, an ANI watch database 248, and an NPA
(Numbering Plan Area) exchange database 250. 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 further to increase the reliability of the validation process.

[0059] In addition to any one or more of the above databases, the module 200 is in communication via a conventional communication channel with an offsite or, in some embodiments, on-site line identification database (LIDB) host 252. The LIDB host 252 may include a line number portability (LNP) database. Typically, 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 module 200 communicates the subscriber line number to the LIDB host 252 which, in turn, communicates reference subscriber data in the form of industry standard LIDB codes back to the module 200 for processing. The module 200 then processes the LIDB codes to provide the merchant 84 with validation data relating to the purchase or transaction based on subscriber line. Unlike conventional LIDB applications which use a 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 module 200 is used to identify telephone numbers of originating subscriber lines.

[0060] Broadly, the module 200 includes a processor module 201 that includes the various databases 220 to 232 as well as the comparator module 218 and the validity check module 236, and an interrogation module 256 for interrogating the LIDB host 252. One or more servers with associated databases may define the aforementioned modules. Further, in the example illustrated, the LIDB host 252 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.

[0061] Referring in particular to Figures 11 to 14 of the drawings, various flow charts describing the method of operation of the module 200 are shown.

[0062] In Figure 11 of the drawings, reference numeral 203 generally indicates a validation process carried out by the module 200. The customer management system 72 (see Figure 3) sends the transaction or billing record to the module 200 (as shown at step 204). The module 200, when it receives the validation request, has its processor module 202 first check (see block 206) if all the information required for validation has been furnished by the merchant network equipment 42 and, if not, the request is returned to the merchant 50 as shown at step 207. If, however, all the information required by the module 200 is present in the record, the record is then parsed and the billing telephone number (BTN) is extracted from the record and formatted into a validation request as shown at step 208. Thereafter, as described more detail in Figures 12 to 14, the module 200 performs various checks during which the subscriber line is validated (see step 209). If the BTN progresses to a LIDB
interrogation step (as described in more detail below with reference to steps 264 to 286 in Figure 12), the request is then reformatted into a LIDB request to obtain LIDB
response information (see step 210). The LIDB database 211 is then interrogated and the LIDB response is received and parsed for relevant information whereafter it is reformatted into a BTN validation request as shown at step 212. Thereafter, and as described in more detail below with reference to Figures 12 and 14, the processor module 202 performs further validation checks (see step 213 in Figure 11 and steps 296 to 338 in Figures 12 and 14).
Once the request has been investigated, the various databases have been interrogated, and the results retrieved therefrom processed, the processor module 202 then translates the validation response into an appropriate response that is communicated to the transaction processing equipment 44 for communication to the merchant 50 (see step 214). The CMS. 72 then updates purchase data, and creates an account for the user as shown in step 132.
Thereafter, the API 201 communicates a display screen to the electronic terminal 52 that thanks the user for ordering the good and/or services.
Typically, each transaction defines a billing that is recorded at the merchant and, together with other billing events, is communicated to the transaction processing facility 82 at the end of a billing cycle (see step 218).

[0063]As described above, the transaction processing equipment 44 initiates a request to the module 200 to validate a transaction between the vendor and the purchaser to be included in a telephone bill associated with the subscriber line. As shown at step 260 (see Figure 12), the module 200 first checks to see if the BTN number is present in the request from the transaction processing equipment 44 and, if no number is present, a return code 121 is generated and communicated to the transaction processing equipment 44 as shown at step 262. The code 121 indicates that the module 200 is unable to process the request. If, however, the number is present in the request, the module 200 then checks if the line number captured (hereinafter also referred to as the ANI) by the ANI module 68 (see Figure 3), and the BTN entered on the display screen 106 (see Figure 8) match; as shown at step 264 (see also the comparator module 218 in Figure 10). If, however, the ANI and the BTN do not match, then the processor module 202 generates a code to indicate that the caller and the owner of the line number are not the same person (e.g. the user enters his or her BTN in the display screen 106 and uses an electronic terminal connected to a different subscriber line and is thus calling from a different ANI) and the relevant modified code is then returned to the transaction processing equipment 44.

[0064] If the ANI and the BTN do match, the processor module 202 interrogates the threshold database 220 (see step 268) to ascertain whether or not the line number has reached its threshold (e.g., a predefined client threshold parameter such as an account expenditure threshold). If the line number has reached its threshold, the processor module 202 then generates a code, as shown at step 270, which is then communicated to the transaction processing equipment 44 to indicate that the line number may not be granted service. In other words, the subscriber account cannot be billed for the goods and/or services requested by the user from the merchant 84.

[0065] If the threshold has not been reached, the module 200 then interrogates its OFFNET database 222 (see step 271 ) to check if the industry standard NPA/NXX and operating company number (OCN) of the subscriber line is present in the OFFNET database 222. The OFFNET database 222 includes NPA /NXX and OCN combinations of operating companies with which the proprietor or user of the module 200 does not have billing and collections agreements to bill into the Telco's bill page associated with the subscriber line.
Accordingly, the transaction processing facility 82 is unable to include a charge in the account associated with the subscriber line on behalf of the merchant for the transaction.

[0066] If the line number is in the OFFNET database 222, then the processor module 202 generates a plurality of codes (see step 272) and communicates these codes to the transaction processing equipment 44. The codes indicate that the NPA/NXX and OCN for the particular line number are not billable and, accordingly, charges for goods andlor services requested by the user cannot be included in a monthly telephone account by the module 200. The codes provide an indication to the transaction processing equipment 44 why the subscriber line is not billable or deliverable. If the subscriber line number is not included in the OFFNET database 222, a check is conducted to see whether or not the subscriber line number is included in the ONNET
database 224. This check is however optional in the embodiment depicted in the drawings, but may be mandatory if the module 200 does not include the OFFNET database 222.

[0067]Thereafter, as shown in step 278, the processor module 202 checks to see if the line number is found in a known CLEC table in the CLEC database 226. CLEC numbers are those line numbers that are known to have ported to a CLEC and, accordingly, the proprietor of the module 200 is thus unable to route these line numbers to the correct billing entities. If the line number is found in the CLEC database 226, then the processor module 202 generates a code~(see step 276) that is communicated to the transaction processing equipment 44. The code indicates that the BTN provided by the user is not billable for the CLEC and the module 200 can thus not charge the transaction to the subscriber account associated with the subscriber line.

(0068] If the line number is not found in the CLEC database 226, then the module 200 checks to see if the subscriber of the subscriber line has requested a 4250 billing block as shown at step 278. tn particular, the processor module 202 interrogates the 42 BLOCK database 228 and, ~if the number is located in the database 228, which indicates that monthly recurring charges (4250) charges are prevented from being billed to that line number, the processor module 202 generates a code (see step 280) which is communicated to the transaction processing equipment 44 to indicate that billing to the particular subscriber line has been blocked.

[0069] If, however, the subscriber line has not been blocked, the module 200 then checks at step 282 if the line number is located in the block and cancel database 230 and, if so, the processor module 202 generates a plurality of codes which are then communicated to the vendor as shown at step 284.

The block and cancel database 230 includes requests from owners of subscriber lines, agencies, businesses, or the like that a service be canceled or blocked from further billing. Thereafter, the module 200 interrogates the unbilled and/or unpaid bills database 232, as shown at step 286, to check if there is a history of any unpaid bills and/or unbillable bills associated with the subscriber line. Unbillable bills relate to those subscriber line numbers where previous attempts have been made to bill charges to the subscriber account associated with the line number, and which have been returned as unbillable.
If the processor module 202 locates the line number in the unbillable and/or unpaid bills database 232 then, as shown at step 288, a code is generated and communicated to the transaction processing equipment 44 to indicate that the line number was previously found to be unbillable and is still considered to be unbillable.

[0070]The process described above conducts a preliminary investigation into the subscriber line number or ANI/BTN to provide an initial indication of whether or not the ANI/BTN corresponds with a billable subscriber line. Once the initial investigation has been conducted, the module 200 then uses the ANI
to obtain reference subscriber line data in the form of LIDB codes from one or more industry standard databases in the form of the LIDB host or database 252.

[0071]As shown at step 290, if the ANI is not found in the LIDS database 252, the module 200 cannot provide any validation data to the transaction processing equipment 44 on this subscriber line and an appropriate code is then communicated to the transaction processing equipment 44 as shown at step 292.

[0072] Once the LIDB database or host 252 has been interrogated, it returns industry standard LIDB codes and line number portability (LNP) data to the module 200 as shown in step 294 (see Figure 13). The LIDB codes are then mapped or translated by the processor module 202 into modified validation codes that provide relevant validation information to the transaction processing equipment 44. 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 202, the LIDB codes, including OCN and RAO response codes, are fed into the validity check module 236 (see Figure 10).

[0073]As mentioned above, the LIDB host 252 may also provide LNP data to the module 200. 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 is verified in the CLEC database 226.
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 would be in control of the cable, dial tone and billing envelope for that number. Typically, the LNP cannot be used to identify CLEC
sellers that have resold the subscriber line under their brand, but still lease the cable and tone from an incumbent local exchange carrier (ILEC). Accordingly, the transaction processing facility 82 may be unable to process transaction data onto a bill page or telephone account of the CLEC reseller bill page. In order to identify reseller CLECs, the module 200 compares RAO and OCN
information, returned from the LIDB host 252, to data in the ONNET database 224. 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.

[0074] If the validity check module 236 determines that the response codes are invalid, the module 200 generates a plurality of modified codes (see step 298) which are communicated to the requestor or transaction processing equipment 44 to indicate that the mapping of the LIDB codes to the modified codes concluded that the line is an unbillable subscriber line.

[0075] If the validity check module 236 confirms the validity of the LIDB
codes and, in the event of the line number being a billable line number, the processor module 202 then checks the RAO database 238 to ascertain whether or not the RAO is billable, as shown at step 300. If the RAO is not billable, then the processor module 202 generates and communicates a return code (see step 302) to indicate to the transaction processing equipment 44 that the line number belongs to a CLEC that is not billable by the module 200.

[0076] In a similar fashion, at step 304 the processor module 210 checks to see if the OCN returned from the LIDB host 252 corresponds with a known CLEC or if the OCN corresponds with an OFFNET OCN and is therefore also unbillable. If the line number corresponds to an OCN that is not billable, a return code is generated by the processor module 210 and communicated to the transaction processing equipment 44 (see step 306).
[0077] If the subscriber line number has passed the RAO and OCN checks and, accordingly, it appears that the number is billable, the processor module 210 then checks to see if a new NPA /NXX and OCN combination for this line number is guidable to the correct local Telco for billing (see step 308). If the line number is not guidable, then the module 200 generates a code at step 310 that is communicated to the transaction processing equipment 44 to indicate that, even though the line number is billable, the transaction processing facility 82 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 transaction processing facility 82 is concerned and a decline status is therefore communicated to the transaction processing equipment 44.

[0078]The abovementioned steps 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 module 200, further checks or verification are conducted as described below.

[0079] In the event that the subscriber line number has passed or complied with the abovementioned checks, and has thus not yet been rejected, the module 200 performs address verification procedures at step 312. The module 200 then interrogates an address verification database 244 to compare the address or location data (e.g. a ZIP code) supplied by the user via a display screen on the terminal 52 with reference address data as shown at step 312.
If, however, the address supplied by the user does not match with the address in the verification database 244 or, the addresses are not within a predefined range or area, the processor module 202, as shown at step 314, generates a plurality of codes that are then communicated to the transaction processing equipment 44 to indicate the level of likelihood that the caller (ANI) and the account owner are the same person.

[0080] During the address verification step 312, the module 200 interrogates a customer account record exchange (CARE) database (which can be an on-site database which is regularly updated), to provide enhanced reliability. In particular, the CARE database or information site is typically one or more industry standard offsite databases that allow consumers to select or change their long distance service provider. Local Telcos forward specific customer information to the LEC associated with the subscriber. The information communicated typically includes a new phone number, billing address, installation date, the person or organization responsible for the account, or the like.

[0081]As shown at step 316, the module 200 interrogates the CARE
database or information site and CARE data is then loaded into CLEC and new line databases to perform certain fraud and billing checks. The CARE
information investigation occurs after a successful validation event. Once the module 200 has validated the subscriber line, the subscriber line number data is sent to a CARE database provider hosting the CARE database 246 to obtain the BNA and age of the account. The information is typically returned within hours and then processed. Care records that are returned without BNA and CLEC ACCOUNT codes are inserted into the CLEC database 226 for future reference. Accordingly, if the BTN is presented again at a later date, it will fail the CLEC check step (see step 274 in Figure 12).

[0082]The ANI watch database 248, which includes historical and adjusted information, is used by the module 200 to determine if the account has previously been adjusted (see step 316). Typically, this step 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.

[0083] If adjustments have previously been made to the account associated with the subscriber line, the processor module 202 generates a plurality of codes (see step 318) to indicate to the transaction processing equipment 44 that the adjustments have been made. If no adjustments have been made, the processor module 202 checks to see whether or not the line number has a business line indicator as shown at step 320. If the business line indicator is active, the module 200 generates a code (see step 322) that is communicated to the transaction processing equipment 44 to advise that the line is a business line. Thereafter, as shown in step 324, the processor module 202 checks to see if the subscriber line number has been in service for less than about 90 days and, if so, a return code (see step 326) is generated to advise the transaction processing equipment 44 who may then selectively decide whether or not to conclude the transaction. A database of new numbers may be updated with the new number.

[0084]Thereafter, the module 200 interrogates the ANI watch database 248 (see step 328) to ascertain whether or not the area code of the line number has been changed or is scheduled to change. This interrogation is typically for billing purposes only and is not used to decide upon the validity of the request.
In this step, the transaction processing equipment 44 requesting the validation typically updates the billing file with the new area code number, and the processor module 202 generates a code (see step 330) to advise the transaction processing equipment 44 of the scheduled change to the area code.

(0085] Once the line number has passed all the aforementioned checks, the module 200 then concludes that the subscriber line obtained using ANI
techniques is in fact a billable line and, accordingly, the transaction may be charged directly to the account of the subscriber. Accordingly, the module 200 then generates a code (see step 334) that is communicated to the transaction processing equipment 44. This code defines an approved status following both a billable line number enquiry as well as several fraud checks which are carried out by the fraud control module 332. If the line number has passed the abovementioned checks and the return code is generated, the process terminates at step 336. Thus, step 336 defines the end of the process during which the various checks have been conducted on the subscriber line to assess whether or not it is a billable subscriber line that charges may be billed to. Step 338 defines the last step to which the process jumps when, at any point during the abovementioned process, the line number is found not to be billable (e.g., a creditworthy decision was requested by the transaction processing equipment 44) and the inquiry is accordingly terminated and the relevant code is communicated to the transaction processing equipment 44.

[0086]The abovementioned steps are typically executed in real time.
However, information sources that do not allow checks on the line number in real time may be are carried out subsequently on the line number. Typically, once the real time evaluation is carried out and the return code is communicated to the transaction processing equipment 44, and the vendor and purchaser proceed with the transaction, transaction data is then periodically returned to the module 200 by the transaction processing equipment 44 for a pre-billing validation check or actual billing. During actual billing the module 200 accesses an account folder of the subscriber line at the Telco and inserts the charges due to the transaction processing equipment 44 into the telephone account. As shown at step 340, line numbers are sent to the CARE database 246 to determine if the BNA is available at the local Telco.
If the folder or telephone account is not available, the local Telco typically sends the BNA and codes as to why the number is unavailable to the transaction processing facility 44. If the BNA is found in the CARE database 246, the processor module 202 then checks to see whether or not the account was created within the last 90 days as shown at step 342. If the account was not created within the last 90 days, then the business indicator is checked as shown at step 344 and the process ends as previously shown at step 346. If, however, the number was found in the CARE database 246, the account was created within the last 90 days, or has an active business indicator then the module 200 generates the appropriate codes that are communicated to transaction processing equipment 44 and the process terminates as shown at step 348.

(0087] Referring in particular to Figure 16 of the drawings, in certain embodiments the transaction processing facility 82 processes all transactions during the cycle at the end of a bill cycle. Reference numeral 350 generally indicates an example of a telephone account billing process in which the merchant 50 communicates a billing transaction file in a all-in-one or hybrid format to the facility 82 (see step 352 in Figure 16). Each event or transaction in the transaction file includes an indicator or identification data to identify the particular account that it is related to, e.g. a telephone account, a credit card account, a bank account, or the like. The transaction processing system 44 of the facility 82 then receives the billing request file as shown at step 354, whereafter the request file is parsed, as shown at step 356, to identify only those transactions to billed to telephone accounts. The request file is also parsed by the processor module 64 to check whether or not all the required information is present in the file (see step 358). If not, a code is appended to the record as show at step 360. If all the information is present in the file, the process then proceeds to step 362 where the telephone account validation steps 208-214, as described above, are executed. Once the validation procedure has been completed, the BTN billing response is formatted into all-one-one format response with a response code appended to the end of each record and, the records are then returned to the CMS 72 (see step 366).

[0088]At the same time, transactions or billing events which have been validated as billable and thus capable of being included in the relevant telephone account, are translated into an electronic message interface (EMI) format appropriate for the Telco with which the telephone account is associated (see step 366). The EMI formatted~file is then transferred to the Telco for billing as shown in step 368 whereafter the Telco call places each billing event on telephone account associated with the subscriber line(see step 370). Typically, the Telco returns any records that can not be billed to the telephone account or that have already been billed and credited, or written off because of non payment to the transaction processing facility 82 as shown at step 372. The records received by the facility 82 are in the EMI format and the facility 82 translates the record to an appropriate return record including a reason code appended to the record, as shown at step 372, whereafter record is returned to the CMS 72.

[0089] Figure 17 shows a diagrammatic representation of machine in the exemplary form of a computer system 400 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.

[0090]The computer system 400 includes a processor 402, a main memory 404 and a static memory 406, which communicate with each other via a bus 408. The computer system 400 may further include a video display unit 410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 400 also includes an alphanumeric input device 412 (e.g. a keyboard), a cursor control device 414 (e.g. a mouse), a disk drive unit 416, a signal generation device 418 (e.g. a speaker) and a network interface device 420.

[0091]The disk drive unit 416 includes a machine-readable medium 422 on which is stored a set of instructions (i.e., software) 424 embodying any one, or all, of the methodologies described above. The software 424 is also shown to reside, completely or at least partially, within the main memory 404 and/or within the processor 402. The software 424 may further be transmitted or received via the network interface device 420. For the purposes of this specification, the term " machine-readable medium" shall be taken to include any medium which is capable of storing or encoding 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.

[0092]Thus, a system and method, including their various components, 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 (32)

What is claimed is:

1. A method of creating a transaction related record, the method including:
communicating selection data to a remote user terminal, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account;
monitoring which particular account type the user selects;
receiving account data associated with the particular account; and including the account data in a transaction record for communication to transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.

2. The method of Claim 1, in which the transaction record is a string communicated to the transaction processing equipment using HyperText Transfer Protocol (HTTP)

3. The method of Claim 1, which includes communicating the transaction record to the transaction processing equipment to perform at least one of validating the transaction and effecting payment for the transaction using the selected account type.

4. The method of Claim 3, which includes providing merchant identification data in the transaction record and validating the transaction in real-time.

5. The method of Claim 4, in which the communicating of the selection data to the remote user terminal is via the Internet.

6. The method of Claim 1, which includes providing a storage indicator in the transaction record which requests the transaction processing equipment to store the account data for use in at least one future transaction.

7. The method of Claim 6, which includes communicating the storage indicator to the transaction processing facility in the future transaction thereby to avoid subsequent communication of confidential account data.

8. A computer program product including a medium readable by a computer, the medium carrying instructions which, when executed cause the computer to:
communicate selection data to a remote user terminal, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account;
monitoring which particular account type the user selects;
receive account data associated with the particular account; and include the account data in a transaction record for communication to transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.

9. Merchant network equipment, which includes:
a communication module to communicate selection data to a plurality remote user terminals via a communication network, the selection data providing a user with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account, and receive account data associated with a particular account type which the user selects; and a processor module to include the account data in a transaction record for communication to centralized transaction processing equipment, the transaction record including an account type identifier that identifies the account type selected by the user.

10. The merchant network equipment of Claim 9, in which the processor module creates the transaction record in the form of a string communicated to the transaction processing equipment using HyperText Transfer Protocol (HTTP)

11. The merchant network equipment of Claim 10, in which the transaction record is communicated to the transaction processing equipment to perform at least one of validating the transaction and effecting payment for the transaction using the selected account type.

12. The merchant network equipment of Claim 11, in which the transaction record includes merchant identification data in the transaction record and the transaction is validated in real-time.

13. The merchant network equipment of Claim 9, in which the communication module is configured to communicate via the Internet.

14. The merchant network equipment of Claim 9, which provides a storage indicator in the transaction record which requests the transaction processing equipment to store the account data for use in at least one future transaction.

15. The merchant network equipment Claim 14, which includes communicating the storage indicator to the transaction processing facility in the future transaction thereby to avoid subsequent communication of confidential account data.

16. A method of processing a transaction between a merchant and a purchaser, the method including:
receiving a transaction record from merchant network equipment;
identifying from the transaction record an account type selected from the group including credit card, a telephone and a bank, account;
creating a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and communicating the standard transaction record to a credit card gateway when the selected account type is a credit card account and to a bank validation gateway when the selected account type is a bank account.

17. The method of Claim 16, which includes investigating a subscriber line validation system when the selected account type is a telephone account, the subscriber line validation system being operable to indicate if charges for the transaction can be included in the telephone account.

18. The method of Claim 16, in which the standard transaction record is communicated to one of the credit card gateway and the bank validation gateway to perform at least one of approving the transaction and effecting payment for the transaction using the selected account type.

19. The method of Claim 16, which includes communicating transaction approval information to the merchant network equipment so that the transaction is validated in real-time.

20. The method of Claim 16, in which the transaction record includes merchant identification data to identify a merchant communicating the transaction record to the transaction processing equipment.

21. The method of Claim 16, which includes storing account data and an account identifier at transaction processing equipment when the transaction record includes a storage indicator, the transaction processing equipment being operable to identify and retrieve the account data using the account identifier when processing at least one future transaction.

22. A computer program product including a medium readable by a computer, the medium carrying instructions which, when executed cause the computer to:
receive a transaction record from merchant network equipment;
identify from the transaction record an account type selected from the group including credit card, a telephone and a bank, account;
create a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network (ACH) when the selected account type is a bank account.

23. Transaction processing equipment for processing a transaction between a merchant and a purchaser, the processing equipment including:
a merchant communication module to receive a transaction record from merchant network equipment;
a processor module to identifying from the transaction record an account type selected from the group including credit card, a telephone and a bank, account and, create a standard transaction record from the transaction record when the account type is a credit card account and a bank account; and a financial service communication module to communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network (ACH) when the selected account type is a bank account.

24. The transaction processing equipment of Claim 23, which investigates a subscriber line validation system when the selected account type is a telephone account, the subscriber line validation system being operable to indicate if charges for the transaction can be included in the telephone account.

25. The transaction processing equipment of Claim 23, in which the standard transaction record is communicated to one of the credit card gateway and the bank validation gateway to perform at least one of validating the transaction and effecting payment for the transaction using the selected account type.

26. The transaction processing equipment of Claim 23, which communicates transaction approval information to the merchant network equipment.

27. The transaction processing equipment of Claim 23, in which the transaction record includes merchant identification data to identify a merchant communicating the transaction record to the transaction processing equipment.

28. The transaction processing equipment of Claim 23, which stores account data and an account identifier when the transaction record includes a storage indicator, the transaction processing equipment being operable to identify and retrieve the account data using the account identifier when processing at least one future transaction.

29. A transaction processing system, which includes:
merchant network equipment including a user communication module to communicate selection data to a plurality remote user terminals via a communication network, the selection data providing a purchaser with an option to select payment for a transaction from one of a credit card, a telephone, and a bank account, and receive account data associated with a particular account type which the purchaser selects; and a processor module to include the account data in a transaction record which includes an account type identifier that identifies the account type selected by the user; and transaction processing equipment connected to the merchant network equipment via a communication network, the transaction processing equipment including:
a merchant communication module to receive a transaction record from the merchant network equipment;
a processor module to identifying from the transaction record an account type selected by the purchaser and, create a standard transaction record from the transaction record when the account type is a credit card account and a bank account;
and a financial service communication module to communicate the standard transaction record to a credit card gateway when the selected account type is a credit card account and to an automatic clearing house network (ACH) when the selected account type is a bank account.

30. The system of Claim 29, in which user communication module interfaces the merchant network equipment to the Internet and the purchasers transact with the merchant via the Internet.

31. The system of Claim 30, in which the merchant network equipment is a web server.

32. A method of billing a plurality of transactions, the method including:
receiving a plurality of transaction records from merchant network equipment;
identifying from each transaction record an associated account type selected from the group including credit card, a telephone and a bank, account;
creating a standard transaction record from the transaction record; and communicating the standard transaction record to a credit card gateway when the selected account type is a credit card account, to an automatic clearing house (ACH) network when the selected account type is a bank account, and to telephone company when the selected account type is a telephone account.~