U.S. patent application number 10/020691 was filed with the patent office on 2002-09-12 for bar coded bill payment system and method.
Invention is credited to Krouse, Lou, Meyer, John.
Application Number | 20020128967 10/020691 |
Document ID | / |
Family ID | 24962246 |
Filed Date | 2002-09-12 |
United States Patent
Application |
20020128967 |
Kind Code |
A1 |
Meyer, John ; et
al. |
September 12, 2002 |
Bar coded bill payment system and method
Abstract
A system and method for payment is provided, wherein consumers
pay their bills at supermarkets, large retail chain, or other
stores and receive immediate credit from billers for their
payments. Payments are made using a bar code printed on the bill or
sent to the consumer, e.g., by fax or email. The biller receives
good payment funds, deposited directly into his bank account, and
error-free electronic payment data for consumer bill payments by
the very next business day. The biller backdates the received bill
payments to the time and date the consumer actually paid,
regardless of the time that the payment data takes to post to the
biller's accounts receivable system. In another aspect, a method
for person-to-person money transfers is provided, wherein a bar
coded deposit slip, card, or other printout permits a sender to
remit finds directly into a receiver's bank account, and such funds
are quickly accessible for withdrawal at a nearby automated teller
machine, or for a debit card purchase.
Inventors: |
Meyer, John; (Orange,
CA) ; Krouse, Lou; (Rancho Palos Verdes, CA) |
Correspondence
Address: |
Kevin M. Drucker
Hayes, Soloway, Hennessey, Grossman & Hage, P.C.
130 W. Cushing Street
Tucson
AZ
85701
US
|
Family ID: |
24962246 |
Appl. No.: |
10/020691 |
Filed: |
December 14, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10020691 |
Dec 14, 2001 |
|
|
|
09737011 |
Dec 14, 2000 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 30/04 20130101;
G06Q 20/04 20130101; G06Q 20/385 20130101; G06Q 40/00 20130101;
G06Q 20/10 20130101; G06Q 20/14 20130101; G06Q 20/042 20130101;
G06Q 20/102 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. A bill payment system comprising: a payee transmitting or
transferring to at least one payor a unique bar code comprising
data identifying at least said payee and said payor; and a scanning
apparatus configured to scan a printed representation of said bar
code, said scanning apparatus being capable, based on information
stored in said bar code and a payment made by said payor, of
transmitting funds or initiating a funds transfer to said payee in
a predetermined amount and transmitting data or initiating a data
transfer to said payee regarding said payment.
2. A system as claimed in claim 1, wherein said funds are
transmitted or transferred as an electronic funds transfer or via
the Automated Clearing House.
3. A system according to claim 1, wherein said apparatus is adapted
to print a receipt evidencing said payment.
4. A system as claimed in claim 1, wherein said bar code comprises
a plurality of validation levels.
5. A system as claimed in claim 1, wherein said data comprises the
date and time said payor makes said payment.
6. A system as claimed in claim 1, wherein said apparatus is
integrated into a point-of-sale system.
7. A system as claimed in claim 1, wherein said apparatus is in a
location selected from the group consisting of: grocery store,
convenience store, supermarket, chain store, post office, drug
store, government office, location where goods are sold, location
where services are sold, bank, and retail store.
8. A system as claimed in claim 1, wherein said payee transmits or
transfers said bar code to said payor by at least one method
selected from the group consisting of: via facsimile transmission
to or from a computer, via facsimile machine, via email, via file
transfer protocol (FTP), via hypertext markup language (HTML), via
extended markup language (XML), via hypertext transport protocol
(HTTP), via modem, via the Internet, via a wide-area network (WAN),
via a local-area network (LAN), via diskette, and via removable
storage medium.
9. A system as claimed in claim 1, further comprising an automatic
caller response system and/or Internet access to said data by said
payee and/or said payor.
10. A system as claimed in claim 1, wherein said system is adapted
to transmit or initiate transfer of notification to said payee of
said payment by said payor via facsimile, email, and/or custom
electronic procedure.
11. A system as claimed in claim 1, wherein said payment is made by
cash, check, debit card or credit card; and wherein said
predetermined amount of funds transmitted or transferred to said
payee is not dependent on whether payment is made by cash, check,
debit card or credit card.
12. A system as claimed in claim 1, wherein said payee further
comprises accounting software, wherein said system is adapted to
transmit or initiate transfer of said data to said payee via said
accounting software.
13: A bill payment method comprising: transmitting or transferring
to at least one payor a unique bar code comprising data identifying
at least said payee and said payor; and permitting a third party to
scan a printed representation of said bar code and, based on the
identifying information of said bar code and a payment made by said
payor, to transmit funds or initiate a funds transfer to said payee
in a predetermined amount and transmit data or initiate a data
transfer to said payee regarding said payment.
14. A method as claimed in claim 13, wherein said transmission or
transfer of funds is an electronic funds transfer or via the
Automated Clearing House.
15. A method as claimed in claim 13, further comprising printing a
receipt evidencing said payment.
16. A method as claimed in claim 13, wherein said bar code
comprises a plurality of validation levels.
17. A method as claimed in claim 13, wherein said data comprises
the date and time said payor makes said payment.
18. A method as claimed in claim 13, wherein said third party
scanning and/or transmitting or transferring funds and data is
performed via an apparatus integrated into a point-of-sale
system.
19. A method as claimed in claim 13, wherein said third party is in
a location selected from the group consisting of: grocery store,
convenience store, supermarket, chain store, post office, drug
store, government office, location where goods are sold, location
where services are sold, bank, and retail store.
20. A method as claimed in claim 13, wherein said step of
transmitting or transferring said bar code to said payor occurs by
at least one method selected from the group consisting of: via
facsimile transmission to or from a computer, via facsimile
machine, via email, via file transfer protocol (FTP), via hypertext
markup language (HTML), via extended markup language (XML), via
hypertext transport protocol (HTTP), via modem, via the Internet,
via a wide-area network (WAN), via a local-area network (LAN), via
diskette, and via removable storage medium.
21. A method as claimed in claim 13, further comprising permitting
access to said data by said payee and/or said payor via an
automatic caller response system and/or the Internet.
22. A method as claimed in claim 13, wherein said system is adapted
to transmit or initiate transfer of notification to said payee of
said payment by said payor via facsimile, email, and/or custom
electronic procedure.
23. A method as claimed in claim 13, wherein said payment is made
by cash, check, debit card or credit card; and wherein said
predetermined amount of funds transmitted or transferred to said
payee is not dependent on whether payment is made by cash, check,
debit card or credit card.
24. A method as claimed in claim 13, wherein said payee further
comprises accounting software, wherein said step of transmitting or
transferring said data to said payee occurs via said accounting
software.
25. A money transfer system comprising: a printed bar code
comprising data identifying at least an account number
corresponding to an account to which a deposit can be made and a
destination payment network corresponding to said account; and a
scanning apparatus configured to scan said bar code, said scanning
apparatus being capable, based on information stored in said bar
code and a payment made by a payor, of transmitting funds or
initiating a funds transfer in a predetermined amount to said
account.
26. A money transfer system as claimed in claim 25, wherein said
apparatus is further capable of transmitting data or initiating a
data transfer to a payee regarding said payment.
27. A money transfer system as claimed in claim 25, wherein said
destination payment network comprises a plurality of organizations
having a common account numbering scheme.
28. A money transfer system as claimed in claim 27, wherein at
least one said organization is identified in said bar code by an
American Bankers Association (ABA) number.
29. A money transfer system as claimed in claim 25, wherein said
printed bar code is printed on at least one medium selected from
the group consisting of: deposit slip, debit card, credit card,
bank card, affinity card, smart card, card bearing a magnetic
stripe, card bearing at least one name corresponding to said
account number, identification card, plastic or paper card, or
sheet of paper.
30. A money transfer system as claimed in claim 25, wherein said
funds are transmitted or transferred as an electronic funds
transfer or via the Automated Clearing House.
31. A money transfer system as claimed in claim 25, wherein said
apparatus is adapted to print a receipt evidencing said
payment.
32. A money transfer system as claimed in claim 25, wherein said
bar code comprises a plurality of validation levels.
33. A money transfer system as claimed in claim 26, wherein said
data comprises the date and time said payor makes said payment.
34. A money transfer system as claimed in claim 25, wherein said
apparatus is integrated into a point-of-sale system.
35. A money transfer system as claimed in claim 25, wherein said
apparatus is in a location selected from the group consisting of:
grocery store, convenience store, supermarket, chain store, post
office, drug store, government office, location where goods are
sold, location where services are sold, bank, and retail store.
36. A money transfer system as claimed in claim 25, wherein said
payor receives said bar code by at least one method selected from
the group consisting of: via facsimile transmission to or from a
computer, via facsimile machine, via email, via file transfer
protocol (FTP), via hypertext markup language (HTML), via extended
markup language (XML), via hypertext transport protocol (HTTP), via
modem, via the Internet, via a wide-area network (WAN), via a
local-area network (LAN), via diskette, and via removable storage
medium.
37. A money transfer system as claimed in claim 26, further
comprising an automatic caller response system and/or Internet
access to said data by said payee and/or said payor.
38. A money transfer system as claimed in claim 25, wherein said
system is adapted to transmit or initiate transfer of notification
to a payee of said payment by said payor via facsimile, email,
and/or custom electronic procedure.
39. A money transfer system as claimed in claim 25, wherein said
payment is made by cash, check, debit card or credit card; and
wherein said predetermined amount of funds transmitted or
transferred to the account corresponding to said account number is
not dependent on whether payment is made by cash, check, debit card
or credit card.
40. A money transfer system as claimed in claim 26, further
comprising accounting software, wherein said system is adapted to
transmit or initiate transfer of said data to said payee via said
accounting software.
41. A method of transferring money, said method comprising:
scanning a printed bar code comprising data identifying at least an
account number corresponding to an account to which a deposit can
be made and a destination payment network corresponding to said
account; and transmitting finds or initiating a funds transfer,
based on information stored in said bar code and a payment made by
a payor, in a predetermined amount to said account.
42. A method as claimed in claim 41, further comprising
transmitting data or initiating a data transfer to a payee
regarding said payment.
43. A method as claimed in claim 41, wherein said destination
payment network comprises a plurality of organizations having a
common account numbering scheme.
44. A method as claimed in claim 43, wherein at least one said
organization is identified in said bar code by an American Bankers
Association (ABA) number.
45. A method as claimed in claim 41, wherein said printed bar code
is printed on at least one medium selected from the group
consisting of: deposit slip, debit card, credit card, bank card,
affinity card, smart card, card bearing a magnetic stripe, card
bearing at least one name corresponding to said account number,
identification card, plastic or paper card, or sheet of paper.
46. A method as claimed in claim 41, wherein said funds are
transmitted or transferred as an electronic funds transfer or via
the Automated Clearing House.
47. A method as claimed in claim 41, further comprising printing a
receipt evidencing said payment.
48. A method as claimed in claim 41, wherein said bar code
comprises a plurality of validation levels.
49. A method as claimed in claim 42, wherein said data comprises
the date and time said payor makes said payment.
50. A method as claimed in claim 41, wherein said apparatus is
integrated into a point-of-sale system.
51. A method as claimed in claim 41, wherein said apparatus is in a
location selected from the group consisting of: grocery store,
convenience store, supermarket, chain store, post office, drug
store, government office, location where goods are sold, location
where services are sold, bank, and retail store.
52. A method as claimed in claim 41, wherein said payor receives
said bar code by at least one method selected from the group
consisting of: via facsimile transmission to or from a computer,
via facsimile machine, via email, via file transfer protocol (FTP),
via hypertext markup language (HTML), via extended markup language
(XML), via hypertext transport protocol (HTTP), via modem, via the
Internet, via a wide-area network (WAN), via a local-area network
(LAN), via diskette, and via removable storage medium.
53. A method as claimed in claim 42, further comprising providing
an automatic caller response system and/or Internet access to said
data for use by said payee and/or said payor.
54. A method as claimed in claim 41, further comprising
transmitting or initiating transfer of notification to a payee of
said payment by said payor via facsimile, email, and/or custom
electronic procedure.
55. A method as claimed in claim 41, wherein said payment is made
by cash, check, debit card or credit card; and wherein said
predetermined amount of funds transmitted or transferred to the
account corresponding to said account number is not dependent on
whether payment is made by cash, check, debit card or credit
card.
56. A method as claimed in claim 42, further comprising
transmitting or initiating a transfer of said data to said payee
via accounting software.
57. A deposit slip comprising: a printed account number; and a
unique bar code comprising data identifying at least said account
number and a destination payment network corresponding to said
account number.
58. A deposit slip as claimed in claim 57, wherein said bar code
comprises a plurality of validation levels.
59. A printed bar code comprising: data identifying at least an
account number and a destination payment network corresponding to
said account number.
60. A printed bar code as claimed in claim 59, wherein said bar
code comprises a plurality of validation levels.
61. A method for performing an Internet financial transaction, said
method comprising: transmitting or transferring to a payor a unique
bar code comprising data identifying at least a payee and a
destination payment network corresponding to said payee.
62. A method as claimed in claim 61, wherein said bar code is
transmitted or transferred to said payor by at least one method
selected from the group consisting of: via facsimile transmission
to or from a computer, via facsimile machine, via email, via file
transfer protocol (FTP), via hypertext markup language (HTML), via
extended markup language (XML), via hypertext transport protocol
(HTTP), via modem, via the Internet, via a wide-area network (WAN),
via a local-area network (LAN), via diskette, and via removable
storage medium.
63. A method of providing for payment from a payor to a payee,
comprising: making available to one or more payees a standard
format for representing on a printed document data including at
least a payee and a destination payment network corresponding to
said payee; providing at one or more locations of one or more third
parties one or more scanning apparatus adapted to read data in said
standard format; receiving by electronic transmission data
comprising said destination payment network identification, payee
identification and payment amount; and providing information to
said destination payment network to effect transmission of funds to
an account of said payee in an amount identified by said payment
amount and concurrently effecting or initiating transmission of
payment information to said payee.
64. A method as claimed in claim 63, wherein said payment
information comprises the date and time said payment is made.
Description
[0001] This application is a continuation-in-part application under
37 C.F.R .sctn.1.53(b) of application Ser. No. 09/737,011, filed
Dec. 14, 2000.
BACKGROUND OF THE INVENTION
[0002] The present invention relates to a system and method for
performing financial transactions, and more particularly, to a
payment system and method using bar code identification.
Traditional Bill Payment Paradigm
[0003] The current paradigm of the bill payment cycle for goods and
services rendered has improved only in incremental steps since the
beginning of time. In ancient times, most goods and services were
exchanged between individuals, using the common currency of the
realm or by a mutually agreed upon barter arrangement. Extension of
credit for goods and services was generally limited to the affluent
and wealthy. When payment was due, handwritten invoices were hand
delivered. Sometime later, cash payment would be remitted in
person. Most trade occurred at the local level between individuals,
exchanging cash or barter goods.
[0004] In the late 1800's and early 1900's in the United States,
credit for goods and services rendered remained essentially
unchanged at the local level. Society became less stratified and
there became an affluent middle class populace between the highest
and lowest levels of society. Credit for goods and services became
extended to select groups and individuals within this populace as
well as the affluent and wealthy. However, invoices were still
handwritten tallies of goods and services rendered, which were paid
for in cash. The Industrial Revolution precipitated many technology
advances in transportation and communication, which affected many
facets of daily life. In commerce, the foundation cornerstones of
the financial services industry, as it exists today, were developed
and shaped. With an infrastructure of a national mail network and a
solid central banking system in place, the more affluent and
wealthy individuals began to have a larger and more convenient span
of financial control with extended remote banking credit services.
Merchants could then send their invoices to distant customers
through the national mail network and receive payments, some time
later, in the form of a bank draft honored by the local bank for
cash.
[0005] In the generations following World War II to the present
time, with general society becoming more and more homogenized and,
on the whole more affluent, banking services are available and
competitive at every level. Bank checking accounts (and therefore a
credit mechanism with which to pay remote billers) are available to
60 percent or more of the population. The national mail network is
a very cost-effective delivery system for local and remote
customers of automated or machine printed monthly invoice
statements, which average 15.9 billion annually. Customers write
checks, as payment for these invoices, and return them via the mail
network. When received at the merchant directed return location (a
bill payment-processing center), these mail payments are opened,
the checks deposited, and the customer accounts credited with the
face amount of these check payments.
[0006] If everyone were to pay their bills on or before the due
date with valid checks, this state of the bill payment industry
might be sufficient to satisfy most of today's societal needs.
However, this is not the case. Some people never pay their bills on
time, for a variety of reasons. Payments made with a check are not
always covered with sufficient funds at their bank. The end-result
consequence to the biller is a finite cost that is directly
attributable to the disruption of the flow of goods and services
through his business.
[0007] To cover the costs incurred by these late payments, billers
have only two options available to them. One option is to spread
this overhead cost over of all the goods and services that they
provide, with the possible consequence of pricing their products or
services out of the competitive price range for similar or
substitute set of products and services. The second option is to
impose payment penalties on those customers who pay late--for
whatever reason. This second option is generally more preferable
since it targets the problem population segment directly. However,
billers are often unable to recover the full cost of late payment
consequences from those customers and still stay within the public
legal and regulatory mandates.
[0008] Recently, there have been business attempts to further
automate the bill payment process by the electronic delivery of
biller invoices and the subsequent electronic remittance of
payments. While the electronic presentment of bill payments might
address the current 15% or so of the U.S. population with access to
the Internet, it does not address the 85% without Internet access.
Within the next decade, the Internet wired segment of the
population will not grow as fast as the current crop of "dot com"
entrepreneurs hope or project in their "new" economy business
plans. The latest statistics show that less than 3% of the American
public may use on-line remittance services.
[0009] Federal statistics indicate that fully 30-40% of the U.S.
population may be "unbanked". The "unbanked" population operates
solely within the cash economy without any formal banking level
traceability. There are many reasons that people prefer to operate
in this economy, some of which are culturally related. Others
prefer anonymity for quite specific reasons, such as illegal aliens
avoiding detection and deportation by the INS or others hiding
their sources of income from the IRS. Federal statistics also
indicate that 30-40% of the adult U.S. population may have a
working fourth grade education or less.
[0010] There may be a correlation between those people opting for
the cash economy and the fact that many may not be able to maintain
and balance a checkbook. Most people would rather admit to being
"unbanked" rather than to being illiterate. The "unbanked" segment
of the population has difficulty operating in a check-oriented
society and paying their monthly bills to remote billers. At the
local level, the proprietor-operated check cashing storefronts may
service some of the needs of these individuals. Weekly paychecks
are cashed for a transaction charge (mostly based on the face value
of the check), and money orders are then bought, to be enclosed
with mailed bill payments. When bill payments are long past their
due date, these individuals may have to resort to more expensive
electronic wire services to avoid service disconnects.
[0011] For the great majority of printed bill payment invoices that
are distributed every month, each biller automates and optimizes
its bill collection and remittance process to suit the requirements
of its installed paper handling equipment and flavor of customer
account numbering assignments and schemes. Bill remittance stub
sizes and formats vary from postcards printed with dot matrix
printers to full-page 81/2" by 11" sheets with laser printed
invoice information on pre-printed forms. Each has a tear-off bill
remittance stub portion that is then mailed back with a check
payment. Account numbers on these bill remittance stubs appear in
different (and sometime multiple) spatial positions, formats and
fonts. While still not universal, most billers have formatted their
account numbers (and other customer related information) on bill
remittance stubs in Optical Character Recognition (OCR) readable
scan lines. Some of this information is printed twice on the bill
remittance stub as a contingency that the paper bill remittance
stub is shredded or mangled by the automation equipment. Human data
entry of this customer account number information is the ultimate
fallback mode for processing this payment.
Traditional Bill Payment Examples
[0012] FIG. 1 shows an exemplary local gas company remittance stub
100 utilizing this manner of design. The biller in this example has
assigned a numeric account number to each of his customers. As
shown in FIG. 1, the customer account number is printed three
times, the human readable one 102 under the "Your Account Number"
heading, and the other two 103, 104 printed twice in
machine-readable form. Account number check digits 101 are used to
validate the account number. Each digit in the account number is
multiplied by a mathematical weight, and then all these products
are added together. Dividing the total sum by 10 and complementing
the remainder yields the check digit that is compared against the
indicated digit. If the digits match, then the account number has
been detected and read correctly. Check digits are employed to
eliminate two types of common errors, physical digit read errors
and transposition errors (when the customer account number is
processed manually).
[0013] FIG. 2 shows an exemplary remittance stub 200 from a local
power company that assigns a combination of letters and digits to
its customer base. There are two forms of the customer account
number 201 that appear on the bill remittance stub. The first 201
is designed to be human readable because it appears within a
printed text box labeled "Account Number". The last digit in the
Account Number box is the customer account number check digit. The
second form of the customer account number 202 appears in
machine-readable form and is embedded in the OCR scan line
(underlined for illustration). The leading "4" digit is the
customer account number check digit and the remainder of the
underlined portion of the OCR line are the digits that can be
mapped into the human readable "Account Number" form. The format of
this machine-readable OCR scan line 202 is probably a confluence of
many internal design decisions, based on several factors. From a
human ergonomics perspective, a customer service representative of
the power company, during a service call, would never ask a
customer to recite his account number from a sequence of digits
appearing within the machine-readable OCR line and expect a correct
answer. The human readable form 201 of the customer account number
is easier for a customer to recognize and to dictate over the
telephone when requesting service changes to his account.
[0014] These two examples illustrate the primary uses of duplicate
account information printed on a bill remittance stub--one for
simplicity when verbally referring to a specific customer account
and the second for the case that the automation process fails and
customer account number payment information has to be entered
manually.
[0015] FIG. 3 shows an exemplary remittance stub 300 from a gas
company, in which the biller automates part of the bill payment
remittance process by including, on the bill remittance stub,
company proprietary bar coded information 301 that does not appear
to be related in any way to the printed customer account number.
While the format of this bill remittance stub 300 may marginally
advance that biller's state-of-the-art bill collection and system
processing with the use of newer and improved automation equipment,
it does not significantly decrease, in favor of the customer, the
overall bill payment cycle. The great majority of the bill payment
cycle time consists of non-deterministic time delays in the
national mail network during the biller-to-customer and the
payment-to-biller delivery paths. These random time delays,
combined with very short biller dictated due dates and (possibly
intentional) delayed processing times, always work to the detriment
of the customer. As a result, some customers are assessed penalty
payments, which are sometimes more profitable than the basic goods
and services provided.
[0016] The system of bill payment invoicing, collection and
remittance processing remains a fragmented industry because there
are no common bill remittance stub format standards, no common
customer account number representation standards, no common,
expedient data and money delivery mechanisms to the biller, and no
large bill remittance stub processing networks, in addition to
payment cycle delays that always work to the detriment of the
customer to favor the biller (with a correspondingly greater profit
margin). By constructing a common set of standards from the current
set of available technology components, a universal national bill
payment network could be implemented that addresses the above list
of industry problems, resulting in a positive economic impact to
the business community at large. For such a set of standards to
work, the cooperation of several large organizations would be
required; however increases in raw profit and new business growth
opportunities should induce such cooperation.
[0017] As shown in FIG. 4, a system 400 consistent with the
existing bill payment paradigm uses the national mail network and
biller payment processing centers to convert physical paper into
electronic data and bank credits. The current bill payment network
is a paper based network that primarily relies on the central
banking system for processing customer remitted bank draft payments
and the national mail network for customer invoice delivery and the
return of mailed bill payments. In system 400, for all the goods
and services rendered to a customer over a given billing period,
the biller accounts receivable 401 accumulates a dollar total and
generates a detailed machine printed invoice (which may take 4-5
days after account cut-off time to process) that is sent to the
customer 403 via U.S. Mail 402. The customer (i.e. payee) 403
typically receives the invoice 2-3 days later (which time is
variable, without any direct traceability from the perspective of
either the biller or the customer).
[0018] Once the customer receives the invoice in the mail, the
customer makes out a check payment or procures a money order 404 to
remit with a mail payment, which occurs sometime later, depending
on the availability of cash resources and other circumstances. The
customer mails the payment via U.S. Mail 405 to the biller
collection and processing center 406, where processing time may be
2-3 business days or more (which time is variable, without any
direct traceability from the perspective of either the biller or
the customer). At the bill payment processing center 406, the
following operations are typically performed: opening all received
mail; microfilming and/or otherwise recording all received
payments; electronically reading and processing OCR bill remittance
stub information; preparing all received check or money order
payments for bank submission; and electronically remitting bill
payment data, based on check payment verification. Processing time
within the processing center 406 may be 2-3 days.
[0019] It should be noted that there may be sanctioned late payment
penalties imposed on credit card payments, wherein a biller might
gain an advantage by intentionally delaying an on-time payment by a
day or so, thereby causing an otherwise on-time payment to be
considered late. For example, for a $200 payment delayed by only
one day, a $25 late payment penalty might result in an equivalent
Annual Percentage Rate (APR) interest rate of 150%, for little or
no marginal cost to the biller. This overcharge, which may be
difficult for the customer to trace later, may be compounded by
another finance charge for the outstanding unpaid balance amount,
made late by that intentional delay.
[0020] Payment data is next remitted electronically from the
processing center 406 to the biller's bank 408, and processing and
distribution of electronic payment data is typically done using the
Federal Reserve Automated Clearing House (ACH) Network 407, which
typically takes 6-9 hours. At the biller's bank 408, the electronic
payment data is received from the ACH Network, stripped and
reformatted according to biller specified formats, which may take
4-6 hours. Finally, the biller's accounts receivable 401 and/or
customer service computer files are updated. Depending on the
"legacy factor" of the biller's computer processing systems, this
process can range anywhere from 2-3 hours to 4-5 days.
[0021] Assuming zero latency on the part of the customer paying his
bill, the cycle time between the customer account cut-off time and
the time that the customer payment is applied to his account, using
the above time estimates, may range from 13-18 days. Since there is
usually some customer delay, the observed bill payment cycle time
will be longer.
SUMMARY OF THE INVENTION
Biller-Payor Aspects of the Present Invention
[0022] The present invention involves the transmission of payment
information via one or more networks (e.g. the Internet and the
Federal Reserve ACH Network) to billers of consumer goods and
services. This payment information is captured using existing
scanners in cash register systems at supermarkets, chain stores, or
other retail outlets. Retailers gain access to a valuable affinity
draw because everyone has bills to pay regularly. Billers save
millions of dollars in collection and processing expenses.
Consumers are provided a convenient way to pay any bill quickly and
flawlessly for a nominal transaction fee (e.g. $1.00 per bill).
[0023] A bill payment system and method consistent with the present
invention relies on an additional ISO standard printed bar code on
the biller invoice, which is then delivered to the customer via the
national mail network. Thereafter, payment information and payment
credits are returned to the biller electronically. With the
proliferation of the Universal Product Codes (UPC) that are
imprinted on every retail product today, an infrastructure for
processing bar coded information is already in place. At
supermarkets, bar code scanners at all the checkout aisles are used
to register the sale of all items for inventory and pricing
purposes. Bar coded bill payments would be just another commodity
item to be paid for, accepted at retail. Upon receiving a bar coded
payment invoice, the customer could go to any supermarket, chain
store, post office, or other location which accepts this type of
payment, to pay his bill. In return for the nominal transaction fee
paid, a customer might receive a printed detailed proof of payment
receipt. Billers could be notified immediately and agree to suspend
all collection activities, and account posting could take place
within 36 hours, all funds remaining within the Federal Reserve
Banking system. No state banking licensing would be required, since
each biller's approval is secured by means of a biller registration
process, which introduces the technical specifications and
certification parameters necessary for billers to participate in a
system consistent with the present invention.
[0024] As a participating retail establishment provides bill
payment services to the public, it also forms a new portal. A
proprietary router/application interface may be non-invasively
attached, indirectly, to the retailer's checkout scanner. Through
this portal, other services can be offered to consumers. For
example, in addition to payments, money transfers (a financial
services which may be lucrative to provide) may be provided through
a system consistent with the invention. Bank account transactions
such as deposits may be made or Internet wallets replenished.
Though not required, the U.S. Postal Service (USPS) could be
offered a new income stream for simply authorizing this system. The
power of an "electronic" postmark may impact the way billers view
this system.
[0025] It is contemplated that the retail industry should provide
advertising as they promote the affinity pull they already wish to
impart upon the consumer marketspace. The community of consumer
billers should provide cooperation because of the potential of this
system to reduce what are now very expensive embedded collection
costs. Consumers need another way to pay their bills more
efficiently than the U.S. Post Office mail can do so today,
especially for those without bank accounts or those who desire to
use credit for bill payments, and clearly for those who are late. A
system consistent with the present invention therefore benefits
billers, consumers and retailers who participate, and may be
inexpensively and easily established and maintained.
Further Payment Aspects of the Present Invention
[0026] A system and method for payment is further provided, wherein
consumers pay their bills at supermarkets, large retail chain, or
other stores and receive immediate credit from billers for their
payments, which are made using a bar code transmitted
electronically to the consumer, e.g., by fax, email, or Internet.
The biller receives good payment funds, deposited directly into his
bank account, and error-free electronic payment data for consumer
bill payments by the very next business day. The biller backdates
the received bill payments to the time and date the consumer
actually paid, regardless of the time that the payment data takes
to post to the biller's accounts receivable system.
[0027] In another aspect, a method for person-to-person money
transfers is provided, wherein a bar coded deposit slip, card, or
other printout permits a sender to remit funds directly into a
receiver's bank account, and such funds are quickly accessible for
withdrawal at a nearby automated teller machine, or for a debit
card purchase.
[0028] In one aspect, a bill payment system consistent with the
invention comprises a payee and a scanning apparatus. The payee
transmits or transfers to at least one payor a unique bar code
comprising data identifying at least the payee and the payor. The
scanning apparatus is configured to scan a printed representation
of the bar code . The scanning apparatus is capable, based on
information stored in the bar code and a payment made by the payor,
of transmitting funds or initiating a funds transfer to the payee
in a predetermined amount and transmitting data or initiating a
data transfer to the payee regarding the payment.
[0029] In method form, a bill payment method consistent with the
invention comprises: transmitting or transferring to at least one
payor a unique bar code comprising data identifying at least the
payee and the payor; and permitting a third party to scan a printed
representation of the bar code and, based on the identifying
information of the bar code and a payment made by the payor, to
transmit funds or initiate a funds transfer to the payee in a
predetermined amount and transmit data or initiate a data transfer
to the payee regarding the payment.
[0030] In another aspect, a method of transferring money consistent
with the invention comprises: scanning a printed bar code
comprising data identifying at least an account number
corresponding to an account to which a deposit can be made and a
destination payment network corresponding to the account; and
transmitting funds or initiating a funds transfer, based on
information stored in the bar code and a payment made by a payor,
in a predetermined amount to the account.
[0031] In a further aspect, a deposit slip consistent with the
invention comprises a printed account number and a unique bar code
comprising data identifying at least the account number and a
destination payment network corresponding to the account
number.
[0032] In still another aspect, a printed bar code consistent with
the invention comprises data identifying at least an account number
and a destination payment network corresponding to the account
number.
[0033] In yet a further aspect, a method for performing an Internet
financial transaction consistent with the invention comprises
transmitting or transferring to a payor a unique bar code
comprising data identifying at least a payee and a destination
payment network corresponding to the payee.
[0034] In still a further aspect, a method of providing for payment
from a payor to a payee comprises: making available to one or more
payees a standard format for representing on a printed document
data including at least a payee and a destination payment network
corresponding to said payee; providing at one or more locations of
one or more third parties one or more scanning apparatus adapted to
read data in said standard format; receiving by electronic
transmission data comprising said destination payment network
identification, payee identification and payment amount; and
providing information to said destination payment network to effect
transmission of funds to an account of said payee in an amount
identified by said payment amount and concurrently effecting or
initiating transmission of payment information to said payee.
BRIEF DESCRIPTION OF THE DRAWINGS
[0035] FIG. 1 is an exemplary prior art remittance stub from a
utility company;
[0036] FIG. 2 is another exemplary prior art remittance stub from a
utility company;
[0037] FIG. 3 is another exemplary prior art remittance stub from a
utility company;
[0038] FIG. 4 is a process flow diagram of an exemplary prior art
bill payment system;
[0039] FIG. 5 is a process flow diagram of an exemplary bill
payment system consistent with the present invention;
[0040] FIG. 6 is an illustration of an exemplary data structure of
elements underlying the bar code "signature" in one embodiment of
the present invention;
[0041] FIG. 7 is an illustration of another exemplary data
structure of elements underlying the bar code "signature" in one
embodiment of the present invention;
[0042] FIG. 8 is an illustration of an exemplary bar code bill
payment "signature" in one embodiment of the present invention;
[0043] FIG. 9 is a table illustrating the results of an exemplary
split modulus matching calculation in one embodiment of the present
invention;
[0044] FIGS. 10 and 11 are illustrations of an exemplary Level 3
envelope in one embodiment of the present invention;
[0045] FIGS. 12 and 13 are process flow interaction diagrams of the
mainline transaction information interchange between the checkout
scanner, retailer host processor, and data collection network
interface (DCNI) unit in processing a bar coded customer bill
remittance stub, in one embodiment of the invention;
[0046] FIG. 14 is a system view diagram of a transaction collection
system in one embodiment of the present invention;
[0047] FIG. 15 is an exemplary transaction processor executive
controller (TPEC) display screen, in one embodiment of the
invention;
[0048] FIG. 16 is an exemplary system monitor station (SMS) display
screen, in one embodiment of the invention;
[0049] FIG. 17 is an exemplary end of batch monitor (EBM) display
screen, in one embodiment of the invention;
[0050] FIG. 18 is an exemplary electronic transmission interface
(ETI) display screen, in one embodiment of the invention;
[0051] FIG. 19 is an exemplary ETI transaction detail display
screen, in one embodiment of the invention;
[0052] FIG. 20 is an exemplary ETI map biller-to-partner display
screen, in one embodiment of the invention;
[0053] FIG. 21 is an exemplary transaction browser display, in one
embodiment of the invention;
[0054] FIG. 22 is a process flow diagram of another exemplary bill
payment system consistent with the present invention;
[0055] FIG. 23 is an illustration of an exemplary Level 3 envelope
in one embodiment of the present invention;
[0056] FIG. 24 is an exemplary bar coded deposit slip in one
embodiment of the present invention;
[0057] FIG. 25 is an illustration of an exemplary gas
station/convenience store debit card known in the art; and
[0058] FIG. 26 is an illustration of an exemplary gas
station/convenience store debit card in one embodiment of the
present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Biller-payor Embodiments
[0059] Turning now to FIG. 5, a bar coded bill payment based system
500 consistent with the present invention utilizes a bar code on
the biller invoice, which is then delivered to the customer via
mail, and payment information and payment credits are returned to
the biller electronically. Advantageously, nationally recognized
and federally sanctioned payment electronic networks may be
utilized for remitting customer payment data and funds. For all the
goods and services rendered to a customer over a given billing
period, the biller's accounts receivable 501 accumulates a dollar
total and generates a detailed machine printed invoice including a
special bar code, which is mailed to the customer 503 via U.S. Mail
502. Time for processing and mailing may be 4-5 days after account
cut-off time, and the mail transit time to the customer may add an
additional 2-3 business days or more before the customer receives
the invoice (which time is variable, without any direct
traceability from the perspective of either the biller or the
customer). The customer 503 then receives the invoice in the mail.
Sometime later when cash resources are available, or depending on
other factors, the customer 503 decides to pay bill. The time for
this to occur is variable, depending upon the customer's
circumstances.
[0060] To pay the bill, the customer 503 takes the bar-coded
invoice to a participating store (e.g. a supermarket) that
processes bill payments. The customer presents his bar-coded bill
remittance stub to the checkout cashier for scanning at the
checkout scanner 504, which may be done while paying for other
UPC-coded items. Instead of looking up an in-house UPC code for
pricing, the scanner 504 picks up the bill payment bar code that
identifies the biller to be paid and the account number to be
credited. The customer informs the checkout cashier the amount to
be paid on that account, payment is tendered to the cashier, and
the cashier inputs the amount to be paid into a terminal which is
in communication with a backend host processing system 505. Upon
receiving payment from the customer, that bill payment is then
complete. The check out of any remaining products and items (or
bills) continues until the complete total for all goods and
services is calculated. The customer may receive a printed receipt
of the payment tendered with date and time that the payment was
made. The backend host processing system 505 forwards all the
payment data to the data collection network interface 506 ("DCNI").
The processing time for all of the payment steps may be as little
as a few seconds. Moreover, payments made in this manner are
time-stamped, so that once payment is made, the customer may rest
assured that payment has been timely acknowledged.
[0061] The data collection network interface 506 collects and
stores all the customer payment data in non-volatile memory.
Periodically throughout the day (based on time and transaction
volume thresholds), or at other predetermined intervals, the
interface 506 transmits the payment data to the central site
transaction collection system 507. Additional transmissions may be
scheduled before the daily transaction collection system 507
aggregation times. The time for the back-end and collection system
processing has no impact on customer payment time, since all
payments may be time-stamped. Separately calculated calendar day
payment counts and totals may also be sent to the transaction
collection system 507 as an independent transaction audit balancing
mechanism. The transaction collection system 507 may continuously
receive payment data information from a distributed network
comprising a plurality of data collection network interface units
506 deployed at field retail establishments. Before the last
processing window closes at the Federal Reserve Automated Clearing
House (ACH) Network 508, all customer payments are sorted and
aggregated for direct remission to their respective billers, which
may take approximately an hour. Processing and distribution of
electronic payment data is done using the Federal Reserve Automated
Clearing House (ACH) Network 508, which may take 6-9 hours. At the
biller's bank 509, the electronic payment data is received from the
ACH Network, stripped and reformatted according to biller specified
formats, which may take 4-6 hours. Finally, the biller's accounts
receivable 501 and/or customer service computer files are updated.
Depending on the "legacy factor" of the biller's computer
processing systems, this process can range anywhere from 2-3 hours
to 4-5 days.
[0062] Assuming zero latency on the part of the customer paying his
bill, the cycle time between the customer account cut-off time and
the time that the customer payment is applied to his account, using
the above time estimates, may range from 9-12 days (in contrast to
the 13-18 days of the prior art system). Since there is usually
some customer delay, the observed bill payment cycle time will be
longer.
[0063] Moreover, if the biller recognized the customer payment date
and time as the creditor date of receipt as specified in the
Federal Reserve Regulation Z, Section 226.10, then the total bill
payment cycle time would be reduced to 6-8 days. Explicit agreement
from the biller would be secured through the biller registration
process. The biller may validate the customer payment date with the
transaction embedded "electronic postmark", which can not be
performed within the current frameworks of either the paper based
bill payment or the electronic payment paradigms, today.
[0064] In addition to the more than 55% time reduction in the bill
payment cycle, other advantages of the present invention include:
customer choice of local bill payment locations, electronic
application of bill payments to account within 24-36 hours, a
reduction in bill payment errors with machine-readable bar coded
account numbers, and time stamping of bill payments at the time
payment is tendered. Electronically delivered bill payments, under
the present invention, are much cheaper for the customer to pay for
and less expensive for the biller to process through its remittance
processing center and accounts receivable systems than under a
prior art system. Additionally, banks that process data from the
ACH system will have more chargeable services to offer their biller
customers. Furthermore, billers can incorporate this bar coding
standard into their bill remittance processing centers, as older
OCR recognition equipment is replaced with simpler and more
reliable laser bar code scanning equipment. With sufficient
planning, a biller, contemplating a conversion of one or more
legacy customer account numbering systems to a simpler, newer
scheme, can use this system of bar coding in its conversion
process. In an alternative embodiment, electronic invoice delivery,
whereby the customer receives and prints the bar-coded invoice at
his own computer system, may be used to reduce the time and labor
required for the biller to prepare and mail invoices to the
customer.
[0065] It is further contemplated that billers would register with
a centralized organization in order to receive an assigned biller
bar code, just as all companies must register with the Uniform Code
Council (UCC) to get their Universal Product Code (UPC) assignment
for their products.
[0066] It should be understood that the foregoing described
embodiment which uses the in-store scanner and retail host back-end
machine as a means of detecting, reading and processing the bill
payment bar codes is but one embodiment, and these components are
not described herein as limitations. For example, another method
might utilize a personal computer, terminal, or other equipment
having a bar code capable scanner, receipt printer and an interface
to the data collection network interface in place of the in-store
system. Ideally, such a computer would have the same functionally
equivalent interface as the in-store system. In fact, it is
contemplated that, as a transitional measure, until the retail
stores modify or update their in-house check-out software systems
to accommodate the data collection network interface, a simple PC
might operate in its place and serve as a model prototype to
demonstrate the operational aspects of this system.
Bar Coding Validation
[0067] Prior art systems have concentrated on the visual aspects of
bill remittance stub recognition, detection and validation against
potential fraud, typically using optical character recognition
(OCR). The present invention applies a bar code solution to the
general bill payments problem, rather than a new variant or
improved OCR technique. Bar code is more efficient than OCR by
several magnitudes because bar codes can be detected reliably and
processed by relatively simple hardware and firmware, whereas OCR
requires long physical scan times and significant host CPU
processing requirements for character recognition (and then only
for a selected set of fonts). Bar code consists of binary elements
that are parity checked for every bar code symbol and globally
checked digited at the message level. OCR consists of many analog
segments that have to be neurally correlated and matched to the
human readable character set with no internal self-checking
controls. In short, bar code is the future digital solution whereas
OCR is a dated analog solution that still plagues most bill payment
processes today.
[0068] The Universal Product Code (UPC), printed on most retail
products today, is a 12digit number that is a concatenation of four
numeric fields--a classification number (1), a producer
identification number (5), a product identification number (5), and
a check digit (1). The need for a standards authority first arose
in 1972 when the supermarket industry decided to mark each of the
grocery point-of-sale packages with a unique identifier to speed
checkout transactions, therein creating an organization that today
is called the Uniform Code Council (UCC). The underlying bar code
symbology is merely a convenient representation of this UPC code
format that can be reliably detected by simple point-of-sale
scanning equipment (thus, it does not matter which particular bar
code is used).
[0069] There is no standard way of representing multiple data
fields in a single scan line, given the designs and formats of
various bar code standards and conventions commonly in use today.
For a typical bill payment application, two fields are minimally
required--a 6-7 digit biller identification and a variable length
(up to 22 characters or more) alphanumeric customer account number.
If these fields were concatenated in a fixed format in a single bar
code scan line on a bill head, it is very doubtful that low skilled
retail help would reliably scan the correct bar code where multiple
bar codes might appear on a given bill head. To perform error-free
data validation on this scan line, more information must be
embedded within the data itself.
[0070] In the retail environment where bar coded products abound,
there is a distinct need to determine that a bar code, submitted
for processing, is correct and valid for the target bill payment
processing application. One cannot assume that the retailer will
always submit a valid bar code from a bill remittance stub that may
contain more than one printed bar code sequence. If, for example, a
utility company prints the new bill payment bar code, in addition
to an already existing internal routing bar code, the two bar codes
must be disambiguated. While the utility company can easily
distinguish its own internal routing code by its printed position
on the bill remittance stub, a retail cashier might not know which
to present. The solution is for the cashier to use trial and error.
If the first bar code attempted does not validate, the second (or
third, etc.) should be scanned. Validating a bar code bill payment
"signature" in the course of the bill payment process is a
component of an embodiment of the present invention.
[0071] By using a unique bar code "signature" having multiple
levels of data validation implemented by check digit algorithms, a
bar code scanning system may reliably recognize and validate a
valid bill payment bar code. The concept of paper envelopes may be
used as an analogy for relating the validation method of the
invention. In the embodiment described herein, three "envelopes"
are used (although those skilled in the art will recognize that any
number of "envelopes" or levels of validation may be used), the
first being inside the second, and the second inside the third. At
the outermost layer, the third "envelope" has printed, on the
outside, the bill payment bar code "signature". If the bar code is
detected and read correctly by the hardware scanner, the resulting
alphanumeric information is valid in that it compared correctly
with the embedded encoded bar code check symbol. If this first
operation is successful, the "envelope" is opened. The directions
printed on the inner "envelope" specify to calculate a check digit
on the resulting alphanumeric information derived from the bar
code, comparing the calculated result against the last digit in the
string. If this second operation is successful, the next "envelope"
is opened. The printed directions on the innermost "envelope"
specify to use the format designator digit(s) to decode and to
verify the data integrity of the embedded component data elements.
Each of these data elements should be verified by calculating their
check digits and by utilizing other independently available data
validation checks.
[0072] If all three levels of validation successfully pass muster,
then a valid bill payment "signature" has been detected and the
resulting data should then be passed to the target bill payment
application for subsequent processing. Failure at any intermediate
validation level results in a negative acknowledgement. The prime
purpose of this bar code "signature" design is to unconditionally
identify the detected scanned bar code as being proprietary to the
present invention, in the absence of any other external
information, through multiple layers of check digit information,
format designator indicators and local data validation schemes.
[0073] A number of different application "signature" formats may be
implemented within a bar code scan line as a series of successive
embedded "signature" data fields. In one embodiment, each signature
data field consists of three elements: a format designator ("fd")
consisting of one or more digits, a data field ("data") consisting
of one or more fixed or variable length sub-data fields, and a
check digit ("cd") algorithm associated with the format designator
and the level at which it appears.
[0074] FIG. 6 illustrates a bar code "signature" 600 in one
embodiment of the invention, utilizing four levels of successive
embedded "signature" data fields. The Level 1 data validation 601
is simply the hardware decode of the bar code symbology, using the
embedded check symbol character as data validation--i.e., all the
bar code symbols were detected and processed correctly.
Applicability of the data to the intended target application is
demonstrated when all the remaining levels of validation are
successful. As shown in FIG. 6, Level 2 data validation 602
consists of one signature data field (although it could have had
more). The data validation of the Level 2 signature data field
consists of two checks--that the format designator value (for that
level) is correct and that the check digit calculation for the data
string consisting of the format designator digit(s) and the data
field digits matches the check digit character. The Level format
designator defines at least three characteristics: the check digit
algorithm implementations (in this example, 1), the number of data
elements (in this example, 1), and the number of trailing discard
characters for bar code odd/even count padding (in this example,
2). The number of unique combinations of the above three
characteristics will determine the number of format designator
values required at this level. For this example, there is only one
check digit algorithm to disambiguate target applications, there is
only one data field element, and there are two padding character
combinations for the Code 128 bar code. Thus, the total number of
format designator values required at this level is two.
[0075] The Level 3 signature data field 603 checks operate on the
residual Level 2 data. The Level 3 data validation checks are
similar to the Level 2 checks and the format designator defines at
least these three characteristics: the check digit algorithm
implementations (in this example, 1), the number of data elements
(in this example, one fixed, one variable or fixed), and the field
lengths for one or more data elements. As shown in FIG. 6, there
are two data element fields. The number of data splits defined for
this data field would determine the number of format designator
values that are required for this level.
[0076] The fourth 604 to nth 605 levels comprise a continuing
iterative process of Level 3. Depending on the attributes or
properties that one arbitrarily assigns to the data (and
hierarchical functions) at each level determines the number of
format designator values required at that level. The target
application receives all the data fields from the final level of
data validation.
[0077] A carefully chosen set of conventions for the format
designators at each level will facilitate correct data field
parsing with the additional security that multiple levels of check
digit validation will ensure data integrity and "positive
ownership" to the target application. The format designator
digit(s) do not necessarily have to be leading as illustrated
above. An alternative format for the leading format designators
could be as is illustrated in the bar code signature 700 of FIG. 7,
in which the data strings precede the format designator digits.
[0078] With reference to the exemplary embodiment shown in FIG. 6,
a sample format of the unique bar code bill payment "signature" 800
is shown in FIG. 8, as a multiple layered data validation scheme. A
bar code typically consists of 6 sections: (1) a quiet zone
(.about.0.25" of white space) before the bar code; (2) a unique bar
code symbol that represents the "START" character; (3) bar code
symbols representing data characters (1300017350764058410363); (4)
bar code check symbol that represents a calculated check digit of
the preceding data character block; (5) a unique bar code symbol
the represents the "STOP" character; and (6) a quiet zone
(.about.0.25" of white space) after the bar code. If the hardware
decode of this Level 1 envelope data string is not successful, the
retail cashier should not get a good bar code scan confirmation. If
the hardware decode is successful, the retailer cashier should get
a good bar code confirmation (but not necessarily of a valid
product code). A good hardware decode of a bar coded scan line is
defined as the detection of valid bar code symbols within the
string that, when processed through the defined check digit
algorithm, matches the embedded string check symbol character. This
is the first level of data validation check that must pass.
[0079] When the bar coded data characters are decoded from this
scheme of variable width white and dark bar patterns, the result is
the following string of (alpha)numeric characters:
130001735076405841036 3. Calculating a split modulus 10 check digit
for the string to match against the last character, using a 1313 .
. . mathematical weighting scheme, results in the table of
calculations illustrated in FIG. 9. The Level 2 format designator
value (1) is chosen to indicate the check digit algorithm (Split
Modulus 10 with mathematical weights of 1313 . . . ), the number of
data field elements (1), and number of trailing padding characters
(0) to utilize the high density Code 128 Type C symbol set. The
Level 2 format designator value (2) is chosen to indicate the check
digit algorithm (Split Modulus 10 with mathematical weights of 1313
. . . ), the number of data field elements (1), and number of
trailing padding characters (1) to utilize the high density Code 28
Type C symbol set. The modulus (or the remainder) of the resulting
sum of the digits (87 divided by 10) yields 7. The complement of
the remainder 7 yields 3 (10-7=3). This calculated result is the
check digit of the above digit string, and successfully matches the
last digit in this illustrative example. This is the second level
of data validation check that must pass. If this validation is
successful, the operation proceeds to the Level 3 envelope data
decode and validation algorithms.
[0080] In this particular example, there are only three levels of
validation defined. The Level 1 check is a hardware validation data
check. The Level 2 check is a pre-qualifying software validation
data check. The Level 3 check is an "ownership" data check (i.e.
whether this is the "signature" for bill payment data under the
present invention). Different "signatures" can be constructed for
any number of application program uses through a judicious design
scheme and the selection of format designators. Format designators
are arbitrary indicators with which to properly decode the format
of and to validate the ensuing data string--in this case, the
format designator is placed as the first (one or more) leading
digit(s). At different levels, the same format designator values
can have different meanings.
[0081] Turning now to FIGS. 10 and 11, two format designator values
have been chosen in this example (at Level 3) to encapsulate six
format and validation data characteristics--all of which must be
correct for the third and final data validation check to pass. The
Biller ID in each of these examples is "173" in a 6-digit numbering
system. The embedded spaces in the encoded data examples 1000 and
1100 of FIGS. 10 and 11 are not significant and are inserted to
show more clearly the various fields within the example digit
strings. The six format designator characteristics shown in FIGS.
10 and 11 define either format (1,2,4,5) or data validation
(1,2,3,6) checks. A format characteristic defines the layout of the
data whereas a validation characteristic facilitates data checking.
To validate a unique bar code application program "signature", the
more dependencies that exist within the data at each level for
subsequent cross checking and validation, the better. In the
illustrations of FIGS. 10 and 11, there are two format designator
examples with all possible variants within several constraints that
are checked and validated. Where there might be several different
Level 2 check digit algorithms employed, a Level 3 dependency is
checked. Condition #1 is checked against valid range of format
designator values for the current Level (in this case 3, 4). Biller
Identification Number (in this example, 173) is determined if
Condition #3 is TRUE and if it exists within the list of current
and valid billers (an independent table acquired by another means).
Where the biller account number check digit algorithms are not
known, a check digit is calculated and added to the account
number--to be checked then stripped when presented to the biller
(Format Designator Value =4). Where the biller account number check
digit algorithm is known, it is checked against biller defined
specifications (Format Designator Value=3): Conditions #1, #6.
Within the Level 3 envelope for each of the above examples, the
decoded and check digited values of the Biller Identification
Number and the presented Biller Customer Account Number results are
as follows: For Format Designator Value=3, Biller ID=173, Customer
Account=07640584103; and for Format Designator Value=4, Biller
ID=173, Customer Account=0764058410. This is the third level of
data validation check that must pass. If all the components in the
Level 3 envelope test and compare successfully, then the unique bar
code bill payment "signature" has been correctly validated for
further processing, and an indication is given to the retailer or
cashier that a dollar amount payment should be entered for this
item.
[0082] The primary purpose of this bar code "signature" design is
to unconditionally identify the detected scanned bar code as being
proprietary to a system or method according to the present
invention, in the absence of any other external information, and to
validate (using mathematical formulae and/or independent table
look-up methods, if possible) all the data element components
therein.
[0083] The methods and procedures by which the format designator
concept could be extended are strictly an implementation issue of
design schemes and an adopted set of orthogonal convention(s).
While the foregoing illustrative working example uses only three
levels of "envelopes" to validate the unique bar code bill payment
"signature", more levels could have been used, as required. The
format designators in the foregoing example utilized a fixed data
format with a set of predefined check digit algorithms for each
level. Possible design extensions in further embodiments might
include: (1) a format designator design scheme that defines a
dynamic variable number of sub-field elements and/or a set of
dynamic component string lengths for each of the defined set of the
sub-field elements (in contrast to the foregoing illustrated
predefined fixed schemes); (2) a format designator design scheme
having more than one digit in length, wherein each digit specifies
an independent set of predefined orthogonal attributes that can be
combined in a mix-and-match fashion (e.g. a two digit format
designator would specify a primary set of attributes in the tens
digit that is qualified by a secondary set of attributes in the
units digit); and (3) format designator design schemes wherein
subsequent trees of sub-field elements are controlled by one or
more preceding levels of format designators.
Bar Coding Specifications
[0084] The bill payment application bar code printed on each bill
remittance stub might minimally consist of four basic fields,
printed as a single string of digits: a format designator (1
digit); a biller identification number with optional embedded check
digit (7 digits); a customer account number with optional embedded
check digit (22 digits); and a check digit of the previous three
fields (1 digit). Of course, those skilled in the art will
recognize that the number of fields and/or digits per field as
described herein is specified by way of example, and not
limitation, and that the number and length of fields may vary
according to each embodiment of the invention. In this example, the
outermost bar code envelope for this information conforms to
documented ISO bar coding convention standards, utilizing an
embedded check digit algorithm to verify the integrity of the
entire bar code scan line data. It is strongly recommended that the
biller defined customer account number also contain an embedded
check digit, as a prudent secondary validation measure. If an
embedded check digit does not already exist within the biller
customer account numbering scheme (or the biller does not wish to
disclose that information as being company proprietary), an
alternate account number format provides a temporary check digit
that is checked then discarded before presentment to the biller. If
the detected bar code scan line data correctly passes the triple
tiered and multiple embedded check digit calculations, this
mechanism will virtually guarantee "defect free" biller and
customer account data. Otherwise, a bill payment stub whose bar
code has been mutilated or defaced by the customer is immediately
rejected at the point-of-sale entry.
[0085] To accommodate future requirements, an expanded set of
format designators could define new data format structures or
redefine the characteristics of current data fields. The following
is a possible list of characteristics that a format designator
element might define within a digit string: number of sub-field
elements; component string lengths of one or more of these
sub-field elements; check digit algorithms to be applied to each of
the sub-field elements; odd/even string packing factors when a
single bar code character represents one or more digits (Code 128
is a good example of this compression feature); or subsequent trees
of dependent sub-field elements. These format changes would be
transparent to the end user. The bar code data, detected by the
retail checkout scanner, is passed directly to the data collection
network interface unit for secondary validation and translation.
The parsed "translated" form of this data is then passed back to
the back-end host processor system for completing the bill payment
transaction at the checkout counter.
[0086] The bar code might either be printed vertically on the left
(bottom to top) or right (top to bottom) hand side of the bill
remittance stub with sufficient surrounding white space to satisfy
the criteria of the ISO bar code format. If there are other
proprietary bar codes present on the bill remittance stub, the
checkout counter cashier could have the option of folding or
bending the bill remittance stub such that only the required bar
code is visible for a successful bar code scan of the bill payment
information. Vertically printed bar codes of the format designator,
biller identification number and the customer account number on
most bill remittance stubs is good for a combined number sequence
of 14-25 digits at the lowest common denominator bar code print
resolution (nominal bar code "X" dimension .gtoreq.0.010 inches and
total bar code string length .ltoreq.3.0 inches). For sequences
longer than that, it is recommended that the bar code sequence be
printed in a manner parallel to the horizontal OCR line such that
extraneous proprietary bar code information can be folded out of
the way for a successful scan.
[0087] The assigned biller identification number is acquired or
distributed from a central registry authority, akin to the manner
in which the Uniform Code Council assigns new producer
identification numbers. As far as the customer account number is
concerned, it is recommended that the biller include a check digit
within the account numbering scheme. While it is unlikely that a
customer account number would be read in error if the hardware bar
code check symbol scan validates, this additional check digit
provides double assurance to the biller that the customer account
number is correct. This is especially important from the biller's
point of view when accepting bill payments from many sources of ACH
submitted data, many of which may be human entered from the myriad
of home banking software packages available--known empirically to
have very high human input error rates.
[0088] To this point, it has been tacitly assumed that the biller
will want to print this new bar code on the face of his bill
remittance stub. However, technical, as well as political, reasons
could preclude the printing of a new bar code standard on the face
of the current bill remittance stub. An alternative option might be
for the new bar code format to be printed on the back of the
current bill remittance stub (so as not to disturb the current mode
of visual remittance processing) or printed on a second or
subsequent tear-off bill page, formatted for that specific purpose.
A further alternative would be to utilize a specially printed bar
code format enclosure page (printed on better and sturdier paper
stock) that would permit multiple reuse by the customer. Spare
space on that enclosure could even be sold for advertising to
defray the printing costs by the biller.
[0089] The most common point-of-sale bar code used throughout the
retail industry is the UPC-A variant. However, most scanners employ
an internal firmware auto-recognition mechanism that permits them
to detect and to read several bar code symbologies. The bar code
symbology, under current consideration for the most general
specification of an alphanumeric customer account number, is the
Code 128 family. Where there are only numerics, the Code 128 Type C
variant features a high-density bar code--one printed symbol per
two digits of information. During the checkout aisle scanner
process, the back-end host processor recognizes a bar code data
scan line as a valid bill payment transaction and requires the
cashier to enter an amount to be paid. When this amount is entered,
a fixed transaction fee is added to the bill payment amount. On the
printed customer receipt, the bill payment is recorded in a form
similar to the following, including biller name and account number,
amount paid, transaction ID, date and time, and transaction fee
charged:
1 PMNT: Biller Name ACCT: Customer Account Number AMNT: $ ddd.cc
TRID: rrrrrrr yjjj ssss DATE: mm/dd/yy hh:mm FEE: $ dd.cc
[0090] This time-stamped transaction data is then stored in the
data communication network interface unit for later transmission to
the transaction collection system.
[0091] Where the checkout scanner detects multiple bar codes, the
retailer cashier can be trained to recognize the placement of a
valid bill payment "signature" bar code to be scanned for the
proper processing of a customer payment. Scanning any other bar
code, present on the bill remittance stub, that does not pass all
of the bill payment "signature" tests results in an immediate
validation reject by the data communication network interface
unit.
Back-end Host Processor
[0092] The retailer back room host processor may be required to
support two well-defined interfaces, the front-end checkout counter
scanner system and the back-end data collection network interface.
When the Code 128 bar code format is encountered from bill
remittance stubs, it should be recognized as a customer bill
payment, rather than the UPC code for a customer selected product.
This decision can be performed in a number of ways by the back-end
host processor. The easiest logic path to implement within the
back-end host processor is as follows: if this bar code scan is not
recognized as one of several defined pre-programmed sequences, pass
it to the data collection network interface before rejecting the
scanned data completely. The back-end host processor passes the
complete scan line data to the data collection network interface
unit for secondary level validation and data translation. If
secondary level validation is successful, the parsed translated
data is passed back to the back-end host processor to complete the
processing for this bill payment transaction. In this case, the
returned translated data consists of the Biller Name, the Customer
Account Number, and Transaction ID that is printed on the customer
printed receipt.
[0093] As bill payment data is processed by the front-end checkout
scanner system and completed, it may be relayed by the back-end
host processor to the data collection network interface unit to be
stored in non-volatile memory for later transmission to the central
transaction collection system. There are a number of standard data
collection network interface functions that may be accessed by the
back-end host processor system, e.g. validating the biller name,
adding a transaction, voiding a transaction, printing daily or
weekly processed totals and reports, and setting or reading
operational configuration parameters.
Data Collection Network Interface (DCNI) Unit
[0094] The retailer on-site data collection network interface unit
should provide a well documented, protocol neutral features and
functions front-end interface to the retailer back-end host
processor. The DCNI should also provide a non-volatile memory
storage capability of accumulated customer bill payment data. This
may be accomplished with a solid state hardware design that is
electrically isolated at all the critical interfaces and has no
moving elements that mechanically wear and eventually cause the
unit to fail. The back-end of the data collection network interface
should provide a transparent interface to the central site
transaction collection system and include functionality such as:
(1) performing secure validation procedures with the transaction
collection system; (2) downloading DCNI unit operating system and
program application code firmware; (3) downloading DCNI unit
operational configuration parameters; (4) uploading DCNI unit
memory image (emergency and debug use); (5) downloading
Verification Biller ID and Name data; (6) uploading transaction
data (compressed & encrypted); and (7) setting DCNI unit system
date or time. The primary function of the data collection network
interface unit is to provide a set of support functions to the
retailer host processor to aid in the collection, validation and
storage of transaction data from customer bill remittance stubs
scanned at the checkout counter.
[0095] FIGS. 12 and 13 illustrate the mainline transaction
information interchange between the checkout scanner, retailer host
processor, and DCNI unit in processing a bar coded customer bill
remittance stub, in one embodiment of the invention. As shown in
FIG. 12, the interaction occurring in the case of a valid account
number begins with the bar code being read 1201 by the checkout
scanner and passed to the retailer host processor. The host
processor next validates the bar code 1202 and passes the resulting
data to the DCNI. Since the account number is valid, an
acknowledgment of validity (ACK) is returned 1203 via the host
processor to the checkout scanner, along with the biller name and
account number. The amount to be paid is queried 1204 at the
checkout scanner, and the amount entered is passed 1205 to the
retailer host processor, which passes 1206 the bar code data and
the amount entered to the DCNI, where this transaction data is
stored 1207. If the data store is successful, an acknowledgment is
sent 1208 via the host processor to the checkout scanner, along
with a transaction ID number. The checkout scanner may then print
1209 the biller name, account number, and transaction ID as a
transaction receipt. As shown in FIG. 13, in the case of an invalid
account number, the checkout scanner first reads the bar code 1301
and passes it to the retailer host processor. The host processor
next validates the bar code 1302 and passes the resulting data to
the DCNI. Since some aspect of the data passed to the DCNI is
invalid, an acknowledgment of invalidity (NAK) is returned 1303 to
the host processor with a reason code. The Reject Payment status,
passed to the checkout scanner 1304 from the host processor, may or
may not contain the DCNI reject reason code for human feedback.
Reason codes might include, e.g., invalid scan line (not a valid
bill payment "signature" scan line), Biller ID check digit error,
invalid Biller ID (old biller that is not serviced anymore), or
Biller Customer Account Number check digit error. Payment is
consequently rejected at the checkout scanner 1304.
[0096] In one embodiment, the Transaction ID that is returned to
the retailer back-end host processor, as a positive confirmation
that the transaction data has been accepted and successfully
stored, is a 15 digit number consisting of: DCNI unit
identification (7 digits), last digit of year (1 digit), Julian
date (3 digits), and transaction sequence number (4 digits). This
information may be printed on the customer receipt as three groups
of digits (7,4,4) as an ease-of-use issue, should it be necessary
for the consumer to dictate his Transaction ID to a customer
service representative over the telephone.
[0097] Periodically throughout the day (primarily based on time and
transaction volume thresholds), the DCNI unit should transmit its
stored data to the transaction collection system after it has aged
past the "transaction void" window. The "transaction void" window
is defined as the time past which the transaction cannot be
canceled after it is taken (e.g. 15 minutes to eliminate the
possibility of fraud). In one embodiment, the data elements of each
transaction transmitted to the host consist of the following:
Retailer ID, Biller ID, Biller Account Number, Amount Paid,
Sequence Number, Transaction Date/Time Stamp, Status as Active or
Void, and Operator ID. When these transactions are transmitted to
the transaction collection system, they may be sent in batches
whose batch name conforms to the following naming convention: DCNI
unit identification (7 digits), last digit of year (1 digit),
Julian date (3 digits), and last transaction sequence number in
batch (4 digits). Such a numbering convention makes it easier for
customer service operations personnel to trace a given Transaction
ID.
[0098] The design and implementation of the data communication
network interface functions could optionally be performed as a real
time on-line system or as a batch oriented system to the
transaction collection system. If implemented as a real-time
system, communication costs to the central site and a redundant
"hot cutover" central site hardware configuration is very
expensive, by comparison, to eliminate all single point equipment
failures in an overall system operation. A central site batch
oriented "hot backup" system eliminates the real-time aspect of
transaction processing that exponentially escalates costs. Central
site redundant hardware still has to be available, but much less of
it is required to achieve the same level of system operation
reliability.
[0099] In systems that are explicitly designed for real-time
operation (e.g. credit card verification), "hot cutover" systems
contain elements that have to be designed, a priori, into the
combination of system and application software to anticipate and to
detect the many types of potential system, application or equipment
failures. When detected, transaction processing is immediately and
automatically transferred to an operational system "in waiting". In
the ensuing recovery mode precipitated by this equipment switch
over, transactions, in transit at the time of the first system
failure, are either pushed through to completion (if past a defined
system bottleneck check point) or are pulled back. If a transaction
is pulled back, all database record modifications are restored and
then the transaction is reprocessed from ground zero.
[0100] "Hot backup" designed systems have fewer constraints. Spare
equipment is powered up and ready to be switched into operational
mode. While time is important, it is not as critical in this
situation. In one embodiment, the DCNI unit resubmits transaction
batches, not explicitly acknowledged as processed, at a later time
(ranging from minutes to hours). Subsequently, if duplicate
transactions are encountered on resubmission, they are not
processed but are acknowledged as such to the DCNI unit. Much less
premeditated contingency system software is required in this
environment for robust system operation.
Transaction Collection System
[0101] While the data collection network interface may be a single
unit, the central site transaction collection system may consist of
multiple central processor server units acting in concert to
perform a collective set of functions and processes. This design
approach permits scaleable processing and avoids the possibility of
single point failures that might curtail or impact the production
processing of incoming transaction batches.
[0102] FIG. 14 illustrates one possible configuration for the
transaction collection system 1400. In the embodiment shown,
incoming encrypted data files from the field data collection
network interface units would come through a dial-up network or
modem bank 1401 over a T1 or similar connection 1402 into an entry
router 1403 outside the central site firewall, via a channel
service unit/data service unit 1404 (CSU/DSU) or other similar
device for providing isolation between the network and the
on-premises equipment. Parallel firewall machines 1405, one
operating in "hot back up" mode, filter the inbound data traffic
from validated and secure data sources. In addition to their
primary security role, one of the ancillary functions of the
firewalls 1405 is to load balance the data traffic across all
available file transfer protocol (FTP) engines 1407. A plurality of
FTP engines 1407 are shown in the diagram as being in a scaleable
multi-server configuration, coupled via one or more integration
hubs (e.g. 100 MB or 1 GB Ethernet hubs) 1425. The FTP engines 1407
provide the raw computing power to transfer data packets from the
firewalls 1405, to coalesce the data packets into data files and to
write them to the FTP storage server 1408, which may comprise RAID
(redundant array of inexpensive disk) storage or similar mass
storage.
[0103] In the FTP storage machine 1408, a monitor process scans for
completed inbound files to process. Upon finding such a file, the
file decryption keys are fetched from the central transaction
collection server 1410 and the file name is packaged in a message
packet that is sent to one of a plurality of transaction processor
(TP) engines 1409 in a scaleable multi-server configuration,
coupled via one or more integration hubs 1425. It is noted that the
transaction processor engines 1409 and FTP engines 1407 may
optionally be provided with a console switching unit 1460 for
sharing a single console (e.g. monitor, mouse, keyboard) across the
plurality of engines 1407, 1409. A transaction processor engine
1409 (TPE), upon receiving this message packet, then has sufficient
information available to locate, to decompress and to decrypt the
inbound data file into its component data record types. The various
received data record types are stored in a database (e.g.
Structured Query Language, or SQL) on the transaction collection
server 1410. The transaction collection server 1410 database is
configured across several partitioned sets of physical hardware
1411 set up for RAID storage operation. The primary purpose for
spreading the databases over several pieces of physical and logical
hardware and/or software is to avoid having single points of data
congestion and equipment failure. The transaction collection server
1410 database is the destination for all the data collected at all
the retail processing locations. On a scheduled production basis,
the data is aggregated and sorted, according to the biller
identification associated with each transaction customer account
number. ACH transaction files are prepared and formatted by biller
identification, which then maps into biller-designated destination
ABA bank routing and bank account numbers.
[0104] The administrative/data reporting server 1420 provides
access to a copy of the production data for back office operations
and monitoring by one or more work stations 1427, without burdening
the front end collection system. In the embodiment shown, the
"glue" that holds the whole network together is one or more 100 MB
or 1 GB Ethernet hubs 1425. This technology provides the foundation
cornerstone by which various elements of the network communicate
with each other and access each other's mass storage as local
devices. The web/fax server 1430 provides on-demand reports to
retailers through a web server application. It also provides
periodic reports to retailers that can be faxed out through the
normal public telephone network 1445. The electronic transmission
interface (ETI) machine 1440 prepares the data that has been
accumulated and processed by the transaction collection server 1410
for transmission to the Federal Reserve ACH Network. It formats the
data into the correct ACH CIE (customer initiated entry) format and
transmits this data file to the appropriate destination bank
interface. An optical drive 1432, tape storage unit 1433, or other
such storage means may be provided for creating removable backups,
which may be stored off-site.
[0105] In the CIE Entry Detail Record format, the following
exemplary fields are populated with bill payment information:
AMOUNT (Field 6) is populated with the Customer Payment; INDIVIDUAL
NAME (Field 7) is populated with the Transaction Sequence Number
(which contains the Julian date of payment); INDIVIDUAL
IDENTIFICATION NUMBER (Field 8) is populated with the Biller
Customer Account Number; and DISCRETIONARY DATA (Field 9) is
populated with the Payment Complete Time encoded as a two digit
time field ranging from 00 to 95. This number may be divided by 4
to calculate military hours (decimal) to the nearest quarter hour.
For example, the number 26 divided by 4 would yield 6.5 (0630 or
6:30 AM). The remaining fields in the CIE Record format are
populated with mandatory banking information data, such as biller
ABA and account number.
[0106] A print control station 1470 is coupled to one or more print
engines 1471 for handling printer transmissions to one or more
laser printers 1472 for a variety of report and other printing
functions.
[0107] FIG. 15 illustrates an exemplary transaction processor
executive controller (TPEC) display screen 1500, in one embodiment
of the invention. The TPEC monitor program resides in the FTP
storage server 1408 and is responsible for detecting complete
inbound data files from the field retailer based data communication
network interface units. When an inbound data file is detected,
TPEC fetches the file decryption key from a master database and
then dispatches it and the data file name to one of the transaction
processor engine (TPE) 1409 program threads. The TPE 1409
decompresses and decrypts the inbound data file and stores the
component plain text data records in the SQL database that resides
within the transaction collection server 1410 on RAID storage 1411.
As shown, display screen 1500 may include features such as jobs
attempted 1501 (i.e. batches received) and transactions processed
1502 (i.e. individual data records processed from the batches
received). This display 1500 shows the current Transaction Process
Engine(s) batch job statistics for the system batch dated
10/12/2000 at 13:44:31. As shown, TPEC is in PAUSEd State--it is
not currently dispatching any detected inbound data files to the
TPE engines 1409. For this batch, 129 inbound data files were
processed that resulted in 244 data records, stored in the SQL
database.
[0108] FIG. 16 illustrates an exemplary system monitor station
(SMS) display screen 1600, in one embodiment of the invention. This
display 1600 shows that individual retailers may be configured in a
directory tree-like structure, with each of a plurality of
distributors 1601 being a parent to one or more retailer bill pay
sites 1602. The directory framework of retailers 1602 may conform
to any convenient form of administrative structure, e.g. a
distributor model, based on a hierarchy of people, or a physical
model, based on territories with defined boundaries (states,
counties, or towns). Also illustrated in this display is the
placement of INSTRUCTION files 1603 that can reside at any level
within an arbitrary configuration structure. An INSTRUCTION file
1603 contains operational directives to be applied to retailer
terminals at or below the level of placement in the directory
structure (i.e. transaction pricing, unit transmission schedule,
revised configuration parameters).
[0109] FIG. 17 illustrates an exemplary end of batch monitor (EBM)
display screen 1700, in one embodiment of the invention. When the
current system batch is closed out, this display 1700 shows the
status of the various data processing phases (e.g. system batch
1701) that take place when the collection of received transaction
data batches from the retail data communication network interface
units are consolidated and sorted by biller for electronic
transmission. EBM may be a Visual Basic program that orchestrates
the series of Structured Query Language (SQL) scripts and ancillary
programs to perform transaction consolidation, general system batch
reporting, database trimming and data archiving.
[0110] FIG. 18 illustrates an exemplary electronic transmission
interface (ETI) display screen 1800, in one embodiment of the
invention. This display 1800 includes a summary 1801 of the dollar
amounts sent to each of the electronically connected remittance
partners. The batch status window 1802 shows the current status of
the transmission batches (QUEUED, ACTIVE, DELETED, or COMPLETED).
An additional column (not shown) may be included to show the
confirmed time of transmission completion.
[0111] FIG. 19 illustrates an exemplary ETI transaction detail
display screen 1900, in one embodiment of the invention. For a
specific partner (in the example shown, MasterCard RPS), this
display shows the details for each remitted transaction - biller
name 1901, originating source transaction detail for direct
traceability 1902, customer account number 1903 and amount paid
1904. From an electronic perspective, the biller is only interested
in the payment amounts to be applied to various customer account
numbers.
[0112] FIG. 20 illustrates an exemplary ETI map biller-to-partner
display screen 2000, in one embodiment of the invention. For each
biller defined in the system, there is a one-to-one mapping of
electronic destinations. While ninety-five percent or more billers
may have their remittances delivered via the Federal Reserve ACH
network, the remainder of the remittances may be delivered by a
combination of directly connected links and secondary consolidator
links. Display screen 2000 shows, for each biller, a Biller ID 2001
and Biller Name 2002 mapped to a particular electronic destination
2003. Not explicitly demonstrated by this display is the implicit
dynamic mapping of internal Biller IDs 2001 to external Merchant
IDs (depending on the electronic link utilized) that has to take
place for this system to interoperate successfully with a variety
of external electronic networks. Different electronic links may
also have different data formats, as those skilled in the art will
appreciate.
[0113] FIG. 21 illustrates an exemplary transaction browser display
screen 2100, in one embodiment of the invention. For every
transaction processed through the collection system, the
transaction browser program accesses and displays all the relevant
information pertaining to that transaction, either locally or
through a secure Web Server Application access to remote billers.
Such information may include, e.g., a selection entry portion 2101,
check and trail record 2102, and payment record 2103. (It should be
noted that the bill image would typically not be transmitted to the
transaction collection system, and that it is shown in this figure
for illustrative purposes only.) The system derives the biller
account number from the proposed standard format of biller
imprinted bar codes, as described herein.
[0114] In summary, the primary function of the central site
transaction collection system 1400 is to collect transaction data
from the retail network, sort and aggregate the data by biller, and
to remit the customer payment data and the money to the biller by
the Federal Reserve ACH Network. In the same way that customer data
is collected, processed and credited to individual billers, the ACH
Network is used to electronically debit the retailers for the
payments that they have collected from their customers. The
transaction fee, paid by the customer, may be shared by the
retailer and the transaction processor.
Central Biller Registry System
[0115] The current state of the bill payment industry is very
fragmented, and many billers currently print their own customer
invoices to suit the needs of their own remittance processing
systems. There is no universal invoice printing standard to which
everyone adheres because there is no economic motivation to do so.
Several primary items are required for a bar coded customer bill
payment system to succeed: (1) an industry standard that is
relatively simple to implement with little or no marginal cost; and
(2) a sufficiently large network of retail establishments, induced
by the economic incentives of taking bill payments with little or
no marginal cost; and (3) a method of delivering totally
error-free, electronically remitted customer payment data and funds
to billers at no charge.
[0116] From a business point of view, there are several
organizations that, once persuaded, might provide the required
motivation momentum in each of these areas. With this assumption in
hand, a central registry system would be required to collect
information and to assign the bar code biller identification
numbers, in the same manner that Network Solutions assigns domestic
Internet addresses for the World Wide Web or the Uniform Code
Council assigns UPC codes for the retail industry.
[0117] In one embodiment, assigned biller bar code identification
numbers may be 7 digits in length. The first 6 digits identify the
biller (in a maximum population of 1 million) with the 7.sup.th
digit being the check digit. For every biller bar code
identification assigned, the following information might be
required for central collection: (1) Biller Name, Address, Phone
Number, Fax Number; (2) Biller Administrative Contact Name, Phone
Number, E-Mail Address; (3) Biller Remittance Contact Name, Phone
Number, E-Mail Address; (4); Electronic Connection Type (ACH or
Direct); (5) Bank Name, Address, Remit Account Information, Type;
(6) Bank Contact Name, Phone Number, E-Mail Address; (7) Account
Number Information--detailed account format specifications. Having
collected the foregoing information, a biller bar code
identification number would be assigned and a set of bar code print
specifications sent to the biller contact. It would then be the
responsibility of the biller to print and to remit a set of test
bill remittance stubs for conformance testing and validation.
Conformance testing on the set of sample bill remittance stubs
would ensure that the bar code image quality and physical bar code
dimensions satisfied the lowest common denominator bar code
scanners at retail. Validation testing would ensure that
information, supplied by the biller, regarding the printed bar
coded customer account number conformed to published account number
validation specifications.
Payment Time Stamp Via Federal Reserve ACH Network
[0118] The INDIVIDUAL NAME field (Field 7) in the ACH CIE Batch
Detail Record contains the customer payment transaction number,
which is composed of the following 4 data fields: DCNI unit
identification (7 digits), last digit of year (1 digit), Julian
Date (3 digits), and the transaction sequence number (4 digits).
While the DCNI unit number identifies the retailer where the
customer payment was taken, the next four digits specify the year
and the Julian date of payment submission and completion. The
DISCRETIONARY DATA (Field 9) in the ACH CIE Batch Detail Record may
be populated with the Payment Complete Time encoded as a two digit
time field ranging from 00 to 95. As stated above, this number may
be divided by 4 to calculate military hours (decimal) to the
nearest quarter hour. For example, the number 26 divided by 4 would
yield 6.5 (0630 or 6:30 AM). Time synchronization may be acquired
from universal time standards available through the Internet or
national dial-up time services (U.S. Naval Observatory, Washington,
D.C. or the National Institute of Standards and Technology,
Boulder, Colo.).
[0119] Whether or not sanctioned by a governmental agency, such as
the U.S. Post Office, this time stamp could be recognized in much
the same way that the U.S. Post Office postmark on letters is used
to prove on-time submission. The customer would have printed proof
of payment date and time, by virtue of his store receipt, that a
biller could not artificially manipulate for purposes of assessing
penalty payments. The biller would also have electronic access to
this field as well. Currently, the biller has no automated means by
which to read the U.S. Post Office postmark for proof of on-time
bill payment submission (nor is there any incentive to do so). Bill
payment "due date" as specified in the small print of every credit
contract can have a variety of individual definitions, none of
which is directly visible to or traceable later by the customer. A
universal bill payment time stamp would eliminate all the
variability of these "due date" definitions if the biller
recognized this time stamp as the creditor date of receipt as
specified in the Federal Reserve Regulation Z Section 226.10.
[0120] The advantage of this date stamping mechanism to the
customer is that it would give him marginally more time to remit
his bill payment on time to the biller. In the extreme, the
customer could pay his bill payment at a late-hours store at one
minute to midnight on the due date. The customer would no longer
have to worry about remittance delivery times. The advantage of
this date stamping mechanism to the biller is that extremely late
payments may be electronically credited to the biller no later than
36 hours after customer payment. In the majority of cases in which
the biller had multiple daily data feeds from his bank, the credit
would probably issue in fewer than 24 hours. Electronically
delivered and electronically applied, the current level of biller
effort in the handling of late payments would be entirely
eliminated with this system in place. In the extreme case, billers
could safely invoke 48-hour cut-off notices with little or no error
of service call recalls.
[0121] Electronically remitting data and money through the Federal
Reserve ACH Network only works for those billers whose customer
account numbers are less than or equal to 22 digits which is the
current maximum width of Field 8, INDIVIDUAL IDENTIFICATION NUMBER,
using the standard CIE Entry Detail Record format. If a remitted
customer account number is longer than 22 characters, then either
one of two possible solutions is available: using Field 3, 80
columns of data in the CIE Addenda Record format; or implementing a
dedicated data link to the biller with a biller specific data
format.
Alternative Electronic Networks to Accommodate Special Billers
[0122] For high volume billers preferring to have their data
delivered to them faster than the current Federal Reserve ACH
Network delivery schedule, direct file transfer links (e.g. FTP)
from the ETI machine through the Internet may be made available.
File data formats and the particular delivery mechanisms may be
tailored to meet any biller requirement, so long as it expedites
the flow of customer payment information. In this mode of
operation, biller data would be available for processing within
minutes after the scheduled transaction collection system
production "system roll" completes. The "system roll" sorts and
aggregates biller data on a daily production schedule--once every
12 hours. Payment totals for these transaction batches would be
delivered via the ACH Network. For a trusted remitter, it is not
necessary to directly couple the transaction dollars with the
transaction data. The time lag between transaction data and
transaction dollars via the Federal Reserve ACH Network should be
no more than 24 hours.
Improved Payment Embodiments
[0123] The embodiments described hereinabove relate, generally, to
bar code based biller/payor systems for electronic bill payment. As
described hereinabove, it is contemplated that, in an exemplary
electronic bill payment infrastructure (e.g., see reference numeral
500 of FIG. 5) consistent with the invention, consumers can pay
their bills at supermarkets and large retail chain stores and
receive immediate credit from billers for their payments. In such
an infrastructure, the biller receives good payment funds,
deposited directly into his bank account, and error-free electronic
payment data for consumer bill payments by 6 AM the very next
business day. Contractually, the biller backdates the received bill
payments to the "electronic postmark" time and date paid at retail,
regardless of the time that the payment data takes to post to the
biller's accounts receivable system. Compared to the present paper
based remittance processes commonly employed throughout the
payments industry today, such an infrastructure provides for an
electronic process that remits error-free payment funds and data
directly to billers within hours, rather than days.
[0124] As efficient as this electronic bill payment process may be,
it may not be fast enough for the needs of Internet commerce based
companies, selling products to electronically connected remote
consumers. The electronic bill payment process, as described
hereinabove with respect to billers and payors, still depends on
the biller generating a paper bar coded invoice statement and
sending it to the consumer by US Mail, a process that can take, on
average, anywhere between 6-8 days. When the consumer has the
financial resources in hand to pay his bill, he can then remit his
payment directly to the biller, electronically, within hours.
[0125] In an improvement to the electronic infrastructure for this
process, described in this section, Internet commerce-based
companies can now choose a new bill payment method that is very
simple and can reduce the time interval between biller invoice
statement generation and consumer payment notification to the
biller, to less an hour.
[0126] Another improvement to the electronic infrastructure for
this process, described in this section, is the provision for
person-to-person money transfers. Currently, there are several
organizations that offer electronic person-to-person money
transfers as long as the sending and receiving parties deposit and
receive their remitted funds within the same organizational network
of geographically dispersed branch offices. What may be a
convenient remittance location for the sender may not be so for the
receiver and/or vice-versa. Person-to-person money transfers can be
easily accomplished with a bar coded deposit slip that permits a
sender to remit funds directly into a receiver's bank account, and
such funds are subsequently accessible for withdrawal at a nearby
and convenient Automated Teller Machine (ATM) or for a debit card
purchase. The details of these improvements are discussed
hereinbelow:
Improved Electronic Bill Payment Network
[0127] The embodiments described in this section relate to an
improved national electronic bill payment network, wherein bar
coded invoice statements are generated immediately by the biller or
the consumer and remitted to the consumer in the span of seconds to
minutes via facsimile, e-mail or other image transmission method.
Upon receipt of such an imaged invoice statement, the consumer,
with payment in hand, may go to a local store that accepts and
processes these bill payments. When the consumer payment is
processed at retail, it is electronically remitted to the biller
with absolute accuracy within 24 hours after receipt of payment,
and electronic notification to the biller may occur within minutes
after receipt of payment, with no payment repudiation.
[0128] Such an electronic bill payment network offers the following
benefits: The biller benefits by receiving 100 percent accurate
electronic bill payment information and good funds, delivered into
his bank account by 6 AM the very next business day that can be
directly applied to his accounts receivable. The biller benefits by
receiving an immediate electronic notification of consumer payment
at retail with funds that cannot later be retracted. As a result,
billers can then ship the consumer product sooner, thereby raising
consumer satisfaction levels with their Internet portal. The
consumer benefits by receiving an immediate electronically
delivered bar coded invoice statement for his Internet shopping
basket of products via facsimile, e-mail or other image
transmission method. The consumer benefits because he can then pay
his bar coded invoice statement locally with his choice of cash,
check, debit card or any credit card for his Internet shopping
basket without having to disclose any personal financial
information to a remote Internet store. Further, local payment
precludes the possibility of future fraud resulting from hackers'
or others' unlawful access to any stored financial information left
and residing at remote Internet stores. The local retail
establishment benefits by receiving a relatively cost-free margin
from each payment transaction taken. Finally, it is anticipated
that a national enhanced network with many retail outlets will spur
the demand for yet new immediate and electronically delivered
financial products and services, using "signature" specific bar
codes, and thus, may generally benefit the economy of the country
or other geographic area in which it is implemented.
[0129] An exemplary embodiment of the improved bar coded bill
payment based system consistent with the present invention utilizes
a bar code on the biller invoice, which is delivered to the
customer electronically, i.e., by fax, e-mail, or, other image
transmission method, and payment information and payment credits
are returned to the biller electronically. This system may augment
some elements of the biller/payor network 500 (described
hereinabove with respect to FIG. 5) with faster and parallel
processing elements. In this case, the biller accounts receivable
and US Mail consumer remittance mechanisms may be enhanced with a
new accounts receivable invoice statement image generation
mechanism that can be activated, on demand, either by a biller
customer service representative or by a consumer initiated action.
The result of either action is a bar coded invoice statement image
that is electronically remitted to the consumer within a time frame
of seconds to minutes. The transaction collection system described
hereinabove, which already has an inherent user Internet accessible
transaction browser capability, may be enhanced with e-mail,
facsimile or other means of electronic notification to the biller
when specifically designated payments have been received. An
automated caller response system may provide for consumer inquiry
confirmation of payments.
[0130] Turning now to FIG. 22, an exemplary improved electronic
bill payment network 2200 is illustrated. For all the goods and
services rendered to a consumer over a given traditional billing
period (or interactive Internet shopping session), the biller
accounts receivable 2202 may accumulate a dollar total and generate
a detailed bar coded invoice statement image 2203 that can be
electronically remitted to the consumer 2204. This same process can
also be used by a biller customer service representative 2201 to
replicate a previous invoice statement that a consumer may have
lost. For example, if a consumer wants an immediate replacement
copy of the invoice for payment, the consumer can access a biller
web site to generate a remittance or deposit document. The time for
a consumer to request the electronic invoice statement 2203 may be
as little as a few minutes after a request is made. The invoice
2203 is transmitted to the consumer 2204, which transmission may be
from a few seconds to several minutes, depending on factors such as
the method of transmission, queue capacity, and number of open
queue slots. The consumer 2204 receives the bar coded invoice
statement image 2203.
[0131] To pay the bill, the consumer 2203 might go to a local store
(or other location with appropriate hardware/software/network
connection) that processes these bill payments. The time for this
to occur is variable, depending upon the consumer's circumstances,
and may occur in as little as a few minutes. The consumer 2203
presents his imaged bar coded invoice statement 2203 to the
checkout cashier for scanning by the checkout scanner 2205, which
may be done while other retail UPC coded items are being scanned.
Instead of looking up an in-house UPC code for pricing, the scanner
2205 would pick up the bill payment bar code that identifies the
biller to be paid and the account number to be credited. The
consumer tells the checkout cashier the amount to be paid on that
account and his option for requesting "normal" or "express" payment
processing, and the cashier inputs the amount to be paid into a
terminal (which may be integrated into a point-of-sale system)
which is in communication with a backend host processing system
2206. The checkout of remaining products and items (or bills)
continues until the complete total for all goods and services is
calculated. Upon receiving payment from the consumer, that bill
payment is then complete. The consumer may receive a printed
receipt of the payment tendered with the date and time the payment
was made. The in-store backend host processing system 2206
immediately completes and forwards all the payment data to the data
collection network interface unit 2207, which may occur in a little
as a few seconds.
[0132] The data collection network interface 2207 (DCNI) unit
collects and stores all the consumer bill payment data in
non-volatile memory. Periodically (e.g., throughout the day, and/or
based on time and transaction volume thresholds), the DCNI 2207
transmits the bill payment data to the central site transaction
collection system 2211, which is part of a central site computer
system 2210 that may also include an Internet server/browser 2212
and/or automatic caller response system 2213. Additional
transmissions may be scheduled before the daily transaction
collection system 2211 aggregation times. If a particular consumer
payment is designated for "express" processing, it may immediately
be transmitted to the central site computer system 2210 when the
transaction void window expires for that payment. The time for the
back-end and collection system processing has no impact on customer
payment time, since all payments may be time-stamped. Separately
calculated calendar day payment counts and totals may also be sent
to the transaction collection system 2211 as an independent
transaction audit balancing mechanism.
[0133] The transaction collection system 2211 may continuously
(and/or periodically) receive payment data information from a
distributed network comprising a plurality of data collection
network interface units 2207 deployed at field retail
establishments. Before the last processing window closes at the
Federal Reserve Automated Clearing House (ACH) Network 2214, all
customer payments may be sorted and aggregated for direct remission
to their respective billers, which may take approximately an
hour.
[0134] As the transaction collection system 2211 receives payment
data information from the network of data collection network
interface units 2207, it processes and stores each consumer bill
payment into a database. Once stored in the database, that payment
and ancillary information can be viewed with a local transaction
browser or Internet web site display 2212. When "express" payments
are encountered in the payment data stream, immediate electronic
notification may be posted to the biller in one of several possible
forms: e-mail, facsimile or biller specified custom electronic
form. Accessible from that same database information, an automated
caller response system 2213 can verbally confirm the receipt of a
particular transaction, particularly for customers 2209 seeking
"comfort call" confirmation regarding the status of a payment. For
"normal" payments, the biller customer service toll-free number may
be nominally printed on the consumer receipt. For "express"
payments, the biller customer service toll-free number may be
replaced with a special in-house toll-free number to relieve biller
customer service representatives 2208 of nervous consumer
confirmation inquiry calls, typically for payments that are long
overdue.
[0135] Processing and distribution of electronic payment data may
be done using the Federal Reserve Automated Clearing House (ACH)
Network 2214, which may take 6-9 hours. At the biller's bank 2215,
the electronic payment data may be received from the ACH Network
2214 and stripped and reformatted according to biller specified
formats, which may take 4-6 hours. Finally, the biller's accounts
receivable 2202 and/or customer service computer files may be
updated. Depending on the "legacy factor" of the biller's computer
processing systems, this process can range anywhere from 2-3 hours
to 4-5 days.
[0136] From both the biller's and consumer's perspective, the
payment network/system 2200 described in this section may be
contrasted with the biller-payor network/system 500 (described
hereinabove with reference to FIGS. 5 et seq.), as follows:
[0137] From the biller perspective, both networks 500, 2200 may be
capable of delivering good payment funds and data directly into the
biller's bank account by 6 AM the next business day after the
consumer pays his bill at retail. The improved network 2200 may
deliver electronic notification of consumer payment information to
the biller within minutes after the payment is made at retail with
the "express" delivery service. All payment funds collected can
remain safe and secure within the Federal Reserve banking system
network at all times. Moreover, the improved network 2200 can
deliver a consumer invoice electronically and immediately, assuming
the biller can generate and remit an electronic invoice statement
image 2203 and the consumer has a corresponding device or means
with which to receive the electronic biller invoice statement image
(e-mail, facsimile etc.). With this enhanced network 2200, the
biller, having Internet access and using his choice of standard
Internet browsers, can confirm a consumer's payment by querying the
database of processed transactions in the transaction collection
system 2211 with a variety of database selection keys and criteria.
Further, the biller can receive full payment funds for the amount
stated on the bar coded invoice statement 2203. This point is
especially important when it comes to paying various governmental
and state license, permit and tax fees. By statute, many states and
governmental organizations cannot accept the payment of license,
permit and tax fees from consumers using either credit or debit
cards because of the subsequent discounted payments remitted.
Third-party payment surcharges, directly assessed from the consumer
over and above the due payment amount, are generally acceptable.
For example, the Commonwealth of Massachusetts has 307 different
types of license, permit and tax fees that must be paid by
consumers either by check or cash.
[0138] From the consumer perspective, the consumer can have a
choice of local payment method (e.g., cash, check, debit card or
any credit card), when paying a bar coded invoice statement 2203 at
retail. The consumer does not have to divulge any personal
financial information to a remote Internet storefront that
electronically generates and delivers bar coded invoice statements
directly to a consumer. With this enhanced network 2200, the
consumer can subsequently confirm the electronic receipt of his
processed payment at retail from an automatic caller response
system 2213. Further, with this enhanced network 2200, the
consumer, having Internet access and using his choice of standard
Internet browsers, can confirm his own payment by querying the
database of processed transactions in the transaction collection
system 2211 with a specific transaction identification number.
[0139] Presently for Internet commerce based companies, there is no
mechanism available for conducting a purely "cash" sale over the
Internet, where consumer cash and retail product can be exchanged
in one anonymous atomic transaction. Currently, problems abound
with all other forms of present payment methods, as follows:
[0140] Payment method fees always erode the profit margin of any
retail or Internet storefront. Credit and debit card companies
charge retail merchants varying commissions, based on a variety of
factors that can range upwards from 2% of the purchase price. By
law, these merchants cannot charge consumers different prices for
the same retail product whether paid for with cash or by credit.
Check guarantee companies impose processing charges on every
consumer check passed through their service. Third party "e-wallet"
payment type companies also charge for their value-added services
as well. Therefore, the merchant absorbs these various discounts
from his profit margin as a normal "cost of doing business".
Checks, if exchanged, take time to clear and can be "stop paid" at
the whim of the consumer. No one is exposed in this situation if
the seller chooses to wait out the prescribed check clearing time
(on average, approximately 4-5 days); however, ultimate consumer
satisfaction will be impacted by this delay. Credit card
transactions require the consumer to divulge personal financial
information to the remote Internet seller, which leaves open the
potential for future and untraceable fraud. Then, that credit card
transaction can be disputed and repudiated by the consumer, up to
60 days later, leaving the seller with an uncollectable debt. While
debit card transactions cannot be repudiated, they also require the
consumer to divulge personal financial information to the remote
Internet seller, again, leaving open the potential for future and
untraceable fraud. The consumer generally has no guaranteed
recourse to recover any stolen funds debited from his account.
Third party "e-wallet" payment type companies that require
consumers to register their bank account numbers for secured
transaction payments over the Internet are ripe for large-scale
fraud. The consumer generally has no guaranteed recourse to recover
any stolen funds debited from his E-Wallet.
[0141] The enhanced electronic bill payment network 2200 consistent
with the present invention permits remote buyers and sellers to
perform anonymous "cash" sale transactions, using the Federal
Reserve banking system as the trusted escrow agent to safely and
securely transfer funds between buyers and sellers.
[0142] An advantageous feature of this enhanced bill payment
network, with a standardized bar coded bill payment "signature"
featured as its centerpiece remittance mechanism, is that all the
non-deterministic time delays have been removed from the total bill
payment cycle. In legacy bill pay arrangements, the two largest
delay factors are the biller invoice paper statement preparation,
printing, mailing systems and the US Post Office mail delivery
system. With the present invention, the consumer can now exercise a
larger control function over his bill payment remittance process.
The consumer can request an immediate invoice statement, which only
requires minutes to formulate and to deliver electronically. The
consumer has his choice of payment methods at a trusted local
retail establishment and receives a printed bill payment receipt
confirmation, guaranteed by the biller. The consumer payment method
to the biller is completely anonymous, in terms of divulged
personal financial information. Subsequently, the consumer, as well
as the biller, can verify that the bill payment has been received
and processed at the central payment distribution site. Thereafter,
payment funds and information may be electronically remitted to the
biller within hours, by 6 AM the following business day directly
into the biller's bank account.
[0143] It should be recognized by those skilled in the art that,
although the foregoing description refers to a bar code transmitted
by e-mail or by facsimile, other methods of transmission are
possible and are included in the invention, e.g., facsimile
transmission to or from a computer, facsimile machine, e-mail, file
transfer protocol (FTP), hypertext markup language (HTML), extended
markup language (XML), hypertext transport protocol (HTTP), modem,
the Internet, a wide-area network (WAN), a local-area network
(LAN), diskette, or other removable storage medium.
Money Transfer Embodiments
[0144] In the above descriptions of an exemplary electronic bill
payment network 500 (described hereinabove with reference to FIGS.
5 et seq.), references have been made regarding the extensibility
of this network and its internal structure to provide for new,
cost-effective financial products and services. Domestic and
international person-to-person money transfer services is one such
product described here. (Of course, the money transfer technology
described in this section may also have applicability to
business-to-person, person-to-business, business-to-business, or
other types of money transfers.)
[0145] The current forms of domestic and international money
transfer services offered today are very labor intensive for both
the person sending the money as well as the service provider. The
amount of paperwork that has to be filled out by the sender and
then manually transcribed into a "communication system" by the
service provider has been the ostensible justification to the
customer of the high fee structure to provide this service. In
point of fact, this service is extremely profitable, which is aptly
demonstrated by the fact that there are so many large and small
money transfer service providers in this industry, primarily
serving immigrant communities whose members regularly send money to
their home country families. Some service providers, such as
Western Union, use relatively "high tech" electronic communication
services to transfer funds while other small service providers use
"low tech" courier services to physically transport funds to their
intended destination.
[0146] Currently, there are several organizations that sell
domestic or international electronic person-to-person money
transfers as long as the sending and receiving parties deposit and
pick up the remitted funds within the same organizational network
of geographically dispersed branch offices. Fees for this service
can range upwards from $35 per transfer. However, convenient
remittance locations for the local sender may not have
corresponding convenient delivery locations for the remote
receiver, or vice-versa.
[0147] In a system consistent with the present invention, domestic
person-to-person money transfers can be easily accomplished with a
bar coded deposit slip that permits a remote sender to remit funds
directly into a receiver's bank checking account, providing funds
that are subsequently accessible at a convenient local automated
teller machine (ATM) or for a debit card purchase.
[0148] Future international (e.g., Mexican) person-to-person money
transfers can be coordinated with appropriate financial
organizations or banks that commonly distribute a form of debit
card to their customer base. These organizations would distribute
to their customer base plastic bar coded deposit-only cards keyed
directly to their debit card, which may then be sent to a remitter
in another country (e.g., the United States). Using that bar coded
plastic deposit-only card instead of a bar coded bank deposit slip
would effect a deposit of the funds directly into the debit card
account corresponding to the deposit-only card. In this way,
domestic and international money transfers could cost far less than
the fees charged today for this equivalent service.
[0149] The complete details of a bar coded bill payment "signature"
are described hereinabove in the section entitled "Bar Coding
Validation" with respect to FIGS. 10 and 11, wherein a structure of
successive data envelopes of embedded "signature" data fields are
employed, consisting of a series of format designators, data and
check digits. In the examples of FIGS. 10 and 11, which illustrate
two arbitrary format designator values, the customer account number
consisted of one numeric field whose associated check digit was the
trailing digit of either a divulged format (=3) or an unknown
format (=4) to which the biller appended a check digit according to
a specified algorithm. In both cases, there is an independent
mechanism in place to mathematically check the validity of the
customer account number.
[0150] In the person-to-person electronic money transfer embodiment
described in this section, the retail based electronic bill payment
infrastructure is utilized, with the modification that the biller
identification number is now used to identify the destination
payment network instead of a destination biller organization. In
the U.S. banking system, the standard bank account numbering scheme
is based on a two-part number system consisting of an ABA (American
Banking Association) number (8 digits plus a check digit), uniquely
identifying the U.S. bank institution, and a local account
numbering convention within that banking institution. While the
format designator=4 validation template scheme can reliably be used
to implement a generalized person-to-bank account remittance
mechanism within the structure of the electronic bill payments
infrastructure, the definition of a new format designator
validation template would offer several advantages: An additional
customer account number validation step further reduces data
errors. Within the full customer specified account number, the ABA
portion of the account number can be independently verified. The
biller identification number would be reduced from 6 to 2 digits,
in recognition of the fact that there are many fewer bank based or
money transfer payment networks than billers. With a reduced number
string, shorter bar code strings fit more appropriately on small
banking deposit slips that measure, on average, 6" wide by 3"
high.
[0151] FIG. 23 illustrates an exemplary specification for the new
format designator=5 format. As shown, the bar code 2300 comprises a
1-digit format designator value=5; the number of components (2
fixed length (3, 9), 1 variable length) by definition; 2-digit
payment network identification number; 1 check digit of preceding 2
digits using 37 weights, MOD10 algorithm; 8-digit ABA number
(51066065); 1 check digit of preceding 8 digits using 37137137
weights, MOD10 algorithm; entire customer bank account number
(5106606550766936692) using 1212 . . . weights, split MOD10 with
added check digit to be discarded before presentment to the
destination payment network (4); and calculated check digit of
level 3 envelope using 2121 . . . weights, split MOD10 algorithm
(4).
[0152] As illustrated in FIG. 24, this bar code 2401 appearing on a
bank deposit slip 2400 (or, alternatively, printed on a plastic or
paper card, or printed on other media, e.g., debit card, credit
card, bank card, affinity card, card bearing a magnetic stripe,
identification card, smart card, or card bearing at least one name
corresponding to an account number encoded in said bar code) could
be presented at a retail checkout aisle, equipped for bill payment
transactions, to initiate domestic person-to-person money
transfers. By 6 AM the following business day, the money remitted
the previous day may be available to the recipient to withdraw from
a local ATM machine or to make payment from a debit card keyed or
associated with that account. The ATM or debit card PIN (personal
identification number) provides the same level of access security
to the receiver of these person-to-person money transfers as exists
for local funds that already reside in the account.
[0153] To implement an international (i.e.,
any-person-to-any-person electronic money transfer) using the
retail based electronic bill payment infrastructure, the biller
identification number may be used to uniquely identify the target
destination payment network. In the case of a foreign payment
network based on a system of debit card accounts, the format
designator=4 validation template scheme can reliably be used to
implement and validate any generalized account numbering scheme to
remit finds. A new format designator validation template definition
offers extended customer account number verification advantages
only if the destination payment network is willing to divulge its
mathematical or other method of customer account numbering
validation scheme.
[0154] In a hypothetical exemplary scenario consistent with the
invention, a national chain of retail gas stations/convenience
supermarket stores called GasoMax is located throughout the whole
of Mexico, serving the public at large. GasoMax issues PIN
protected debit cards to all their customers, in effect, setting up
a pseudo-bank account for each of them. Instead of carrying cash,
these customers deposit or apply money to these accounts so that
they can later purchase food staples or convenience items at the
same time they come for fuel. When GasoMax issues these
PIN-protected debit cards to their customer base, one or more bar
coded deposit only cards are included (and/or a bar code might be
printed on the debit card itself). The debit card can either be
used to deposit local money into their account or to withdraw money
in the form of purchases at the national chain GasoMax gas
stations. FIG. 25 illustrates an exemplary GasoMax debit card 2500,
which resembles a standard debit card. FIG. 26 illustrates an
exemplary deposit-only card 2600 comprising a bar code 2601
consistent with the invention. In this exemplary scenario, the bar
coded deposit-only card 2600 (or, alternatively, a bar code printed
on the standard debit card) would be used in U.S. retail stores
that offer access to the electronic bill payment network. Whereas
most customers submit their U.S. based biller bar coded invoice
statements to the cashier for payment, the customer that presents
the GasoMax bar coded deposit-only card 2600 is making a payment to
a destination payment network (Payment Network=51, using a standard
Format Designator=4 description). Payments remitted to this payment
network are automatically converted to local currency by GasoMax at
a better rate than the larger commercial money transfer
organizations. Commercial money transfer companies charge up to $25
per $300 remittance as a foreign exchange (FX) fee on top of the
base $35 remittance fee. In the recent past, wire transfer
companies have been sanctioned for these usurious currency exchange
practices. GasoMax would have a greater incentive to offer a better
exchange rate to its customer base for its money transfer services
than the current crop of commercial money transfer services.
GasoMax could expand its local customer base to shop for goods and
services through its chain of gas station supermarkets that also
offers a convenient money transfer service, as an affinity draw or
loyalty program, for relatives working outside of the country to
support their loved ones in Mexico.
[0155] Several further examples of "real-life" scenarios
demonstrating the utility of an improved payment network consistent
with the invention are provided, as follows:
EXAMPLE 1
[0156] Payment for Mobile Telephone Service
[0157] A client procures a mobile phone subscription from a
well-known national vendor. The client gives his place of
employment as his cell phone billing address. As a new customer, he
is assigned a total credit limit and an accrued monthly limit. When
this client subsequently leaves his place of employment, he forgets
about changing his mobile phone billing address and continues to
use his mobile phone regularly, until one day his mobile phone
stops working. When he calls the customer service office to inquire
about the matter, he finds out that his mobile phone usage is well
within his credit limits but that the reason for his mobile phone
being disconnected is that bill payment is overdue by ten days. The
company does not accept credit card payments and only accepts a
check payment for the total past due amount. The company restores
his service ten days after receiving and processing his check.
[0158] With an enhanced bill payment network consistent with the
invention in place, this client could have remitted his late
payment with the "express" payment service, as described
hereinabove. The mobile phone company would have been
electronically notified minutes after his retail payment, so that
his cell phone service could be restored within an hour, rather
than days.
EXAMPLE 2
[0159] Payment for Internet-based Auction
[0160] The business model for the Internet-based auction (e.g.,
eBay) is very basic in concept, a meeting place for bringing
together Internet buyers and sellers, wherein an electronic
framework displays sellers' goods and services. When a sale is
completed between a seller and a buyer, the online auction house
charges a sales commission. It is the responsibility of the seller
and the buyer to establish a lowest common denominator payment
exchange method. Individuals selling items, are generally not
equipped to process Mastercard or VISA credit or debit cards. If
the seller accepts a personal check payment from the buyer,
shipment of the sold item is delayed until the buyer check clears.
A buyer can mitigate a seller shipment delay if he is willing to go
out and purchase a money order to send to the seller. If the buyer
and seller wish to use a third-party payment clearinghouse, (e.g.,
Billpoint or PayPal), then both must register personal financial
information about their respective bank accounts to transfer money,
as well as pay yet another sales commission charge. In general,
none of these payment alternatives are particularly attractive if a
buyer or seller desires any degree of financial
confidentiality.
[0161] With an electronic payment network consistent with the
invention in place, an online auction house could provide a
cost-effective and value-added anonymous payment alternative within
its framework of auction services. When a sale is completed, the
online auction house provides the means for the buyer to print out
a bar coded invoice statement, citing the online auction house as
the biller of record with a transaction identification number.
Instead of purchasing a money order, which would then have to be
physically remitted, the buyer then pays this invoice at a local
supermarket. When the online auction house receives the electronic
payment the very next business day, it notifies the seller of the
completed payment via e-mail and then sends a check for that
payment amount to the seller. Aside from exchanging their mailing
addresses, both buyer and seller maintain their financial
privacy.
[0162] This same sales paradigm would also work well for home
shopping television channel environments, (e.g., Home Shopping
Network, QVC), wherein the "express" payment option could be used
when buyer desire is at its highest level.
EXAMPLE 3
[0163] Automobile Insurance Payment
[0164] Insurance companies have varying grace periods within which
to pay their insurance premiums, beyond which the policy is
irrevocably canceled. If one cannot or chooses not to pay the
entire annual premium on its anniversary date, an installment plan
of smaller payments may alternatively be offered. If a premium
payment is not received, a cancellation notice is sent toward the
end of the payment grace period specifying a "hard" cancellation
date. If a policy is canceled due to non-payment, depending on the
prior payment history, the insurance carrier may not want to
reissue another insurance policy because of a previous poor payment
record. Therefore, given the gravity of the possible consequences,
time is of the essence when it comes to paying insurance premiums
on time--whether for car insurance, home insurance or personal life
insurance. Mailed late payments may not be delivered and processed
in time. Depending on company policy, even in-person payments
directly to insurance agents, during normal business hours, may or
may not be acceptable. A confirmed electronic payment made using an
enhanced bill payment network consistent with the invention would
provide a way for both the insurance company and insureds to know
precisely when premiums are paid.
EXAMPLE 4
[0165] Payment to College Student
[0166] When a parent agrees to send money for college expenses to a
child away at school, a question that typically arises is, "how
fast do you need the money?" A printed bar coded bill payment
"signature" on out-of-town bank checking account deposit slips
would enable remote deposits with a simple cash, check, debit card
or any credit card payment at a local supermarket. A college-bound
child could have previously sent home an ample supply of these
deposit slips to cover for such eventualities. If a supply of
originals is not available, a facsimile copy (sent at high
resolution mode) will generally perform the job equally well. Funds
deposited with this payment mechanism are electronically available
the very next morning for withdrawal from a local ATM
cash-dispensing machine. For a small fee (e.g., about a dollar),
this service is much faster, more convenient to all parties
involved and cost-effective than any existing person-to-person
money transfer service.
Further Alternate Embodiments
[0167] The present invention may use the public Internet and
Internet compatible HTTP and UDP protocols for the network
interconnections described herein, as well as the Federal Reserve
Automated Clearing House (ACH) Network or other networks. Those
skilled in the art will recognize that the servers and their
various components, as well as any other components described
herein may be implemented in software, hardware, or a combination
of both, and may be separate components or be integrated into other
components described above. Likewise, the processes described
herein may be separate or combined and may run on common, shared,
or separate machines, and as integrated or separate software
modules.
[0168] Additionally, scanning bar codes, in methods consistent with
the invention, may be preformed using, e.g., wand or handheld
scanning devices, scanning devices mounted to or near a point of
sale system, and other such scanning devices, and such devices may
be devices coupled to other devices, e.g., a computer, cash
register, or point of sale system, or alternatively, integrated
therein. A scanning device consistent with the invention may
alternatively be coupled to or integrated into a PDA, handheld or
pocket computer, as well as a mobile telephone or other portable,
wireless, or computerized device. Thus, it is contemplated that an
account corresponding to a mobile telephone or other such device,
or other credit or debit account corresponding to the user of such
a device, could be automatically debited for payment to a payee, in
methods consistent with the invention.
[0169] It will be appreciated by those skilled in the art that,
although the functional components of the above described
embodiments of the system of the present invention are embodied as
one or more distributed computer program processes, data
structures, dictionaries or other stored data on one or more
conventional general purpose computers (e.g. IBM-compatible, Apple
Macintosh, and/or RISC microprocessor-based computers), mainframes,
minicomputers, conventional telecommunications (e.g. modem, DSL,
satellite and/or ISDN communications), memory storage means (e.g.
RAM, ROM) and storage devices (e.g. computer-readable memory, disk
array, direct access storage) networked together by conventional
network hardware and software (e.g. LAN/WAN network backbone
systems and/or Internet), other types of computers and network
resources may be used without departing from the present
invention.
[0170] The invention as described herein may be embodied in one or
more computers residing on one or more server systems, and
input/output access to the invention may comprise appropriate
hardware and software (e.g. personal and/or mainframe computers
provisioned with Internet wide area network communications hardware
and software (e.g. CQI-based, FTP, Netscape Navigator.TM. or
Microsoft Internet Explorer.TM. HTML Internet browser software,
and/or direct real-time TCP/IP interfaces accessing real-time
TCP/IP sockets) for permitting human users to send and receive
data, or to allow unattended execution of various operations of the
invention, in real-time and/or batch-type transactions and/or at
user-selectable intervals. Likewise, it is contemplated that the
above-described servers consistent with the present invention may
be remote Internet-based servers accessible through conventional
communications channels (e.g. conventional telecommunications,
broadband communications, wireless communications) using
conventional browser software (e.g. Netscape Navigator.TM. or
Microsoft Internet Explorer.TM.), and that the present invention
should be appropriately adapted to include such communication
functionality. Additionally, those skilled in the art will
recognize that the various components of the system of the present
invention can be remote from one another, and may further comprise
appropriate communications hardware/software and/or LAN/WAN
hardware and/or software to accomplish the functionality herein
described. Alternatively, a system consistent with the present
invention may operate completely within a single machine, e.g. a
mainframe computer, and not as part of a network.
[0171] Moreover, each of the functional components of the present
invention may be embodied as one or more distributed computer
program processes running on one or more conventional general
purpose computers networked together by conventional networking
hardware and software. Each of these functional components may be
embodied by running distributed computer program processes (e.g.,
generated using "full-scale" relational database engines such as
IBM DB2.TM., Microsoft SQL Server.TM., Sybase SQL Server.TM., or
Oracle 8.0.TM. database managers, and/or a JDBC interface to link
to such databases) on networked computer systems (e.g. comprising
mainframe and/or symmetrically or massively parallel computing
systems such as the IBM SB2.TM. or HP 9000.TM. computer systems)
including appropriate mass storage, networking, and other hardware
and software for permitting these functional components to achieve
the stated function. These computer systems may be geographically
distributed and connected together via appropriate wide- and
local-area network hardware and software.
[0172] Primary elements of the invention may be server-based and
may reside on hardware supporting an operating system such as
Microsoft Windows NT/2000.TM. or UNIX. Clients may include
computers with windowed or non-windowed operating systems, e.g., a
PC that supports Apple Macintosh.TM., Microsoft Windows
95/98/NT/ME/2000.TM., or MS-DOS.TM., a UNIX Motif workstation
platform, a Palm.TM., Windows CE.TM.-based or other handheld
computer, a network- or web-enabled mobile telephone or similar
device, or any other computer capable of TCP/IP or other
network-based interaction. The communications media described
herein (generally referred to using the generic term "network") may
be a wired or wireless network, or a combination thereof.
[0173] Alternatively, the aforesaid functional components may be
embodied by a plurality of separate computer processes (e.g.
generated via dBase.TM., Xbase.TM., MS Access.TM. or other "flat
file" type database management systems or products) running on
IBM-type, Intel Pentium.TM. or RISC microprocessor-based personal
computers networked together via conventional networking hardware
and software and including such other additional conventional
hardware and software as is necessary to permit these functional
components to achieve the stated functionalities. In this
alternative configuration, since such personal computers typically
are unable to run full-scale relational database engines of the
types presented above, a non-relational flat file "table" may be
included in at least one of the networked personal computers to
represent at least portions of data stored by a system consistent
with the present invention. These personal computers may run, e.g.,
Unix, Microsoft Windows NT/2000.TM. or Windows 95/98/ME.TM.
operating system. The aforesaid functional components of a system
consistent with the present invention may also comprise a
combination of the above two configurations (e.g. by computer
program processes running on a combination of personal computers,
RISC systems, mainframes, symmetric or parallel computer systems,
and/or other appropriate hardware and software, networked together
via appropriate wide- and local-area network hardware and
software).
[0174] As those in the art will recognize, possible embodiments of
the invention may include one- or two-way data encryption and/or
digital certification for data being input and output, to provide
security to data during transfer. Further embodiments may comprise
security means in the including one or more of the following:
password or PIN number protection, use of a semiconductor, magnetic
or other physical key device, biometric methods (including
fingerprint, nailbed, palm, iris, or retina scanning, handwriting
analysis, handprint recognition, voice recognition, or facial
imaging), or other security measures known in the art. Such
security measures may be implemented in one or more processes of
the invention.
[0175] Source code may be written in an object-oriented or
non-object-oriented programming language using relational or
flat-file databases and may include the use of other programming
languages, e.g., C++, Java, HTML, Perl, UNIX shell scripting,
assembly language, Fortran, Pascal, Visual Basic, and QuickBasic.
It is noted that the screen displays illustrated herein at FIGS.
15-21 are provided by way of example only, and are not to be
construed as limiting the invention or any component thereof to the
exemplary embodiments illustrated therein.
[0176] Furthermore, it is contemplated that the system and method
described herein may be implemented as part of a business method,
wherein payment is received from users, which might include
customers, retailers, and/or billers employing the invention. Such
users may pay for the use of the invention based on the number of
files, messages, bills, or other units of data sent or received or
processed, based on bandwidth used, on a periodic (weekly, monthly,
yearly) or per-use basis, or in a number of other ways consistent
with the invention, as will be appreciated by those skilled in the
art.
[0177] Those skilled in the art will recognize that the present
invention may be implemented in hardware, software, or a
combination of hardware and software. Finally, it should also be
appreciated from the outset that one or more of the functional
components may alternatively be constructed out of custom,
dedicated electronic hardware and/or software, without departing
from the present invention. Thus, the present invention is intended
to cover all such alternatives, modifications, and equivalents as
may be included within the spirit and broad scope of the invention
as defined only by the hereinafter appended claims.
* * * * *