U.S. patent application number 12/647702 was filed with the patent office on 2010-04-22 for dual source remittance processing.
This patent application is currently assigned to CHECKFREE CORPORATION. Invention is credited to David Lee Garrison, Amy Lynn Kerin, Patricia A. Kight, Mary Elizabeth Lawson, Brad Perkins, Cheryl Lynn Ward.
Application Number | 20100100466 12/647702 |
Document ID | / |
Family ID | 42109431 |
Filed Date | 2010-04-22 |
United States Patent
Application |
20100100466 |
Kind Code |
A1 |
Garrison; David Lee ; et
al. |
April 22, 2010 |
Dual Source Remittance Processing
Abstract
A method and apparatus for electronically processing bill
payment requests where respective sets of payment requests are
received electronically from a plurality of independent sources,
each set of payment requests corresponding to an associated set of
payors requesting payments to a plurality of payees. The payment
requests are processed at a single remittance processing system
having a database including payee information for each of the
plurality of payees to generate payment directions for paying the
plurality of payees in accordance with the processed payment
requests.
Inventors: |
Garrison; David Lee;
(Columbus, OH) ; Kight; Patricia A.; (Alpharetta,
GA) ; Perkins; Brad; (Dublin, OH) ; Ward;
Cheryl Lynn; (Hilliard, OH) ; Lawson; Mary
Elizabeth; (Dublin, OH) ; Kerin; Amy Lynn;
(Delaware, OH) |
Correspondence
Address: |
SUTHERLAND II
SUTHERLAND, ASBILL & BRENNAN, LLC, 999 PEACHTREE STREET
ATLANTA
GA
30309
US
|
Assignee: |
CHECKFREE CORPORATION
Norcross
GA
|
Family ID: |
42109431 |
Appl. No.: |
12/647702 |
Filed: |
December 28, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09010193 |
Jan 21, 1998 |
|
|
|
12647702 |
|
|
|
|
Current U.S.
Class: |
705/34 ;
705/40 |
Current CPC
Class: |
G06Q 20/14 20130101;
G06Q 20/102 20130101; G06Q 30/04 20130101; G06Q 40/02 20130101;
Y10S 707/95 20130101 |
Class at
Publication: |
705/34 ;
705/40 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. A method comprising: transmitting, by a source system to a
remittance processing system, a payment request on behalf of a
payor; responsive to the transmission of the payment request,
receiving, by the source system from the remittance processing
system, at least one payment instruction generated by the
remittance processing system, wherein the generation of the at
least one payment instruction includes the remittance processing
system (i) identifying a payee in a merchant database based, at
least in part, on information in the payment request, (ii)
retrieving information associated with the payee from the merchant
database, and (iii) altering an account number associated with the
payment request according to at least one alteration rule
associated with the payee, and wherein the at least one payment
instruction includes the retrieved information or the altered
account number; and issuing, by the source system, a payment
associated with the payment request in accordance with the at least
one payment instruction received from the remittance processing
system, wherein the payment is made to the identified payee and
includes the altered account number.
2. The method of claim 1, wherein the issued payment is an
electronic credit transmitted from the source system to an external
entity.
3. The method of claim 1, wherein the generation of the at least
one payment instruction further includes the remittance processing
system determining a remittance center of the payee to which the
payment is to be sent, and wherein the payment is directed to the
determined remittance center.
4. The method of claim 1, wherein identifying the payee in the
merchant database based, at least in part, on information in the
payment request includes generating an eleven-digit zip code from
the information in the payment request and searching for stored
information associated with the payee using at least the
eleven-digit zip code.
5. A method comprising: receiving, by a remittance processing
system from a source system, a payment request on behalf of a
payor; responsive to receiving the payment request, generating, by
the remittance processing system, at least one payment instruction,
wherein the generation of the at least one payment instruction
includes (i) identifying a payee in a merchant database based, at
least in part, on information in the payment request, (ii)
retrieving information associated with the payee from the merchant
database, and (iii) altering an account number associated with the
payment request according to at least one alteration rule
associated with the payee, and wherein the at least one payment
instruction includes the retrieved information or the altered
account number; and transmitting, by the remittance processing
system to the source system, the at least one payment instruction,
wherein the source system issues a payment associated with the
payment request in accordance with the at least one payment
instruction, and wherein the payment is made to the identified
payee and includes the altered account number.
6. The method of claim 5, wherein the generation of the at least
one payment instruction further includes determining a remittance
center of the payee to which payment is to be sent, and wherein the
payment is directed to the determined remittance center.
7. The method of claim 5, wherein the issued payment is an
electronic credit transmitted from the source system to an external
entity.
8. The method of claim 5, wherein identifying the payee in the
merchant database based, at least in part, on information in the
payment request includes generating an eleven-digit zip code from
the information in the payment request and searching for stored
information associated with the payee using at least the
eleven-digit zip code.
9. A system comprising: a communications interface; a processor in
communication with the communications interface, wherein the
processor is configured to execute software instructions to:
transmit, via the communications interface to a remittance
processing system, a payment request on behalf of a payor,
responsive to the transmission of the payment request, receive, via
the communications interface from the remittance processing system,
at least one payment instruction generated by the remittance
processing system, wherein the generation of the at least one
payment instruction includes the remittance processing system (i)
identifying a payee in a merchant database based, at least in part,
on information in the payment request, (ii) retrieving information
associated with the payee from the merchant database, and (iii)
altering an account number associated with the payment request
according to at least one alteration rule associated with the
payee, and wherein the at least one payment instruction includes
the retrieved information or the altered account number; and issue
a payment associated with the payment request in accordance with
the at least one payment instruction received from the remittance
payment processor, wherein the payment is made to the identified
payee and includes the altered account number.
10. The system of claim 9, wherein the generation of the at least
one payment instruction further includes the remittance processing
system determining a remittance center of the payee to which
payment is to be sent, and wherein the payment is directed to the
determined remittance center.
11. The system of claim 9, wherein the issued payment is an
electronic credit transmitted by the processor via the
communications interface to an external entity.
12. The system of claim 9, wherein the identification of the payee
in the merchant database based, at least in part, on information in
the payment request includes generating an eleven-digit zip code
from the information in the payment request and searching for
stored information associated with the payee using at least the
eleven-digit zip code.
Description
CROSS REFERENCES TO RELATED APPLICATIONS
[0001] The present application is a continuation of co-pending U.S.
patent application Ser. No. 09/010,193, filed Jan. 21, 1998, and
entitled DUAL SOURCE REMITTANCE PROCESSING, the contents of which
is incorporated by reference herein in its entirety. Additionally,
the present application is related to U.S. patent application Ser.
No. 08/994,047, filed Dec. 19, 1997, and entitled AN ELECTRONIC
BILL PAYMENT SYSTEM WITH MERCHANT IDENTIFICATION (now U.S. Pat. No.
7,296,004); U.S. patent application Ser. No. 08/994,046, filed on
Dec. 19, 1997, and entitled "AN ELECTRONIC BILL PAYMENT SYSTEM WITH
ACCOUNT NUMBER SCHEMING" (now U.S. Pat. No. 6,327,577); and U.S.
patent application Ser. No. 08/994,363, filed on Dec. 19, 1997, and
entitled "AN ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT RANGING"
(now abandoned).
TECHNICAL FIELD
[0002] The present invention relates to electronic commerce. More
particularly, the present invention relates to an improved
electronic bill payment system.
BACKGROUND ART
[0003] It has been common for many years for consumers to pay bills
by way of a personal check written by the consumer to the order of
an entity and delivered to that entity by mail or in person. With
the proliferation of computers interconnected to computer networks,
particularly the Internet, consumers can now pay bills
electronically. However until recently it was not possible for a
consumer, using a computer terminal, to interact with a single
payment system capable of paying all the consumer's bills whether
by electronic means or by a paper check. Such a system now exists
in the form of a consolidated bill payment system as described by
Kight, et al. in U.S. Pat. No. 5,383,113, entitled SYSTEM AND
METHOD FOR ELECTRONICALLY PROVIDING CUSTOMER SERVICES INCLUDING.
PAYMENT OF BILLS, FINANCIAL ANALYSIS AND LOANS.
[0004] Although the consolidated bill payment system described by
Kight, et al. significantly advanced the state of the art, it did
not focus on several problems which may arise in implementing a
consolidated bill payment system capable of automatically paying
consumer bills to merchants.
[0005] A typical state of the art electronic bill payment system is
established by a financial institution or third party to provide
subscribing customers with the capability to electronically pay
registered merchants. Present day electronic bill payment systems
operate in an integrated manner to collect payment requests
electronically from consumers, process those requests to render
them suitable for payment, and then pay the registered merchants,
i.e., merchants listed in the system database. Hence, using present
day systems, each has to establish relationships with both
customers and merchants.
[0006] Developing and implementing a bill payment system has
significant costs. First, a relationship has to be established with
each merchant. Furthermore, special formatting requirements, and
other rules and procedures required by each merchant for presenting
payment data in a form the merchant system can process
automatically must be determined and complied with. One of the
features most desirable in any consolidated electronic bill payment
system is that a consumer be allowed to pay any merchant to which
the consumer owes a bill. Ultimately, this means that each
conventional bill payment system may have hundreds of thousands of
merchants in a database. Each bill payment entity must establish
relationships with these merchants and comply with their special
rules and procedures for the transfer of payment data. This is an
expensive and time consuming process. Thus, it would be beneficial
to provide a way to reduce the time and expense which must now be
spent by every bill payment entity to implement a consolidated bill
payment system.
[0007] Another problem is that consumers or data entry personnel
sometimes make mistakes in entering payment data required by the
bill payment system. Such a case arises when a consumer's account
number with a merchant is incorrectly entered. The payment system
must submit a correct account number to the merchant who will use
this account number to associate the payment with the consumer.
Thus, a technique is needed to validate the submitted consumer's
account number.
[0008] A data entry person may also enter payment data which
incorrectly specifies the merchant's name or parts of the
merchant's address. It has been found that merchant information
such as the merchant name, address, zip code are typically mangled
at the data entry stage. It has been further observed that errors
will often be made upon entry of the zip code. The merchant's name,
address, and zip code is typically required by the payment system
in order to, for example, retrieve merchant records from the
merchant database. If this data is incorrect, the payment system
may be unable to retrieve the correct merchant's record for
processing a payment. Thus, a technique is needed to correctly
identify a merchant record notwithstanding the submission of
erroneous merchant data.
[0009] A consolidated bill payment system must also have the
capability to properly remit payments to the same merchant at more
than one remittance center. Commonly a large commercial merchant,
(e.g., shoe company, Sears) will have several remittance centers
distributed geographically so that customers can submit bills to a
center within their location. Thus, a technique is required to
ensure that consumer payments are remitted to the proper one of
multiple remittance centers associated with the same.
[0010] Advantageously, a consolidated payment system must also be
able to handle the different processing formats and requirements of
numerous separate merchant accounting systems. For example, each
merchant's account system may require payment information, such as
consumer account numbers, in a format different than that submitted
by the consumer. For example, many merchant accounting systems will
only accept an account number with some portion of a consumer's
last name or the consumer's zip code appended to the end of the
account number presented by the customer.
[0011] A merchant account system may even require an altered
consumer account number which uniquely identifies the consumer. For
example, two consumers, e-g., spouses, may have identical account
numbers, but the merchant accounting system may designate the
account of each consumer uniquely, such as by combining the account
number with the prospective customer's name. Additionally, it is
not unusual for a merchant to have different account numbers for a
single customer. For example, an account number on an invoice which
goes out electronically may be different from an account number for
the same customer which goes out as a paper transaction.
[0012] Thus, a consolidated bill payment system must be able to
handle the various formats required by the merchant accounting
system of each merchant. Accordingly, a technique is required to
transform payment data received from the consumer into a form
compatible with a merchant's accounting system.
OBJECTIVES OF THE INVENTION
[0013] Accordingly, it is an object of the present invention to
provide an improved technique for automatically paying bills to any
merchant on behalf of consumers.
[0014] It is a further object of the present invention to provide a
technique which allows individual bill payment entities to
implement consolidated bill payment system with greater
efficiency.
[0015] It is a further object of the present invention to provide a
technique for correcting erroneous bill payment data received from
customers. In particular, it is an object of the present invention
to correctly identify a merchant record based on received
information which may include erroneous data.
[0016] It is still a further object of the present invention to
provide a technique for furnishing payment information, including a
payor's account number with a merchant, in a format acceptable to a
particular merchant's accounting system.
[0017] It is another object of the present invention to provide a
technique for validating a consumer's account number with a
merchant.
[0018] It is another object of the present invention to provide a
technique for ensuring payments are remitted to the proper
remittance center.
[0019] Additional objects, advantages, novel features of the
present invention will become apparent to those skilled in the art
from this disclosure, including the following detailed description,
as well as by practice of the invention. While the invention is
described below with reference to preferred embodiment(s), it
should be understood that the invention is not limited thereto.
Those of ordinary skill in the art having access to the teachings
herein will recognize additional implementations, modifications,
and embodiments, as well as other fields of use, which are within
the scope of the invention as disclosed and claimed herein and with
respect to which the invention could be of significant utility.
SUMMARY OF THE INVENTION
[0020] In order to solve the limitation of present art electronic
bill payment systems, the present invention provides a method and
apparatus for electronically processing bill payment requests where
respective sets of payment requests are received electronically
from a plurality of independent sources, each set of payment
requests corresponding to an associated set of payors requesting
payments to a plurality of payees. The payment requests are
processed at a single remittance processing system having a
database including payee information for each of the plurality of
payees to generate payment directions for paying the plurality of
payees in accordance with the processed payment requests.
[0021] A source may include any computer or network of computers
capable of collecting payment requests from consumers, and may be,
for example, a CheckFree processing center, a financial
institution, or some other payment processing center. Typically a
payment request would be a record containing whatever information
is needed to process a particular payment.
[0022] Beneficially, the sets of payment requests from payors are
sent from the sources to the bill payment system as batch files.
Preferably, the bill payment system can normalize batch files
received from the sources to correspond to a single normalized
format.
[0023] In yet another aspect of the present invention, each of the
received payment requests includes payor payment information, and
the payment information other than a received zip code is processed
to identify an eleven digit zip code for the payee to be paid. The
database is then accessed by the eleven digit zip code to locate
payee information on the payee to be paid.
[0024] In a still further aspect of the present invention, a payee
has a plurality of payment remittance centers and a payment request
includes information identifying a payor account number with the
payee. The account number is processed to select one of the
plurality remittance centers and payment is directed to the
selected remittance center for the payee.
[0025] In a further aspect of the present invention, each of the
payment requests includes a payor's account number with a payee.
Alteration rules are stored corresponding to a payee account number
format and one of the received account numbers is transformed into
an altered account number according to the alteration rules.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 is a system overview of an automated bill payment
system in accordance with the present invention.
[0027] FIG. 2A is a diagrammatical representation of an electronic
bill payment system according to the present invention.
[0028] FIG. 2B is a diagrammatical representation of an electronic
bill payment system according to the present invention.
[0029] FIG. 3 is a flow chart illustrating merchant identification
in accordance with the present invention.
[0030] FIG. 4 is a block diagram illustrating accesses to the
merchant database during merchant identification in accordance with
the present invention.
[0031] FIG. 5 is a flow chart illustrating account ranging in
accordance with the present invention.
[0032] FIG. 6 is a flow chart illustrating account scheming in
accordance with the present invention.
PREFERRED EMBODIMENT(S) OF THE INVENTION
[0033] FIG. 1 generally depicts a bill payment system including
consumer systems (i.e., payors) 8, merchant systems (i.e., payees)
4, source systems 7, a remittance payment processor 5 (RPP) 3,
merchant bank systems 5, and consumer bank systems 6.
[0034] A consumer system 8 provides the consumer (i.e. payor) with
an interface to the RPP 3 via a source system 7 and typically would
be a personal computer located at the consumer's residence, but
could possibly be another electronic device such as a phone or
specialized box containing bill payment software. A consumer is an
individual or other entity, e.g., a corporation, for whom payments
are actually made and whose account will be debited by the amount
of the payment.
[0035] Source systems 7 represent any computer or network of
computers capable of collecting payment requests from one or more
consumer systems 8, and may be, for example, a CheckFree processing
center 7B, a financial institution processing center 7A, or a third
party payment processing center 7C.
[0036] Merchant systems 4 are computer systems typically owned by
merchants for carrying out the bill payment process. Merchants are
the persons or other entities to whom payments are made via the
bill payment system on behalf of consumers. Merchants may include
department stores, the phone company, the paper boy, a credit card
company, as well as other persons and entities to whom payments are
owed by one or more of consumers. Merchants have accounts with
merchant bank systems 5 to which payments made on behalf of
consumers are forwarded for deposit.
[0037] Consumer bank systems 6 either physically or electronically
hold funds on account for consumers. These accounts are debited by
the amount of any payments made to merchants on behalf of the
consumers.
[0038] A network 1 connects the above-stated entities making
communications between them possible. The network may be of any
type capable of facilitating the flow of information among the
various entities. It could, for example, be a public
telecommunication network, the Internet, or other type of
communication network. The network 1 may also be physically
realized as one or more private or public networks. For example, in
one possible embodiment, consumer systems 8 are coupled to a source
systems 7 through one network and the source coupled to the RPP 3
through another separate network.
[0039] FIGS. 2A-2B illustrate an overview of the process flow of a
bill payment system. As shown in FIG. 2A, source systems 7A-C
collect payment requests from consumer systems 8A-8C over networks
1A-1C. Typically, each source has its own consumer base of
subscribed consumers. Thus, Referring to FIG. 2A, Bank Source
System 7A collects payment requests from consumer system Al through
consumer system AN, denoted as consumer systems 8A, where there are
N subscribed consumers, over network 1A. Similarly, CheckFree
Source System 7B collects payment requests from consumer system B1
through consumer system BM, denoted as consumer systems 8B, where
there are M subscribed consumers, over network 1B. Similarly, Third
Party Source System 7C collects payment requests from consumer
system C1 through consumer system CP, denoted as consumer systems
8C, where there are P subscribed consumers, over network 1C.
[0040] In FIG. 2A, each source is depicted as receiving payment
requests from consumers over its own wide area network 1A-1C.
However, other network configurations are possible. For example,
the payment requests could be received over a single network, such
as the Internet. Furthermore, the networks may be private or public
(e.g., the Internet).
[0041] A payment request contains payment information for a
consumer which will include several different types of information,
such as the consumer account number, the merchant name, and the
merchant address.
[0042] RPP 3 receives payment requests from each of the sources
7A-7C via networks 1D-1F. Typically, each source collects the
payment requests, processes the requests into batch files, and
transmits the batch files over networks 1D-1F. In FIG. 2A, each
source is depicted as connected to the RPP 3 shown in FIG. 2B over
a wide area network. However, other network configurations are
possible including the possibility that networks 1D-1F are a single
network, and the networks may be private or public (e.g., the
Internet).
[0043] The RPP 3, as further detailed in FIG. 2B, includes a memory
16 storing programmed instructions for carrying out the functions
of the RPP, a processor 17 for executing these instructions, and a
merchant database 18 storing information associated with the
merchants 4.
[0044] RPP 3 includes an input port 10 which accepts and collects
together the payment requests from each of the respective sources
7. Preferably, RPP 3 also includes a normalization unit 9 which
accepts the collected payment requests from input port 10, each
payment request in a particular source's format and automatically
converts the received format to a format compatible to the RPP 3.
Thus, each source does not have to alter its own formatting or
procedures in order to have payment requests processed by the RPP
3.
[0045] The RPP 3 processes the received payment information from
the payment requests, and passes payment instructions to a merchant
payment processing system 25 which processes the payment
instructions in processor 24 in accordance with programmed
instructions on memory 23, and makes payments to merchant systems 4
either directly or indirectly. It should be understood that the
merchant payment processing system 25 could be multiple systems
which respectively reside with each source 7, a single system (as
shown) which resides with the RPP 3 or as a separate stand-alone
system controlled by an entirely separate entity connected to the
RPP 3 by a network. Hence each source processing system 7 collects
payment requests made by consumers in its consumer base and the one
or more merchant payment systems 25 makes payments on behalf of
these consumers 8 in accordance with payment directions from the
centralized RPP 3.
[0046] Payment is made from the payment processor 25 to merchant
system 4 or merchant bank system 5 electronically through networks
1G-1J, or alternately can be transmitted by paper through checks 32
and drafts 34. Payment advice reflecting the payment can also be
directly sent by network 1G to merchant system 4. The payment
information is presented to the applicable merchant electronically
in a form that the merchant system 4 can process to update the
merchant's records.
[0047] As shown in FIG. 2B, one possible mode of payment to a
merchant via merchant bank 5 is electronic funds transfer through
the Federal Reserve Automated Clearing House (ACH) Network 1H.
Another electronic payment avenue is through the Mastercard RPS
Network 1J. Additionally, payment can also be made
non-electronically to a merchant by a check 32 or a draft 34
printed on laser printer 28. Payment advice can alternatively be
delivered through Fax 22 or through the telephone network 11. Thus,
by the above described process, the bill payment system of the
present invention pays bills to merchants according to payment
requests received by customers through multiple sources.
[0048] Now taking a closer look at the RPP processor 17, the
RPP-stores or processes several different record types necessary to
the bill payment process. A merchant record contains all necessary
information needed to forward a payment. This includes a merchant
name, address, and zip code. A. consumer record includes' a
consumer name, address, zip code, and consumer account number. A
payment record will contain information related to payment,
including payee identification, consumer identification, and the
dollar amount of the transaction. The merchant records are stored
in a merchant database 18. All other records as well as programmed
instructions which direct the operation of the RPP are stored in a
memory 16. The memory 16 could also store the merchant database 18
if desired.
[0049] After receiving payment requests from sources 7, the RPP 3
periodically initiates a payment cycle 20 which process the records
to generate information which will be used by the payment
processing system 25 to credit merchant accounts and advise the
merchant systems of the payments. The processing flow of the
billing cycle contains, in addition to other processes, three
particularly important processes necessary for successful
processing of each payment request. These processes are merchant
identification 19a, account ranging 19b, and account scheming 19c,
typically performed in this order. In the first step of processing
a payment request, the processor 17 attempts to identify a merchant
in the merchant database 18 based on information in the payment
request. In the second step, the processor 17 will attempt to
determine a remittance center of the merchant to which the payment
and/or payment information is to be sent. If a candidate remittance
center is identified, the system enters the third stage of
processing, account scheming. In account scheming, the processor 17
attempts to normalize a user account with a merchant according to
the merchant's rules. If account scheming fails, the system will
return to the account ranging process to attempt to identify
another candidate remittance center, and from there, again into
account scheming.
[0050] Although the above described payment cycle is a preferable
embodiment of the RPP, a payment cycle can include merchant
identification 19a, account ranging 19b, and/or 19c, in any order
or combination. In addition, these processes may be performed
independently, and could be performed individually outside the RPP.
These three processes will now be described in further detail
herein referring to FIGS. 3-6.
[0051] FIG. 3 illustrates merchant identification. Using merchant
identification, the RPP 3 is able-to retrieve the correct merchant
record from merchant database 18 based on a consumer's payment
request submitted with possibly erroneous merchant name and address
information, e-g., street address, city, state, zip code. It has
been observed that data entry operators will often make errors in
the merchant's street address and zip code. The RPP 3 is capable of
mapping the mangled merchant information supplied in the payment
request into the proper merchant record in the merchant database 18
notwithstanding the errors in the merchant information. Merchant
identification as described herein, can be used in any
implementation where merchant information is likely to contain
errors and must be mapped into an existing merchant record in the
merchant database.
[0052] RPP 3 initiates merchant identification by step 60 which
retrieves a payment record from one of the payment records
previously submitted by the source 7. At step 62, the RPP first
attempts to retrieve a merchant record from the merchant database
18 by matching the merchant id included in the payment record
against the records of the merchant database 18. If there is a
match, then at step 63 processing of the payment record continues
to the payment directions stage 64. The payment directions stage is
where the RPP determines where to send payments. This stage
includes account ranging discussed below which determines the
remittance center to which payment gets sent. If there is no match
at step 63, the RPP continues to step 65. At step 65, the RPP maps
the merchant's merchant name and address, excluding the provided
street address and zip code, into an eleven digit zip code. That
is, the RPP produces an eleven digit zip code based on merchant
name, city, and state in the payment information. In order to avail
the merchant information which the inventors have determined to be
mostly likely to contain errors, the received merchant street
address and zip code are not considered. Hence, in step 65 the RPP
3 identifies an eleven digit zip code based only on the merchant's
name, city, and state.
[0053] Step 65 of merchant identification uses the indexing
structure shown in FIG. 4 to access one or more records from the
merchant database 18. In step 65, referring to FIG. 4, the RPP 3
forms an 11 digit zip code index 82 and compares this index to
index 84 in order to retrieve a merchant record in merchant
database 18. It may be possible that there is more than one
merchant at a location identified by an eleven digit zip code. For
example, there could be a remittance processing center on the floor
of-the building identified by the eleven digit zip code which
handles payments for several merchants 4. In such a case, the RPP
differentiates the correct merchant record from other possibly
correct merchant records associated with the same eleven digit zip
code by, after identifying merchant records indexed to the same
eleven digit zip code, comparing some portion of the merchant's
name, e.g., the first five characters with the characters of each
merchant's name which has been combined with the application zip
code in the merchant index. The RPP 3 is thereby able to uniquely
identify the proper merchant record.
[0054] If step 65 identifies a unique merchant record then 5 there
is an exact match and at step 66 processing continues to step 64.
However, if step 65 retrieves more than one merchant forming a
group of records 86, (see FIG. 4) then at step 66 processing
continues to step 67. At step 67, the RPP 3 will attempt to match
one or more characters of the merchant's name 83 against the
records 86 to identify a merchant record. If a match is found,
processing continues at step 68 to the payment directions stage 64.
If there is no match, then at step 68 the program will continue to
step 69 where the RPP will handle the unmanaged merchant. If there
is no merchant, the system may have provisions at step 69 for
adding the merchant to the merchant database 18.
[0055] FIG. 5 illustrates a payment direction stage, as performed
in the preferred embodiment of the present invention, in which the
RPP attempts to determine a remittance center to which payment is
sent. The RPP determines a remittance center based on one or more
of the following identification rules: 1) length of account number,
2) merchant zip code, 3) merchant name, and 4) account ranging.
Each rule has in common that it identifies the remittance center
based on some factor of the payment information.
[0056] In FIG. 5, the RPP 3 processes the payment record presented
in step 51 to determine one of a plurality of remittance centers
associated with the applicable merchant in which to make payment.
In step 53, the RPP chooses one, of the above-mentioned four rules
and at step 55 attempts to identify a remittance center. If a
remittance center is found at step 56, then the RPP directs payment
to that remittance center 58. If the RPP is unsuccessful in
determining a remittance center, the RPP cycles back to step 53 and
picks a new rule for identification. By this process, the system
cycles through all combinations of rules that identify remittance
centers for the merchant.
[0057] In account ranging, the correct remittance center is
determined based on some characteristic of the consumer's account
number. Typically a large merchant, such as credit card company
will have multiple remittance centers to which respective consumer
payments must be submitted. The payment record contains information
which may be used to identify a remittance center besides an
account number, such as an area code of the payor's telephone
number. A telephone phone utility might include each consumer's
area code in the consumer's account number and require payments
from all consumers within a particular area code be directed to a
particular one of multiple remittance centers. A credit card
company may require that payments from all consumers having the
same first six digits in their account numbers be made to the same
remittance center.
[0058] The payment direction process illustrated in FIG. 5 is a
preferred embodiment for determining payment direction. In this
embodiment, the payment direction process includes account ranging
as one of four possible methods of identifying a remittance center.
However, in other embodiments, account ranging may be used in
different combinations, or independently.
[0059] FIG. 6 illustrates the steps for account scheming. In
certain cases, the consumer account number received by the RPP as
part of the payment information may contain errors. Hence, the RPP
has no way of checking the account number against a previously
stored account number associated with the applicable consumer to
verify the accuracy of the received information.
[0060] Using account scheming, the RPP receives, in step 12a, the
consumer account number as part of the payment record. In step 42,
the RPP checks to validate the account number. Then in step 46, the
RPP alters the account number to correspond to a format required by
a merchant's system 4 for processing.
[0061] More particularly, the RPP validates and alters the consumer
account number by storing separate business rules for each merchant
which identify the expected general format for any consumer account
number associated with that merchant. These business rules are
stored as validation templates 40 in merchant database 18 for each
merchant. The account number received from the consumer is checked
against the validation template to validate that the account number
conforms to the general account number format to which an account
number associated with the applicable merchant must conform. For
example, the validation template for a merchant such as a credit
card company may require an account number begin with the numbers
"43" and be 18 digits long. Additionally, for some merchants the
validation template will have check digit requirements. That is,
the validation template can be used to confirm that the received
consumer account number conforms to a check digit after being run
through a specific algorithm.
[0062] In operation, the RPP 3 performs, in accordance with
programmed instructions stored on the memory 16, the validation
procedure by comparing in step 42 the received consumer account
number for the applicable merchant received in step 12a with the
validation template, say 40, for that merchant to test the validity
of the account number. If that account number is not valid, the
payment directions are rejected as not valid in step 43; otherwise,
the account number is considered valid.
[0063] Once the account number has been validated, it is then
modified in step 46 so as to conform to alteration rules 44 for the
applicable merchant. The alteration rules 44 are also stored in
database 18. The alteration rules 44 relate to the format of the
consumer's account number in which the applicable merchant system
requires to process a consumer's payment. Typically, alteration
rules would specify an altered account number which includes a
portion of a payor's name with the account number, a portion of the
payor's address with the account number, or a portion of the
payor's zip code with the account number. Alteration, by the RPP 3
involves notifying the received account number which will be
furnished, along with payment, to the merchant. For instance, some
merchant systems require that the consumer's account number always
end in "120". Hence, in such a case, the RPP 3, in accordance with
programmed instructions stored on the memory 16, modifies the
received account number to append "120" to the end of the
alpha-numeric sequence of the received account number. Once the
account number has been modified so as to conform to the format
required by the merchant system, the altered account number 47 is
then transmitted from the RPP 3 to the merchant 4 via the network
1, along with the payment, in step 48.
[0064] It will also be recognized by those skilled in the art that,
while the invention has been described above in terms of one or
more preferred embodiments, it is not limited thereto. Various
features and aspects of the above described invention may be used
individually or jointly. Further, although the invention has been
described in the context of its implementation in a particular
environment and for particular purposes, e.g. a bill payment
system, those skilled in the art will recognize that its usefulness
is not limited thereto and that the present invention can be
beneficially utilized in any number of environments and
implementations. Accordingly, the claims set forth below should be
construed in view of the full breadth and spirit of the invention
as disclosed herein.
[0065] The present invention is not to be limited in scope by the
specific embodiments described herein. Indeed, various
modifications of the present invention, in addition to those
described herein, will be apparent to those of skill in the art
from the foregoing description and accompanying drawings. Thus,
such modifications are intended to fall within the scope of the
appended claims.
* * * * *