Note: Descriptions are shown in the official language in which they were submitted.
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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;
1
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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:
2
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
3
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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;
4
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
6
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
7
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
8
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
9
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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.
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
11
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
12
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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:
13
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
[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
14
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
00015103624000120011231
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:
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
16
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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:
17
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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.
18
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
19
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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.
21
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
[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
22
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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.
23
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
[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
24
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
50
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
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
50
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
26
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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.
27
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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,
28
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
29
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
48
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
31
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
32
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
33
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
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
34
CA 02474663 2004-07-29
WO 03/065277 PCT/US03/03016
(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.
