CA2432750A1 - Bar coded bill payment system and method - Google Patents

Abstract

A system and method for payment is provided, wherein consumers (2204) pay their bills at supermarkets (2205), or retail 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 (2201) receives good payment funds, deposited directly into his bank account, and error-free electronic payment data for consumer bill payment 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 (2202). In other 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.

Description

2 BACKGROUND OF THE INVENTION

3 The present invention relates to a system and method for performing financial

4 transactions, and more particularly, to a payment system and method using bar code identification.
6 Traditional Bill Payment Paradigmm 7 The current paradigm of the bill payment cycle for goods and services 8 rendered has improved only in incremental steps since the beginning of time.
In 9 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.
11 Extension of credit for goods and services was generally limited to the affluent and 12 wealthy. When payment was due, handwritten invoices were hand delivered.
13 Sometime later, cash payment would be remitted in person. Most trade occurred at 14 the local level between individuals, exchanging cash or barter goods.
In the late 1800's and early 1900's in the United States, credit for goods and 16 services rendered remained essentially unchanged at the local level.
Society became 17 less stratified and there became an affluent middle class populace between the highest 18 and lowest levels of society. Credit for goods and services became extended to select 19 groups and individuals within this populace as well as the affluent and wealthy.
However, invoices were still handwritten tallies of goods and services rendered, 21 which were paid for in cash. The Industrial Revolution precipitated many technology 22 advances in transportation and communication, which affected many facets of daily 23 life. In commerce, the foundation cornerstones of the financial services industry, as it 24 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 26 individuals began to have a larger and more convenient span of financial control with 27 extended remote banking credit services. Merchants could then send their invoices to 28 distant customers through the national mail network and receive payments, some time 29 later, in the form of a bank draft honored by the local bank for cash.
In the generations following World War II to the present time, with general 31 society becoming more and more homogenized and, on the whole more affluent, 32 banking services are available and competitive at every level. Bank checking

5 PCT/USO1/48442 1 accounts (and therefore a credit mechanism with which to pay remote billets) are 2 available to 60 percent or more of the population. The national mail network is a very 3 cost-effective delivery system for local and remote customers of automated or 4 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

6 network. When received at the merchant directed return location (a bill payment-? processing center), these mail payments are opened, the checks deposited, and the 8 customer accounts credited with the face amount of these check payments.
9 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 11 societal needs. However, this is not the case. Some people never pay their bills on 12 time, for a variety of reasons. Payments made with a check are not always covered 13 with sufficient funds at their bank. The end-result consequence to the billet is a finite 14 cost that is directly attributable to the disruption of the flow of goods and services through his business.
16 To cover the costs incurred by these late payments, billets have only two 17 options available to them. One option is to spread this overhead cost over of all the 18 goods and services that they provide, with the possible consequence of pricing their 19 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 21 customers who pay late - for whatever reason. This second option is generally more 22 preferable since it targets the problem population segment directly.
However, billets 23 are often unable to recover the full cost of late payment consequences from those 24 customers and still stay within the public legal and regulatory mandates.
Recently, there have been business attempts to further automate the bill 26 payment process by the electronic delivery of billet invoices and the subsequent 27 electronic remittance of payments. While the electronic presentment of bill payments 28 might address the current 15% or so of the U.S. population with access to the Internet, 29 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 31 "dot com" entrepreneurs hope or project in their "new" economy business plans. The 1 latest statistics show that less than 3% of the American public may use on-line 2 remittance services.
3 Federal statistics indicate that fully 30-40% of the U.S. population may be 4 "unbanked". The "unbanked" population operates solely within the cash economy without any formal banking level traceability. There are many reasons that people 6 prefer to operate in this economy, some of which are culturally related.
Others prefer

7 , anonymity for quite specific reasons, such as illegal aliens avoiding detection and

8 deportation by the INS or others hiding their sources of income from the IRS. Federal

9 statistics also indicate that 30-40% of the adult U.S. population may have a working fourth grade education or less.
11 There may be a correlation between those people opting for the cash economy 12 and the fact that many may not be able to maintain and balance a checkbook.
Most 13 people would rather admit to being "unbanked" rather than to being illiterate. The 14 "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 16 proprietor-operated check cashing storefronts may service some of the needs of these 17 individuals. Weekly paychecks are cashed for a transaction charge (mostly based on 18 the face value of the check), and money orders are then bought, to be enclosed with 19 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 21 service disconnects.
22 For the great majority of printed bill payment invoices that are distributed 23 every month, each biller automates and optimizes its bill collection and remittance 24 process to suit the requirements of its installed paper handling equipment and flavor of customer account numbering assignments and schemes. Bill remittance stub sizes 26 and formats vary from postcards printed with dot matrix printers to full-page 8 %2" by 27 11" sheets with laser printed invoice information on pre-printed forms.
Each has a 28 tear-off bill remittance stub portion that is then mailed back with a check payment.
29 Account numbers on these bill remittance stubs appear in different (and sometime multiple) spatial positions, formats and fonts. While still not universal, most billers 31 have formatted their account numbers (and other customer related information) on bill 32 remittance stubs in Optical Character Recognition (OCR) readable scan lines. Some 1 of this information is printed twice on the bill remittance stub as a contingency that 2 the paper bill remittance stub is shredded or mangled by the automation equipment.
3 Human data entry of this customer account number information is the ultimate 4 fallback mode for processing this payment.
Traditional Bill Payment Examples 6 Figure 1 shows an exemplary local gas company remittance stub 100 utilizing 7 this manner of design. The biller in this example has assigned a numeric account 8 number to each of his customers. As shown in Figure 1, the customer account 9 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 11 form. Account number check digits 101 are used to validate the account number.
12 Each digit in the account number is multiplied by a mathematical weight, and then all 13 these products are added together. Dividing the total sum by 10 and complementing 14 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 16 digits are employed to eliminate two types of common errors, physical digit read 17 errors and transposition errors (when the customer account number is processed 18 manually).
19 Figure 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 21 are two forms of the customer account number 201 that appear on the bill remittance 22 stub. The first 201 is designed to be human readable because it appears within a 23 printed text box labeled "Account Number". The last digit in the Account Number 24 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
26 scan line (underlined for illustration). The leading "4" digit is the customer account 27 number check digit and the remainder of the underlined portion of the OCR
line are 28 the digits that can be mapped into the human readable "Account Number"
form. The 29 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 31 perspective, a customer service representative of the power company, during a service 32 call, would never ask a customer to recite his account number from a sequence of 1 digits appearing within the machine-readable OCR line and expect a correct answer.
2 The human readable form 201 of the customer account number is easier for a 3 customer to recognize and to dictate over the telephone when requesting service 4 changes to his account.
These two examples illustrate the primary uses of duplicate account 6 information printed on a bill remittance stub - one for simplicity when verbally 7 referring to a specific customer account and the second for the case that the 8 automation process fails and customer account number payment information has to be 9 entered manually.
Figure 3 shows an exemplary remittance stub 300 from a gas company, in 11 which the biller automates part of the bill payment remittance process by including, 12 on the bill remittance stub, company proprietary bar coded information 301 that does 13 not appear to be related in any way to the printed customer account number.
While 14 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 16 automation equipment, it does not significantly decrease, in favor of the customer, the 17 overall bill payment cycle. The great majority of the bill payment cycle time consists 18 of non-deterministic time delays in the national mail network during the biller-to-19 customer and the payment-to-biller delivery paths. These random time delays, combined with very short biller dictated due dates and (possibly intentional) delayed 21 processing times, always work to the detriment of the customer. As a result, some 22 customers are assessed penalty payments, which are sometimes more profitable than 23 the basic goods and services provided.
24 The system of bill payment invoicing, collection and remittance processing remains a fragmented industry because there are no common bill remittance stub 26 format standards, no common customer account number representation standards, no 27 common, expedient data and money delivery mechanisms to the biller, and no large 28 bill remittance stub processing networks, in addition to payment cycle delays that 29 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 31 from the current set of available technology components, a universal national bill 32 payment network could be implemented that addresses the above list of industry 1 problems, resulting in a positive economic impact to the business community at large.
2 For such a set of standards to work, the cooperation of several large organizations 3 would be required; however increases in raw profit and new business growth 4 opportunities should induce such cooperation.
As shown in Figure 4, a system 400 consistent with the existing bill payment 6 paradigm uses the national mail network and billet payment processing centers to 7 convert physical paper into electronic data and bank credits. The current bill payment 8 network is a paper based network that primarily relies on the central banking system 9 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, 11 for all the goods and services rendered to a customer over a given billing period, the 12 billet accounts receivable 401 accumulates a dollar total and generates a detailed 13 machine printed invoice (which may take 4-5 days after account cut-off time to 14 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 16 direct traceability from the perspective of either the billet or the customer).
17 Once the customer receives the invoice in the mail, the customer makes out a 18 check payment or procures a money order 404 to remit with a mail payment, which 19 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 billet 21 collection and processing center 406, where processing time may be 2-3 business days 22 or more (which time is variable, without any direct traceability from the perspective 23 of either the billet or the customer). At the bill payment processing center 406, the 24 following operations are typically performed: opening all received mail;
microfilming and/or otherwise recording all received payments; electronically reading and 26 processing OCR bill remittance stub information; preparing all received check or 27 money order payments for bank submission; and electronically remitting bill payment 28 data, based on check payment verification. Processing time within the processing 29 center 406 may be 2-3 days.
It should be noted that there may be sanctioned late payment penalties 31 imposed on credit card payments, wherein a billet might gain an advantage by 32 intentionally delaying an on-time payment by a day or so, thereby causing an 1 otherwise on-time payment to be considered late. For example, for a $200 payment 2 delayed by only one day, a $25 late payment penalty might result in an equivalent 3 Annual Percentage Rate (APR) interest rate of 150%, for little or no marginal cost to 4 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 6 amount, made late by that intentional delay.
7 Payment data is next remitted electronically from the processing center 406 to 8 the biller's bank 408, and processing and distribution of electronic payment data is 9 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 11 data is received from the ACH Network, stripped and reformatted according to biller 12 specified formats, which may take 4-6 hours. Finally, the biller's accounts receivable 13 401 and/or customer service computer files are updated. Depending on the "legacy 14 factor" of the biller's computer processing systems, this process can range anywhere from 2-3 hours to 4-5 days.
16 Assuming zero latency on the part of the customer paying his bill, the cycle 17 time between the customer account cut-off time and the time that the customer 18 payment is applied to his account, using the above time estimates, may range from 13-19 18 days. Since there is usually some customer delay, the observed bill payment cycle time will be longer.

22 Biller-Pa or Aspects of the Present Invention 23 The present invention involves the transmission of payment information via 24 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 26 existing scanners in cash register systems at supermarkets, chain stores, or other retail 27 ~ outlets. Retailers gain access to a valuable affinity draw because everyone has bills to 28 pay regularly. Billers save millions of dollars in collection and processing expenses.
29 Consumers are provided a convenient way to pay any bill quickly and flawlessly for a nominal transaction fee (e.g. $1.00 per bill).
31 A bill payment system and method consistent with the present invention relies 32 on an additional ISO standard printed bar code on the biller invoice, which is then _7_ 1 delivered to the customer via the national mail network. Thereafter, payment 2 information and payment credits are returned to the biller electronically.
With the 3 proliferation of the Universal Product Codes (UPC) that are imprinted on every retail 4 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 6 register the sale of all items for inventory and pricing purposes. Bar coded bill 7 payments would be just another commodity item to be paid for, accepted at retail.
8 Upon receiving a bar coded payment invoice, the customer could go to any 9 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 11 might receive a printed detailed proof of payment receipt. Billers could be notified 12 immediately and agree to suspend all collection activities, and account posting could 13 take place within 36 hours, all funds remaining within the Federal Reserve Banking 14 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 16 specifications and certification parameters necessary for billers to participate in a 17 system consistent with the present invention.
18 As a participating retail establishment provides bill payment services to the 19 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 21 portal, other services can be offered to consumers. For example, in addition to 22 payments, money transfers (a financial services which may be lucrative to provide) 23 may be provided through a system consistent with the invention. Bank account 24 transactions such as deposits may be made or Internet wallets replenished.
Though not required, the U.S. Postal Service CUSPS) could be offered a new income stream 26 for simply authorising this system. The power of an "electronic" postmark may 27 impact the way billers view this system.
28 It is contemplated that the retail industry should provide advertising as they 29 promote the affinity pull they already wish to impart upon the consumer marketspace.
The community of consumer billers should provide cooperation because of the 31 potential of this system to reduce what are now very expensive embedded collection 32 costs. Consumers need another way to pay their bills more efficiently than the U.S.
.g_ 1 Post Office mail can do so today, especially for those without bank accounts or those 2 who desire to use credit for bill payments, and clearly for those who are late. A .
3 system consistent with the present invention therefore benefits billers, consumers and 4 retailers who participate, and may be inexpensively and easily established and maintained.
6 Further Payment Aspects of the Present Invention 7 A system and method for payment is further provided, wherein consumers pay 8 their bills at supermarkets, large retail chain, or other stores and receive immediate 9 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 11 good payment funds, deposited directly into his bank account, and error-free 12 electronic payment data for consumer bill payments by the very next business day.
13 The biller backdates the received bill payments to the time and date the consumer 14 actually paid, regardless of the time that the payment data takes to post to the biller's accounts receivable system.
16 In another aspect, a method for person-to-person money transfers is provided, 17 wherein a bar coded deposit slip, card, or other printout permits a sender to remit 18 funds directly into a receiver's bank account, and such funds are quickly accessible 19 for withdrawal at a nearby automated teller machine, or for a debit card purchase.
In one aspect, a bill payment system consistent with the invention comprises a 21 payee and a scanning apparatus. The payee transmits or transfers to at least one payor 22 a unique bar code comprising data identifying at least the payee and the payor. The 23 scanning apparatus is configured to scan a printed representation of the bar code . The 24 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 26 payee in a predetermined amount and transmitting data or initiating a data transfer to 27 the payee regarding the payment.
28 In method form, a bill payment method consistent with the invention 29 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 31 party to scan a printed representation of the bar code and, based on the identifying 32 information of the bar code and a payment made by the payor, to transmit funds or 1 initiate a funds transfer to the payee in a predetermined amount and transmit data or 2 initiate a data transfer to the payee regarding the payment.
3 In another aspect, a method of transferring money consistent with the 4 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 6 destination payment network corresponding to the account; and transmitting funds or 7 initiating a funds transfer, based on information stored in the bar code and a payment 8 made by a payor, in a predetermined amount to the account.
9 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 11 account number and a destination payment network corresponding to the account 12 number.
13 In still another aspect, a printed bar code consistent with the invention 14 comprises data identifying at least an account number and a destination payment network corresponding to the account number.
16 In yet a further aspect, a method for performing an Internet financial 17 transaction consistent with the invention comprises transmitting or transferring to a 18 payor a unique bar code comprising data identifying at least a payee and a destination 19 payment network corresponding to the payee.
In still a further aspect, a method of providing for payment from a payor to a 21 payee comprises: making available to one or more payees a standard format for 22 representing on a printed document data including at least a payee and a destination 23 payment network corresponding to said payee; providing at one or more locations of 24 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 26 payment network identification, payee identification and payment amount;
and 27 providing information to said destination payment network to effect transmission of 28 funds to an account of said payee in an amount identified by said payment amount 29 and concurrently effecting or initiating transmission of payment information to said payee. .

32 Figure 1 is an exemplary prior art remittance stub from a utility company;

-10-1 Figure 2 is another exemplary prior art remittance stub from a utility company;
2 Figure 3 is another exemplary prior art remittance stub from a utility company;
3 Figure 4 is a process flow diagram of an exemplary prior art bill payment 4 system;
Figure 5 is a process flow diagram of an exemplary bill payment system 6 consistent with the present invention;
7 Figure 6 is an illustration of an exemplary data structure of elements 8 underlying the bar code "signature" in one embodiment of the present invention;
9 Figure 7 is an illustration of another exemplary data structure of elements underlying the bar code "signature" in one embodiment of the present invention;

11 Figure 8 is an illustration of an exemplary bar code bill payment "signature" in

12 one embodiment of the present invention;

13 Figure 9 is a table illustrating the results of an exemplary split modulus

14 matching calculation in one embodiment of the present invention;
Figures 10 and 11 are illustrations of an exemplary Level 3 envelope in one 16 embodiment of the present invention;
17 Figures 12 and 13 are process flow interaction diagrams of the mainline 18 transaction information interchange between the checkout scanner, retailer host 19 processor, and data collection network interface (DCNI) unit in processing a bar coded customer bill remittance stub, in one embodiment of the invention;
21 Figure 14 is a system view diagram of a transaction collection system in one 22 embodiment of the present invention;
23 Figure 15 is an exemplary transaction processor executive controller (TPEC) 24 display screen, in one embodiment of the invention;
Figure 16 is an exemplary system monitor station (SMS) display screen, in 26 one embodiment of the invention;
27 Figure 17 is an exemplary end of batch monitor (EBM) display screen, in one 28 embodiment of the invention;
29 Figure 18 is an exemplary electronic transmission interface (ETI) display screen, in one embodiment of the invention;
31 Figure 19 is an exemplary ETI transaction detail display screen, in one 32 embodiment of the invention;

1 Figure 20 is an exemplary ETI map biller-to-partner display screen, in one 2 embodiment of the invention;
3 Figure 21 is an exemplary transaction browser display, in one embodiment of 4 the invention;
Figure 22 is a process flow diagram of another exemplary bill payment system 6 consistent with the present invention;
7 Figure 23 is an illustration of an exemplary Level 3 envelope in one 8 embodiment of the present invention;
9 Figure 24 is an exemplary bar coded deposit slip in one embodiment of the present invention;
11 Figure 25 is an illustration of an exemplary gas station/convenience store debit 12 card known in the art; and 13 Figure 26 is an illustration of an exemplary gas station/convenience store debit 14 card in one embodiment of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
16 Biller-Payor Embodiments 17 Turning now to Figure 5, a bar coded bill payment based system 500 18 consistent with the present invention utilizes a bar code on the biller invoice, which is 19 then delivered to the customer via mail, and payment information and payment credits are returned to the biller electronically. Advantageously, nationally recognized and 21 federally sanctioned payment electronic networks may be utilized for remitting 22 customer payment data and funds. For all the goods and services rendered to a 23 customer over a given billing period, the biller's accounts receivable 501 accumulates 24 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 26 and mailing may be 4-5 days after account cut-off time, and the mail transit time to 27 the customer may add an additional 2-3 business days or more before the customer 28 receives the invoice (which time is variable, without any direct traceability from the 29 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 31 on other factors, the customer 503 decides to pay bill. The time for this to occur is 32 variable, depending upon the customer's circumstances.

1 To pay the bill, the customer 503 takes the bar-coded invoice to a participating 2 store (e.g. a supermarket) that processes bill payments. The customer presents his 3 bar-coded bill remittance stub to the checkout cashier for scanning at the checkout 4 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 6 payment bar code that identifies the biller to be paid and the account number to be 7 credited. The customer informs the checkout cashier the amount to be paid on that 8 account, payment is tendered to the cashier, and the cashier inputs the amount to be 9 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 11 complete. The check out of any remaining products and items (or bills) continues 12 until the complete total for all goods and services is calculated. The customer may 13 receive a printed receipt of the payment tendered with date and time that the payment 14 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 16 the payment steps may be as little as a few seconds. Moreover, payments made in this 17 manner are time-stamped, so that once payment is made, the customer may rest 18 assured that payment has been timely acknowledged.
19 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 21 and transaction volume thresholds), or at other predetermined intervals, the interface 22 506 transmits the payment data to the central site transaction collection system 507.
23 Additional transmissions may be scheduled before the daily transaction collection 24 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-26 stamped. Separately calculated calendar day payment counts and totals may also be 27 sent to the transaction collection system 507 as an independent transaction audit 28 balancing mechanism. The transaction collection system 507 may continuously 29 receive payment data information from a distributed network comprising a plurality of data collection network interface units 506 deployed at field retail establishments.
31 Before the last processing window closes at the Federal Reserve Automated Clearing 32 House (ACH) Network 508, all customer payments are sorted and aggregated for 1 direct remission to their respective billers, which may take approximately an hour.
2 Processing and distribution of electronic payment data is done using the Federal 3 Reserve Automated Clearing House (ACH) Network 508, which may take 6-9 hours.
4 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 6 take 4-6 hours. Finally, the biller's accounts receivable 501 andlor customer service 7 computer files are updated. Depending on the "legacy factor" of the biller's computer 8 processing systems, this process can range anywhere from 2-3 hours to 4-5 days.
9 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 11 payment is applied to his account, using the above time estimates, may range from 9-12 12 days (in contrast to the 13-18 days of the prior art system). Since there is usually 13 some customer delay, the observed bill payment cycle time will be longer.
14 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 16 226.10, then the total bill payment cycle time would be reduced to 6-8 days. Explicit 17 agreement from the biller would be secured through the biller registration process.
18 The biller may validate the customer payment date with the transaction embedded 19 "electronic postmark", which can not be performed within the current frameworks of either the paper based bill payment or the electronic payment paradigms, today.
21 In addition to the more than 55% time reduction in the bill payment cycle, 22 other advantages of the present invention include: customer choice of local bill 23 payment locations, electronic application of bill payments to account within 24-36 24 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.
26 Electronically delivered bill payments, under the present invention, are much cheaper 27 for the customer to pay for and less expensive for the biller to process through its 28 remittance processing center and accounts receivable systems than under a prior art 29 system. Additionally, banks that process data from the ACH system will have more chargeable services to offer their biller customers. Furthermore, billers can 31 incorporate this bar coding standard into their bill remittance processing centers, as 32 older OCR recognition equipment is replaced with simpler and more reliable laser bar 1 code scanning equipment. With sufficient planning, a biller, contemplating a 2 conversion of one or more legacy customer account numbering systems to a simpler, 3 newer scheme, can use this system of bar coding in its conversion process.
In an 4 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 6 the time and labor required for the biller to prepare and mail invoices to the customer.
7 It is further contemplated that billers would register with a centralized 8 organization in order to receive an assigned biller bar code, just as all companies must 9 register with the Uniform Code Council (UCC) to get their Universal Product Code (UPC) assignment for their products.
11 It should be understood that the foregoing described embodiment which uses 12 the in-store scanner and retail host back-end machine as a means of detecting, reading 13 and processing the bill payment bar codes is but one embodiment, and these 14 components are not described herein as limitations. For example, another method might utilize a personal computer, terminal, or other equipment having a bar code 16 capable scanner, receipt printer and an interface to the data collection network 17 interface in place of the in-store system. Ideally, such a computer would have the 18 same functionally equivalent interface as the in-store system. In fact, it is 19 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 21 network interface, a simple PC might operate in its place and serve as a model 22 prototype to demonstrate the operational aspects of this system.
23 Bar Coding Validation 24 Prior art systems have concentrated on the visual aspects of bill remittance stub recognition, detection and validation against potential fraud, typically using 26 optical character recognition (OCR). The present invention applies a bar code 27 solution to the general bill payments problem, rather than a new variant or improved 28 OCR technique. Bar code is more efficient than OCR by several magnitudes because 29 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
31 processing requirements for character recognition (and then only for a selected set of 32 fonts). Bar code consists of binary elements that are parity checked for every bar

-15-1 code symbol and globally checked digited at the message level. OCR consists of 2 many analog segments that have to be neurally correlated and matched to the human 3 readable character set with no internal self checking controls. In short, bar code is the 4 future digital solution whereas OCR is a dated analog solution that still plagues most bill payment processes today.
6 The Universal Product Code (UPC), printed on most retail products today, is a 7 12-digit number that is a concatenation of four numeric fields - a classification 8 number (1), a producer identification number (5), a product identification number (5), 9 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 11 a unique identifier to speed checkout transactions, therein creating an organization 12 that today is called the Uniform Code Council (UCC). The underlying bar code 13 symbology is merely a convenient representation of this UPC code format that can be 14 reliably detected by simple point-of sale scanning equipment (thus, it does not matter which particular bar code is used).

16 There is no standard way of representing multiple data fields in a single scan

17 line, given the designs and formats of various bar code standards and conventions

18 commonly in use today. For a typical bill payment application, two fields are

19 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 21 concatenated in a fixed format in a single bar code scan line on a bill head, it is very 22 doubtful that low skilled retail help would reliably scan the correct bar code where 23 multiple bar codes might appear on a given bill head. To perform error-free data 24 validation on this scan line, more information must be embedded within the data itself.
26 In the retail environment where bar coded products abound, there is a distinct 27 need to determine that a bar code, submitted for processing, is correct and valid for 28 the target bill payment processing application. One cannot assume that the retailer 29 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 31 bill payment bar code, in addition to an already existing internal routing bar code, the 32 two bar codes must be disambiguated. While the utility company can easily 1 distinguish its own internal routing code by its printed position on the bill remittance 2 stub, a retail cashier might not know which to present. The solution is for the cashier 3 to use trial and error. If the first bar code attempted does not validate, the second (or 4 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 6 invention.
7 By using a unique bar code "signature" having multiple levels of data 8 validation implemented by check digit algorithms, a bar code scanning system may 9 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 11 invention. In the embodiment described herein, three "envelopes" are used (although 12 those skilled in the art will recognize that any number of "envelopes" or levels of 13 validation may be used), the first being inside the second, and the second inside the 14 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 16 hardware scanner, the resulting alphanumeric information is valid in that it compared 17 correctly with the embedded encoded bar code check symbol. If this first operation is 18 successful, the "envelope" is opened. The directions printed on the inner "envelope"
19 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.
21 If this second operation is successful, the next "envelope" is opened. The printed 22 directions on the innermost "envelope" specify to use the format designator digits) to 23 decode and to verify the data integrity of the embedded component data elements.
24 Each of these data elements should be verified by calculating their check digits and by utilizing other independently available data validation checks.
26 If all three levels of validation successfully pass muster, then a valid bill 27 payment "signature" has been detected and the resulting data should then be passed to 28 the target bill payment application for subsequent processing. Failure at any 29 intermediate validation level results in a negative acknowledgement. The prime purpose of this bar code "signature" design is to unconditionally identify the detected 31 scanned bar code as being proprietary to the present invention, in the absence of any 1 other external information, through multiple layers of check digit information, format 2 designator indicators and local data validation schemes.
3 ~ A number of different application "signature" formats may be implemented 4 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 6 designator ("fd") consisting of one or more digits, a data field ("data") consisting of 7 one or more fixed or variable length sub-data fields, and a check digit ("cd") 8 algorithm associated with the format designator arid the level at which it appears.
9 Figure 6 illustrates a bar code "signature" 600 in one embodiment of the invention, utilizing four levels of successive embedded "signature" data fields. The 11 Level 1 data validation 601 is simply the hardware decode of the bar code symbology, 12 using the embedded check symbol character as data validation - i.e., all the bar code 13 symbols were detected and processed correctly. Applicability of the data to the 14 intended target application is demonstrated when all the remaining levels of validation are successful. As shown in Figure 6, Level 2 data validation 602 consists of one 16 signature data field (although it could have had more). The data validation of the 17 Level 2 signature data field consists of two checks - that the format designator value 18 (for that level) is correct and that the check digit calculation for the data string 19 consisting of the format designator digits) and the data field digits matches the check digit character. The Level 2 format designator defines at least three characteristics:
21 the check digit algorithm implementations (in this example, 1 ), the number of data 22 elements (in this example, 1), and the number of trailing discard characters for bar 23 code odd / even count padding (in this example, 2). The number of unique 24 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 26 digit algorithm to disambiguate target applications, there is only one data field 27 element, and there are two padding character combinations for the Code 128 bar code.
28 Thus, the total number of format designator values required at this level is two.
29 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 31 format designator defines at least these three characteristics: the check digit algorithm 32 implementations (in this example, 1), the number of data elements (in this example, 1 one fixed, one variable or fixed), and the field lengths for one or more data elements.
2 As shown in Figure 6, there are two data element fields. The number of data splits 3 defined for this data field would determine the number of format designator values 4 that are required for this level.
The fourth 604 to nth 605 levels comprise a continuing iterative process of 6 Level 3. Depending on the attributes or properties that one arbitrarily assigns to the 7 data (and hierarchical functions) at each level determines the number of format 8 designator values required at that level. The target application receives all the data 9 fields from the final level of data validation.
A carefully chosen set of conventions for the format designators at each level 11 will facilitate correct data field parsing with the additional security that multiple levels 12 of check digit validation will ensure data integrity and "positive ownership" to the 13 target application. The format designator digits) do not necessarily have to be 14 leading as illustrated above. An alternative format for the leading format designators could be as is illustrated in the bar code signature 700 of Figure 7, in which the data 16 strings precede the format designator digits.
17 With reference to the exemplary embodiment shown in Figure 6, a sample 18 format of the unique bar code bill payment "signature" 800 is shown in Figure 8, as a 19 multiple layered data validation scheme. A bar code typically consists of 6 sections:
(1) a quiet zone (~ 0.25" of white space) before the bar code; (2) a unique bar code 21 symbol that represents the "START" character; (3) bar code symbols representing 22 data characters (1300017350764058410363); (4) bar code check symbol that 23 represents a calculated check digit of the preceding data character block;
(5) a unique 24 bar code symbol the represents the "STOP" character; and (6) a quiet zone (~ 0.25" of white space) after the bar code. If the hardware decode of this Level 1 envelope data 26 string is not successful, the retail cashier should not get a good bar code scan 27 confirmation. If the hardware decode is successful, the retailer cashier should get a 28 goad bar code confirmation (but not necessarily of a valid product code). A
good 29 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 31 algorithm, matches the embedded string check symbol character. This is the first 32 level of data validation check that must pass.

1 When the bar coded data characters are decoded from this scheme of variable 2 width white and dark bar patterns, the result is the following string of (alpha)numeric 3 characters: 130001735076405841036 3. Calculating a split modulus 10 check digit 4 for the string to match against the last character, using a 1313...
mathematical weighting scheme, results in the table of calculations illustrated in Figure 9. The 6 Level 2 format designator value (1) is chosen to indicate the check digit algorithm 7 (Split Modulus 10 with mathematical weights of 1313...), the number of data field 8 elements (1), and number of trailing padding characters (0) to utilize the high density 9 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 11 1313...), the number of data field elements (1), and number of trailing padding 12 characters (1) to utilize the high density Code 128 Type C symbol set. The modulus 13 (or the remainder) of the resulting sum of the digits (87 divided by 10) yields 7. The 14 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 16 illustrative example. This is the second level of data validation check that must pass.
17 If this validation is successful, the operation proceeds to the Level 3 envelope data 18 decode and validation algorithms.
19 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-21 qualifying software validation data check. The Level 3 check is an "ownership" data 22 check (i.e. whether this is the "signature" for bill payment data under the present 23 invention). Different "signatures" can be constructed for any number of application 24 program uses through a judicious design scheme and the selection of format designators. Format designators are arbitrary indicators with which to properly 26 decode the format of and to validate the ensuing data string - in this case, the format 27 designator is placed as the first (one or more) leading digit(s). At different levels, the 28 same format designator values can have different meanings.
29 Turning.now to Figures 10 and 11, two format designator values have been chosen in this example (at Level 3) to encapsulate six format and validation data 31 characteristics - all of which must be correct for the third and final data validation 32 check to pass. The Biller ID in each of these examples is "173" in a 6-digit numbering

-20-1 system. The embedded spaces in the encoded data examples 1000 and 1100 of 2 Figures 10 and 11 are not significant and are inserted to show more clearly the various 3 fields within the example digit strings. The six format designator characteristics 4 shown in Figures 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 6 characteristic facilitates data checking. To validate a unique bar code application 7 program "signature", the more dependencies that exist within the data at each level for 8 subsequent cross checking and validation, the better. In the illustrations of Figures 10 9 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 11 different Level 2 check digit algorithms employed, a Level 3 dependency is checked.
12 Condition #1 is checked against valid range of format designator values for the 13 current Level (in this case 3, 4). Biller Identification Number (in this example, 173) is 14 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 16 number check digit algorithms are not known, a check digit is calculated and added to 17 the account number - to be checked then stripped when presented to the biller 18 (Format Designator Value = 4). Where the biller account number check digit 19 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

21 the above examples, the decoded and check digited values of the Biller Identification

22 Number and the presented Biller Customer Account Number results are as follows:

23 For Format Designator Value = 3, Biller ID = 173, Customer Account

24 07640584103; and for Format Designator Value = 4, Biller ID = 173, Customer Account = 0764058410. This is the third level of data validation check that must 26 _ pass. If all the components in the Level 3 envelope test and compare successfully, 27 then the unique bar code bill payment "signature" has been correctly validated for 28 further processing, and an indication is given to the retailer or cashier that a dollar 29 amount payment should be entered for this item.
The primary purpose of this bar code "signature" design is to unconditionally 31 identify the detected scanned bar code as being proprietary to a system or method 32 according to the present invention, in the absence of any other external information, 1 and to validate (using mathematical formulae and/or independent table look-up 2 methods, if possible) all the data element components therein.
3 The methods and procedures by which the format designator concept could be 4 extended are strictly an implementation issue of design schemes and an adopted set of orthogonal convention(s). While the foregoing illustrative working example uses 6 only three levels of "envelopes" to validate the unique bar code bill payment 7 "signature", more levels could have been used, as required. The format designators in 8 .the foregoing example utilized a fixed data format with a set of predefined check digit 9 algorithms for each level. Possible design extensions in further embodiments might include: (1) a format designator design scheme that defines a dynamic variable 11 number of sub-field elements and/or a set of dynamic component string lengths for 12 each of the defined set of the sub-field elements (in contrast to the foregoing 13 illustrated predefined fixed schemes); (2) a format designator design scheme having 14 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 16 (e.g. a two digit format designator would specify a primary set of attributes in the tens 17 digit that is qualified by a secondary set of attributes in the units digit); and (3) format 18 designator design schemes wherein subsequent trees of sub-field elements are 19 controlled by one or more preceding levels of format designators.
Bar Coding Specifications 21 The bill payment application bar code printed on each bill remittance stub 22 might minimally consist of four basic fields, printed as a single string of digits: a 23 format designator (1 digit); a biller identification number with optional embedded 24 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 26 skilled in the art will recognize that the number of gelds and/or digits per field as 27 described herein is specified by way of example, and not limitation, and that the 28 number and length of fields may vary according to each embodiment of the invention.
29 In this example, the outermost bar code envelope for this information conforms to documented ISO bar coding convention standards, utilizing an embedded check digit 31 algorithm to verify the integrity of the entire bar code scan line data. It is strongly 32 recommended that the biller defined customer account number also contain an _22_ 1 embedded check digit, as a prudent secondary validation measure. If an embedded 2 check digit does not already exist within the biller customer account numbering 3 scheme (or the biller does not wish to disclose that information as being company 4 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 6 code scan line data correctly passes the triple tiered and multiple embedded check 7 digit calculations, this mechanism will virtually guarantee "defect free"
biller and 8 customer account data. Otherwise, a bill payment stub whose bar code has been 9 mutilated or defaced by the customer is immediately rejected at the point-of sale entry.
11 To accommodate future requirements, an expanded set of format designators 12 could define new data format structures or redefine the characteristics of current data 13 fields. The following is a possible list of characteristics that a format designator 14 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 16 applied to each of the sub-field elements; oddleven string packing factors when a 17 single bar code character represents one or more digits (Code 128 is a good example 18 of this compression feature); or subsequent trees of dependent sub-field elements.
19 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 21 network interface unit for secondary validation and translation. The parsed 22 "translated" form of this data is then passed back to the back-end host processor 23 system for completing the bill payment transaction at the checkout counter.
24 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 26 white space to satisfy the criteria of the ISO bar code format. If there are other 27 proprietary bar codes present on the bill remittance stub, the checkout counter cashier 28 could have the option of folding or bending the bill remittance stub such that only the 29 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 31 identification number and the customer account number on most bill remittance stubs 32 is good for a combined number sequence of 14-25 digits at the lowest common 1 denominator bar code print resolution (nominal bar code "X" dimension >
0.010 2 inches and total bar code string length < 3.0 inches). For sequences longer than that, 3 it is recommended that the bar code sequence be printed in a manner parallel to the 4 horizontal OCR line such that extraneous proprietary bar code information can be folded out of the way for a successful scan.
6 The assigned biller identification number is acquired or distributed from a 7 central registry authority, akin to the manner in which the Uniform Code Council 8 assigns new producer identification numbers. As far as the customer account number 9 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 11 would be read in error if the hardware bar code check symbol scan validates, this 12 additional check digit provides double assurance to the biller that the customer 13 account number is correct. This is especially important from the biller's point of view 14 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 16 available - known empirically to have very high human input error rates.
17 To this point, it has been tacitly assumed that the biller will want to print this 18 new bar code on the face of his bill remittance stub. However, technical, as well as 19 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 21 format to be printed on the back of the current bill remittance stub (so as not to disturb 22 the current mode of visual remittance processing) or printed on a second or 23 subsequent tear-off bill page, formatted for that specific purpose. A
further 24 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 26 customer. Spare space on that enclosure could even be sold for advertising to defray 27 the printing costs by the biller.
28 The most common point-of sale bar code used throughout the retail industry is 29 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 31 symbologies. The bar code symbology, under current consideration for the most 32 general specification of an alphanumeric customer account number, is the Code 128 1 family. Where there are only numerics, the Code 128 Type C variant features a high-2 density bar code - one printed symbol per two digits of information. During the 3 checkout aisle scanner process, the back-end host processor recognizes a bar code 4 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 6 the bill payment amount. On the printed customer receipt, the bill payment is 7 recorded in a form similar to the following, including biller name and account 8 number, amount paid, transaction ID, date and time, and transaction fee charged:
9 PMNT: Biller Name ACCT: Customer Account Number 11 AMNT: $ ddd.cc 12 TRID: rrrrrrr yjjj ssss 13 DATE: mm/dd/yy hh:mm 14 FEE: $ dd.cc 16 This time-stamped transaction data is then stored in the data communication 17 network interface unit for later transmission to the transaction collection system.
18 Where the checkout scanner detects multiple bar codes, the retailer cashier can 19 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 21 code, present on the bill remittance stub, that does not pass all of the bill payment 22 "signature" tests results in an immediate validation reject by the data communication 23 network interface unit.
24 Back-end Host Processor The retailer back room host processor may be required to support two well-26 defined interfaces, the front-end checkout counter scanner system and the back-end 27 data collection network interface. When the Code 128 bar code format is encountered 28 from bill remittance stubs, it should be recognized as a customer bill payment, rather 29 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 31 implement within the back-end host processor is as follows: if this bar code scan is 32 not recognized as one of several defined pre-programmed sequences, pass it to the

- 25 -1 data collection network interface before rejecting the scanned data completely. The 2 back-end host processor passes the complete scan line data to the data collection 3 network interface unit for secondary level validation and data translation.
If 4 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 6 transaction. In this case, the returned translated data consists of the Biller Name, the 7 Customer Account Number, and Transaction ID that is printed on the customer 8 printed receipt.
9 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 11 network interface unit to be stored in non-volatile memory for later transmission to 12 the central transaction collection system. There are a number of standard data 13 collection network interface functions that may be accessed by the back-end host 14 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 16 reading operational configuration parameters.
17 Data Collection Network Interface (DCNI) Unit 18 The retailer on-site data collection network interface unit should provide a 19 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 21 memory storage capability of accumulated customer bill payment data. This may be 22 accomplished with a solid state hardware design that is electrically isolated at all the 23 critical interfaces and has no moving elements that mechanically wear and eventually 24 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

26 include functionality such as: (1) performing secure validation procedures with the

27 transaction collection system; (2) downloading DCNI unit operating system and

28 program application code firmware; (3) downloading DCNI unit operational

29 configuration parameters; (4) uploading DCNI unit memory image (emergency and debug use); (5) downloading Verification Biller ID and Name data; (6) uploading 31 transaction data (compressed & encrypted); and (7) setting DCNI unit system date or 32 time. The primary function of the data collection network interface unit is to provide 1 a set of support functions to the retailer host processor to aid in the collection, 2 validation and storage of transaction data from customer bill remittance stubs scanned 3 at the checkout counter.
4 Figures 12 and 13 illustrate the mainline transaction information interchange between the checkout scanner, retailer host processor, and DCNI unit in processing a 6 bar coded customer bill remittance stub, in one embodiment of the invention.
As 7 shown in Figure 12, the interaction occurring in the case of a valid account number 8 begins with the bar code being read 1201 by the checkout scanner and passed to the 9 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 11 acknowledgment of validity (ACK) is returned 1203 via the host processor to the 12 checkout scanner, along with the biller name and account number. The amount to be 13 paid is queried 1204 at the checkout scanner, and the amount entered is passed 1205 14 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 16 successful, an acknowledgment is sent 1208 via the host processor to the checkout 17 scanner, along with a transaction ID number. The checkout scanner may then print 18 1209 the biller name, account number, and transaction ID as a transaction receipt. As 19 shown in Figure 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 21 processor next validates the bar code 1302 and passes the resulting data to the DCNI.
22 Since some aspect of the data passed to the DCNI is invalid, an acknowledgment of 23 invalidity (NAK) is returned 1303 to the host processor with a reason code.
The 24 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 26 codes might include, e.g., invalid scan line (not a valid bill payment "signature" scan 27 line), Biller ID check digit error, invalid Biller ID (old biller that is not serviced 28 anymore), or Biller Customer Account Number check digit error. Payment is 29 consequently rejected at the checkout scanner 1304.
In one embodiment, the Transaction ID that is returned to the retailer back-end 31 host processor, as a positive confirmation that the transaction data has been accepted 32 and successfully stored, is a 15 digit number consisting o~ DCNI unit identification (7 _27_ 1 digits), last digit of year (1 digit), Julian date (3 digits), and transaction sequence 2 number (4 digits). This information may be printed on the customer receipt as three 3 groups of digits (7,4,4) as an ease-of use issue, should it be necessary for the 4 consumer to dictate his Transaction ID to a customer service representative over the telephone.
6 Periodically throughout the day (primarily based on time and transaction 7 volume thresholds), the DCNI unit should transmit its stored data to the transaction 8 collection system after it has aged past the "transaction void" window. The 9 "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 11 embodiment, the data elements of each transaction transmitted to the host consist of 12 the following: Retailer ID, Biller ID, Biller Account Number, Amount Paid, Sequence 13 Number, Transaction Date/Time Stamp, Status as Active or Void, and Operator ID.
14 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:
16 DCNI unit identification (7 digits), last digit of year (1 digit), Julian date (3 digits), 17 and last transaction sequence number in batch (4 digits). Such a numbering 18 convention makes it easier for customer service operations personnel to trace a given 19 Transaction ID.
The design and implementation of the data communication network interface 21 functions could optionally be performed as a real time on-line system or as a batch 22 oriented system to the transaction collection system. If implemented as a real-time 23 system, communication costs to the central site and a redundant "hot cutover" central 24 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 26 "hot backup" system eliminates the real-time aspect of transaction processing that 27 exponentially escalates costs. Central site redundant hardware still has to be 28 available, but much less of it is required to achieve the same level of system operation 29 reliability.
In systems that are explicitly designed for real-time operation (e.g. credit card 31 verification), "hot cutover" systems contain elements that have to be designed, a 32 priori, into the combination of system and application software to anticipate and to 1 detect the many types of potential system, application or equipment failures. When 2 detected, transaction processing is immediately and automatically transferred to an 3 operational system "in waiting". In the ensuing recovery mode precipitated by this 4 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 6 point) or are pulled back. If a transaction is pulled back, all database record 7 modifications are restored and then the transaction is reprocessed from ground zero.
8 "Hot backup" designed systems have fewer constraints. Spare equipment is 9 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 11 transaction batches, not explicitly acknowledged as processed, at a later time (ranging 12 from minutes to hours). Subsequently, if duplicate transactions are encountered on 13 resubmission, they are not processed but are acknowledged as such to the DCNI unit.
14 Much less premeditated contingency system software is required in this environment for robust system operation.
16 Transaction Collection S, s 17 While the data collection network interface may be a single unit, the central 18 site transaction collection system may consist of multiple central processor server 19 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 21 point failures that might curtail or impact the production processing of incoming 22 transaction batches.
23 Figure 14 illustrates one possible configuration for the transaction collection 24 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 26 modem bank 1401 over a T1 or similar connection 1402 into an entry router 27 outside the central site firewall, via a channel service unit/data service unit 1404 28 (CSU/DSU) or other similar device for providing isolation between the network and 29 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.
31 In addition to their primary security role, one of the ancillary functions of the 32 firewalls 1405 is to load balance the data traffic across all available file transfer 1 protocol (FTP) engines 1407. A plurality of FTP engines 1407 are shown in the 2 diagram as being in a scaleable multi-server configuration, coupled via one or more 3 integration hubs (e.g. 100 MB or 1 GB Ethernet hubs) 1425. The FTP engines 4 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 6 1408, which may comprise RAID (redundant array of inexpensive disk) storage or 7 similar mass storage.
8 In the FTP storage machine 1408, a monitor process scans for completed 9 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 11 message packet that is sent to one of a plurality of transaction processor (TP) engines 12 1409 in a scaleable mufti-server configuration, coupled via one or more integration 13 hubs 1425. It is noted that the transaction processor engines 1409 and FTP
engines 14 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, 16 1409. A transaction processor engine 1409 (TPE), upon receiving this message 17 packet, then has sufficient information available to locate, to decompress and to 18 decrypt the inbound data file into its component data record types. The various 19 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 21 1410 database is configured across several partitioned sets of physical hardware 1411 22 set up for RAID storage operation. The primary purpose for spreading the databases 23 over several pieces of physical and logical hardware and/or software is to avoid 24 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 26 retail processing locations. On a scheduled production basis, the data is aggregated 27 and sorted, according to the biller identification associated with each transaction 28 customer account number. ACH transaction files are prepared and formatted by biller 29 identification, which then maps into biller-designated destination ABA bank routing and bank account numbers.
31 The administrative/data reporting server 1420 provides access to a copy of the 32 production data for back office operations and monitoring by one or more work

-30-1 stations 1427, without burdening the front end collection system. In the embodiment 2 shown, the "glue" that holds the whole network together is one or more 100 MB or 1 3 GB Ethernet hubs 1425. This technology provides the foundation cornerstone by 4 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 6 reports to retailers through a web server application. It also provides periodic reports 7 to retailers that can be faxed out through the normal public telephone network 1445.
8 The electronic transmission interface (ETI) machine 1440 prepares the data that has 9 been accumulated and processed by the transaction collection server 1410 for transmission to the Federal Reserve ACH Network. It formats the data into the 11 correct ACH CIE (customer initiated entry) format and transmits this data file to the 12 appropriate destination bank interface. An optical drive 1432, tape storage unit 1433, 13 or other such storage means may be provided for creating removable backups, which 14 may be stored off site.
In the CIE Entry Detail Record format, the following exemplary fields are 16 populated with bill payment information: AMOUNT (Field 6) is populated with the 17 Customer Payment; INDIVIDUAL NAME (Field 7) is populated with the Transaction 18 Sequence Number (which contains the Julian date of payment); INDIVIDUAL
19 IDENTIFICATION NUMBER (Field 8) is populated with the Biller Customer Account Number; and DISCRETIONARY DATA (Field 9) is populated with the 21 Payment Complete Time encoded as a two digit time field ranging from 00 to 95.
22 This number may be divided by 4 to calculate military hours (decimal) to the nearest 23 quarter hour. For example, the number 26 divided by 4 would yield 6.5 (0630 or 6:30 24 AM). The remaining fields in the CIE Record format are populated with mandatory banking information data, such as biller ABA and account number.
26 A print control station 1470 is coupled to one or more print engines 1471 for 27 handling printer transmissions to one or more laser printers 1472 for a variety of 28 report and other printing functions.
29 Figure 15 illustrates an exemplary transaction processor executive controller (TPEC) display screen 1500, in one embodiment of the invention. The TPEC
monitor

31 program resides in the FTP storage server 1408 and is responsible for detecting

32 complete inbound data files from the field retailer based data communication network 1 interface units. When an inbound data file is detected, TPEC fetches the file 2 decryption key from a master database and then dispatches it and the data file name to 3 one of the transaction processor engine (TPE) 1409 program threads. The TPE

4 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 6 1410 on RAID storage 1411. As shown, display screen 1500 may include features 7 such as jobs attempted 1501 (i.e. batches received) and transactions processed 1502 8 (i.e. individual data records processed from the batches received). This display 1500 9 shows the current Transaction Process Engines) 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 11 currently dispatching any detected inbound data files to the TPE
engines.1409. For 12 this batch, 129 inbound data files were processed that resulted in 244 data records, 13 stored in the SQL database.
14 Figure 16 illustrates an exemplary system monitor station (SMS) display screen 1600, in one embodiment of the invention. This display 1600 shows that 16 individual retailers may be configured in a directory tree-like structure, with each of a 17 plurality of distributors 1601 being a parent to one or more retailer bill pay sites 1602.
18 The directory framework of retailers 1602 may conform to any convenient form of 19 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 21 towns). Also illustrated in this display is the placement of INSTRUCTION
files 1603 22 that can reside at any level within an arbitrary configuration structure.
An 23 INSTRUCTION file 1603 contains operational directives to be applied to retailer 24 terminals at or below the level of placement in the directory structure (i.e. transaction pricing, unit transmission schedule, revised configuration parameters).
26 Figure 17 illustrates an exemplary end of batch monitor (EBM) display screen 27 1700, in one embodiment of the invention. When the current system batch is closed 28 out, this display 1700 shows the status of the various data processing phases (e.g.
29 system batch 1701) that take place when the collection of received transaction data batches from the retail data communication network interface units are consolidated 31 and sorted by biller for electronic transmission. EBM may be a Visual Basic program 32 that orchestrates the series of Structured Query Language (SQL) scripts and ancillary 1 programs to perform transaction consolidation, general system batch reporting, 2 database trimming and data archiving.
3 Figure 18 illustrates an exemplary electronic transmission interface (ETI) 4 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 6 remittance partners. The batch status window 1802 shows the current status of the 7 transmission batches (QUEUED, ACTIVE, DELETED, or COMPLETED). An 8 additional column (not shown) may be included to show the confirmed time of 9 transmission completion.
Figure 19 illustrates an exemplary ETI transaction detail display screen 1900, 11 in one embodiment of the invention. For a specific partner (in the example shown, 12 MasterCard RPS),.this display shows the details for each remitted transaction - biller 13 name 1901, originating source transaction detail for direct traceability 1902, customer 14 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 16 account numbers.
17 Figure 20 illustrates an exemplary ETI map biller-to-partner display screen 18 2000, in one embodiment of the invention. For each biller defined in the system, 19 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
21 network, the remainder of the remittances may be delivered by a combination of 22 directly connected links and secondary consolidator links. Display screen 23 shows, for each biller, a Biller ID 2001 and Biller Name 2002 mapped to a particular 24 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 26 the electronic link utilized) that has to take place for this system to interoperate 27 successfully with a variety of external electronic networks. Different electronic links 28 may also have different data formats, as those skilled in the art will appreciate.
29 Figure 21 illustrates an exemplary transaction browser display screen 2100, in one embodiment of the invention. For every transaction processed through the 31 collection system, the transaction browser program accesses and displays all the 32 relevant information pertaining to that transaction, either locally or through a secure

- 33 -1 Web Server Application access to remote billers. Such information may include, e.g., 2 a selection entry portion 2101, check and trail record 2102, and payment record 2103.
3 (It should be noted that the bill image would typically not be transmitted to the 4 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 6 standard format of biller imprinted bar codes, as described herein.
7 In summary, the primary function of the central site transaction collection 8 system 1400 is to collect transaction data from the retail network, sort and aggregate 9 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 11 collected, processed and credited to individual billers, the ACH Network is used to 12 electronically debit the retailers for the payments that they have collected from their 13 customers. The transaction fee, paid by the customer, may be shared by the retailer 14 and the transaction processor.
Central Biller Re_~i, str,~ystem 16 The current state of the bill payment industry is very fragmented, and many 17 billers currently print their own customer invoices to suit the needs of their own 18 remittance processing systems. There is no universal invoice printing standard to 19 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:
21 (1) an industry standard that is relatively simple to implement with little or no 22 marginal cost; and (2) a sufficiently large network of retail establishments, induced by 23 the economic incentives of taking bill payments with little or no marginal cost; and 24 (3) a method of delivering totally error-free, electronically remitted customer payment data and funds to billers at no charge.
26 From a business point of view, there are several organizations that, once 27 persuaded, might provide the required motivation momentum in each of these areas.
28 With this assumption in hand, a central registry system would be required to collect 29 information and to assign the bar code biller identification numbers, in the same manner that Network Solutions assigns domestic Internet addresses for the World 31 Wide Web or the Uniform Code Council assigns UPC codes for the retail industry.

-34-

35 PCT/USO1/48442 1 In one embodiment, assigned biller bar code identification numbers may be 7 2 digits in length. The first 6 digits identify the biller (in a maximum population of 1 3 million) with the 7th digit being the check digit. For every biller bar code 4 identification assigned, the following information might be required for central S collection: (1) Biller Name, Address, Phone Number, Fax Number; (2) Biller 6 Administrative Contact Name, Phone Number, E-Mail Address; (3) Biller 7 Remittance Contact Name, Phone Number, E-Mail Address; (4); Electronic Connection Type (ACH or Direct); (5) Bank Name, Address, Remit Account 9 Information, Type; (6) Bank Contact Name, Phone Number, E-Mail Address; (7) Account Number Information - detailed account format specifications. Having 11 collected the foregoing information, a biller bar code identification number would be 12 assigned and a set of bar code print specifications sent to the biller contact. It would 13 then be the responsibility of the biller to print and to remit a set of test bill remittance 14 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 16 physical bar code dimensions satisfied the lowest common denominator bar code 17 scanners at retail. Validation testing would ensure that information, supplied by the 1 ~ biller, regarding the printed bar coded customer account number conformed to 19 published account number validation specifications.
Payment Time Stamp via Federal Reserve ACH Network 21 The INDIVIDUAL NAME field (Field 7) in the ACH CIE Batch Detail' 22 Record contains the customer payment transaction number, which is composed of the 23 following 4 data fields: DCNI unit identification (7 digits), last digit of year (1 digit), 24 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 26 next four digits specify the year and the Julian date of payment submission and 27 completion. The DISCRETIONARY DATA (Field 9) in the ACH CIE Batch Detail 28 Record may be populated with the Payment Complete Time encoded as a two digit 29 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 31 number 26 divided by 4 would yield 6.5 (0630 or 6:30 AM). Time synchronization 32 may be acquired from universal time standards available through the Internet or 1 national dial-up time services (U.S. Naval Observatory, Washington, DC or the 2 National Institute of Standards and Technology, Boulder, CO).
3 ' Whether or not sanctioned by a governmental agency, such as the U.S. Post 4 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 6 have printed proof of payment date and time, by virtue of his store receipt, that a biller 7 could not artificially manipulate for purposes of assessing penalty payments. The 8 biller would also have electronic access to this field as well. Currently, the biller has 9 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 11 date" as specified in the small print of every credit contract can have a variety of 12 individual definitions, none of which is directly visible to or traceable later by the 13 customer. A universal bill payment time stamp would eliminate all the variability of 14 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.
16 The advantage of this date stamping mechanism to the customer is that it 17 would give him marginally more time to remit his bill payment on time to the biller.
18 In the extreme, the customer could pay his bill payment at a late-hours store at one 19 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 21 the biller is that extremely late payments may be electronically credited to the biller 22 no later than 36 hours after customer payment. In the majority of cases in which the 23 biller had multiple daily data feeds from his bank, the credit would probably issue in 24 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 26 with this system in place. In the extreme case, billers could safely invoke 48-hour 27 cut-off notices with little or no error of service call recalls.
28 Electronically remitting data and money through the Federal Reserve ACH
29 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
31 IDENTIFICATION NUMBER, using the standard CIE Entry Detail Record format.
32 If a remitted customer account number is longer than 22 characters, then either one of

-36-1 two possible solutions is available: using Field 3, 80 columns of data in the CIE
2 Addenda Record format; or implementing a dedicated data link to the biller with a 3 biller specific data format.
4 Alternative Electronic Networks to Accommodate Special Billers For high volume billers preferring to have their data delivered to them faster 6 than the current Federal Reserve ACH Network delivery schedule, direct file transfer 7 links (e.g. FTP) from the ETI machine through the Internet may be made available.
8 File data formats and the particular delivery mechanisms may be tailored to meet any 9 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 11 after the scheduled transaction collection system production "system roll"
completes.
12 The "system roll" sorts and aggregates biller data on a daily production schedule -13 once every 12 hours. Payment totals for these transaction batches would be delivered 14 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 16 and transaction dollars via the Federal Reserve ACH Network should be no more than 17 24 hours.
18 Improved Payment Embodiments 19 The embodiments described hereinabove relate, generally, to bar code based biller/payor systems for electronic bill payment. As described hereinabove, it is 21 contemplated that, in an exemplary electronic bill payment infrastructure (e.g., see 22 reference numeral 500 of Figure 5) consistent with the invention, consumers can pay 23 their bills at supermarkets and large retail chain stores and receive immediate credit 24 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 26 payment data for consumer bill payments by 6 AM the very next business day.
27 Contractually, the biller backdates the received bill payments to the "electronic 28 postmark" time and date paid at retail, regardless of the time that the payment data 29 takes to post to the biller's accounts receivable system. Compared to the present paper based remittance processes commonly employed throughout the payments 31 industry today, such an infrastructure provides for an electronic process that remits 32 error-free payment funds and data directly to billers within hours, rather than days.

-37-1 As efficient as this electronic bill payment process may be, it may not be fast 2 enough for the needs of Internet commerce based companies, selling products to 3 electronically connected remote consumers. The electronic bill payment process, as 4 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
6 Mail, a process that can take, on average, anywhere between 6-8 days. When the 7 consumer has the financial resources in hand to pay his bill, he can then remit his 8 payment directly to the biller, electronically, within hours.
9 ~ In an improvement to the electronic infrastructure for this process, described in this section, Internet commerce-based companies can now choose a new bill 11 payment method that is very simple and can reduce the time interval between biller 12 invoice statement generation and consumer payment notification to the biller, to less 13 an hour.
14 Another improvement to the electronic infrastructure for this process, described in this section, is the provision for person-to-person money transfers.
16 Currently, there are several organizations that offer electronic person-to-person 17 money transfers as long as the sending and receiving parties deposit and receive their 18 remitted funds within the same organizational network of geographically dispersed 19 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 21 easily accomplished with a bar coded deposit slip that permits a sender to remit funds 22 directly into a receiver's bank account, and such funds are subsequently accessible for 23 withdrawal at a nearby and convenient Automated Teller Machine (ATM) or for a 24 debit card purchase. The details of these improvements are discussed hereinbelow:
Improved Electronic Bill Payment Network 26 The embodiments described in this section relate to an improved national 27 electronic bill payment network, wherein bar coded invoice statements are generated 28 immediately by the biller or the consumer and remitted to the consumer in the span of 29 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, 31 may go to a local store that accepts and processes these bill payments.
When the 32 consumer payment is processed at retail, it is electronically remitted to the biller with

-38-1 absolute accuracy within 24 hours after receipt of payment, and electronic notification 2 to the biller may occur within minutes after receipt of payment, with no payment 3 repudiation.
4 Such an electronic bill payment network offers the following benefits: The biller benefits by receiving 100 percent accurate electronic bill payment information 6 and good funds, delivered into his bank account by 6 AM the very next business day 7 that can be directly applied to his accounts receivable. The biller benefits by 8 receiving an immediate electronic notification of consumer payment at retail with 9 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.
11 The consumer benefits by receiving an immediate electronically delivered bar coded 12 invoice statement for his Internet shopping basket of products via facsimile, e-mail or 13 other image transmission method. The consumer benefits because he can then pay his 14 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 16 financial information to a remote Internet store. Further, local payment precludes the 17 possibility of future fraud resulting from hackers' or others' unlawful access to any 18 stored financial information left and residing at remote Internet stores.
The local 19 retail establishment benefits by receiving a relatively cost-free margin from each payment transaction taken. Finally, it is anticipated that a national enhanced network 21 with many retail outlets will spur the demand for yet new immediate and 22 electronically delivered financial products and services, using "signature"
specific bar 23 codes, and thus, may generally benefit the economy of the country or other 24 geographic area in which it is implemented.
An exemplary embodiment of the improved bar coded bill payment based 26 system consistent with the present invention utilizes a bar code on the biller invoice, 27 which is delivered to the customer electronically, i.e., by fax, e-mail, or, other image 28 transmission method, and payment information and payment credits are returned to 29 the biller electronically. This system may augment some elements of the biller/payor network 500 (described hereinabove with respect to Figure 5) with faster and parallel 31 processing elements. In this case, the biller accounts receivable and US
Mail 32 consumer remittance mechanisms may be enhanced with a new accounts receivable

-39-1 invoice statement image generation mechanism that can be activated, on demand, 2 either by a biller customer service representative or by a consumer initiated action.
3 The result of either action is a bar coded invoice statement image that is electronically 4 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 6 accessible transaction browser capability, may be enhanced with e-mail, facsimile or 7 other means of electronic notification to the biller when specifically designated 8 payments have been received. An automated caller response system may provide for 9 consumer inquiry confirmation of payments.
Turning now to Figure 22, an exemplary improved electronic bill payment 11 network 2200 is illustrated. For all the goods and services rendered to a consumer 12 over a given traditional billing period (or interactive Internet shopping session), the 13 biller accounts receivable 2202 may accumulate a dollar total and generate a detailed 14 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 16 representative 2201 to replicate a previous invoice statement that a consumer may 17 have lost. For example, if a consumer wants an immediate replacement copy of the 18 invoice for payment, the consumer can access a biller web site to generate a 19 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 21 invoice 2203 is transmitted to the consumer 2204, which transmission may be from a 22 few seconds to several minutes, depending on factors such as the method of 23 transmission, queue capacity, and number of open queue slots. The consumer 24 receives the bar coded invoice statement image 2203.
To pay the bill, the consumer 2203 might go to a local store (or other location 26 with appropriate hardware/softwarelnetwork connection) that processes these bill 27 payments. The time for this to occur is variable, depending upon the consumer's 28 circumstances, and may occur in as little as a few minutes. The consumer 29 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
31 coded items are being scanned. Instead of looking up an in-house UPC code for 32 pricing, the scanner 2205 would pick up the bill payment bar code that identifies the

-40-1 biller to be paid and the account number to be credited. The consumer tells the 2 checkout cashier the amount to be paid on that account and his option for requesting 3 "normal" or "express" payment processing, and the cashier inputs the amount to be 4 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 6 remaining products and items (or bills) continues until the complete total for all goods 7 and services is calculated. Upon receiving payment from the consumer, that bill 8 payment is then complete. The consumer may receive a printed receipt of the 9 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 11 payment data to the data collection network interface unit 2207, which may occur in a 12 little as a few seconds.
13 The data collection network interface 2207 (DCNI) unit collects and stores all 14 the consumer bill payment data in 1 non-volatile memory. Periodically (e.g., throughout the day, and/or based on .time and transaction volume thresholds), the 16 DCNI 2207 transmits the bill payment data to the central site transaction collection 17 system 2211, which is part of a central site computer system 2210 that may also 18 include an Internet server/browser 2212 and/or automatic caller response system 19 2213. Additional transmissions may be scheduled before the daily transaction collection system 2211 aggregation times. If a particular consumer payment is 21 designated for "express" processing, it may immediately be transmitted to the central 22 site computer system 2210 when the transaction void window expires for that 23 payment. The time for the back-end and collection system processing has no impact 24 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 26 collection system 2211 as an independent transaction audit balancing mechanism.
27 The transaction collection system 2211 may continuously (and/or periodically) 28 receive payment data information from a distributed network comprising a plurality of 29 data collection network interface units 2207 deployed at field retail establishments.
Before the last processing window closes at the Federal Reserve Automated Clearing 31 House (ACH) Network 2214, all customer payments may be sorted and aggregated 32 for direct remission to their respective billers, which may take approximately an hour.

-41 -1 As the transaction collection system 2211 receives payment data information 2 from the network of data collection network interface units 2207, it processes and 3 stores each consumer bill payment into a database. Once stored in the database, that 4 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 6 payment data stream, immediate electronic notification may be posted to the biller in 7 one of several possible forms: e-mail, facsimile or biller specified custom electronic 8 form. Accessible from that same database information, an automated caller response 9 system 2213 can verbally confirm the receipt of a particular transaction, particularly for customers 2209 seeking "comfort call" confirmation regarding the status of a 11 payment. For "normal" payments, the biller customer service toll-free number may 12 be nominally printed on the consumer receipt. For "express" payments, the biller 13 customer service toll-free number may be replaced with a special in-house toll-free 14 number to relieve biller customer service representatives 2208 of nervous consumer confirmation inquiry calls, typically for payments that are long overdue.
16 Processing and distribution of electronic payment data may be done using the 17 Federal Reserve Automated Clearing House (ACH) Network 2214, which may take 18 9 hours. At the biller's bank 2215, the electronic payment data may be received from 19 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 21 and/or customer service computer files may be updated. Depending on the "legacy 22 factor" of the biller's computer processing systems, this process can range anywhere 23 from 2-3 hours to 4-5 days.
24 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 26 network/system 500 (described hereinabove with reference to Figures 5 et seq.), as 27 follows:
28 From the biller perspective, both networks 500, 2200 may be capable of 29 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 31 network 2200 may deliver electronic notification of consumer payment information to 32 the biller within minutes after the payment is made at retail with the "express"

- 42 -1 delivery service. All payment funds collected can remain safe and secure within the 2 Federal Reserve banking system network at all times. Moreover, the improved 3 network 2200 can deliver a consumer invoice electronically and immediately, 4 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 6 electronic biller invoice statement image (e-mail, facsimile etc.). With this enhanced 7 network 2200, the biller, having Internet access and using his choice of standard 8 Internet browsers, can confirm a consumer's payment by querying the database of 9 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 11 for the amount stated on the bar coded invoice statement 2203. This point is 12 especially important when it comes to paying various governmental and state license, 13 permit and tax fees. By statute, many states and governmental organizations cannot 14 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 16 payment surcharges, directly assessed from the consumer over and above the due 17 payment amount, are generally acceptable. For example, the Commonwealth of 18 Massachusetts has 307 different types of license, permit and tax fees that must be paid 19 by consumers either by check or cash.
From the consumer perspective, the consumer can have a choice of local 21 payment method (e.g., cash, check, debit card or any credit card), when paying a bar 22 coded invoice statement 2203 at retail. The consumer does not have to divulge any 23 personal financial information to a remote Internet storefront that electronically 24 generates and delivers bar coded invoice statements directly to a consumer.
With this enhanced network 2200, the consumer can subsequently confirm the electronic receipt 26 of his processed payment at retail from an automatic caller response system 2213.
27 Further, with this enhanced network 2200, the consumer, having Internet access and 28 using his choice of standard Internet browsers, can confirm his own payment by 29 querying the database of processed transactions in the transaction collection system 2211 with a specific transaction identification number.
31 Presently for Internet commerce based companies, there is no mechanism 32 available for conducting a purely "cash" sale over the Internet, where consumer cash

- 43 -1 and retail product can be exchanged in one anonymous atomic transaction.
Currently, 2 problems abound with all other forms of present payment methods, as follows:
3 Payment method fees always erode the profit margin of any retail or Internet 4 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 6 purchase price. By law, these merchants cannot charge consumers different prices for 7 the same retail product whether paid for with cash or by credit. Check guarantee 8 companies impose processing charges on every consumer check passed through their 9 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 11 his profit margin as a normal "cost of doing business". Checks, if exchanged, take 12 time to clear and can be "stop paid" at the whim of the consumer. No one is exposed 13 in this situation if the seller chooses to wait out the prescribed check clearing time (on 14 average, approximately 4-5 days); however, ultimate consumer satisfaction will be impacted by this delay. Credit card transactions require the consumer to divulge 16 personal financial information to the remote Internet seller, which leaves open the 17 potential for future and untraceable fraud. Then, that credit card transaction can be 18 disputed and repudiated by the consumer, up to 60 days later, leaving the seller with 19 an uncollectable debt. While debit card transactions cannot be repudiated, they also require the consumer to divulge personal financial information to the remote Internet 21 seller, again, leaving open the potential for future and untraceable fraud.
The 22 consumer generally has no guaranteed recourse to recover any stolen funds debited 23 from his account. Third party "e-wallet" payment type companies that require 24 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 26 guaranteed recourse to recover any stolen funds debited from his E-Wallet.
27 The enhanced electronic bill payment network 2200 consistent with the 28 present invention permits remote buyers and sellers to perform anonymous "cash"
29 sale transactions, using the Federal Reserve banking system as the trusted escrow agent to safely and securely transfer funds between buyers and sellers.
31 An advantageous feature of this enhanced bill payment network, with a 32 standardized bar coded bill payment "signature" featured as its centerpiece remittance

-44-1 mechanism, is that all the non-deterministic time delays have been removed from the 2 total bill payment cycle. In legacy bill pay arrangements, the two largest delay factors 3 are the biller invoice paper statement preparation, printing, mailing systems and the 4 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 6 consumer can request an immediate invoice statement, which only requires minutes to 7 formulate and to deliver electronically. The consumer has his choice of payment 8 methods at a trusted local retail establishment and receives a printed bill payment 9 receipt confirmation, guaranteed by the biller. The consumer payment method to the biller is completely anonymous, in terms of divulged personal financial information.
11 Subsequently, the consumer, as well as the biller, can verify that the bill payment has 12 been received and processed at the central payment distribution site.
Thereafter, 13 payment funds and information may be electronically remitted to the biller within 14 hours, by 6 AM the following business day directly into the biller's bank account.
It should be recognized by those skilled in the art that, although the foregoing 16 description refers to a bar code transmitted by e-mail or by facsimile, other methods 17 of transmission are possible and are included in the invention, e.g., facsimile 18 transmission to or from a computer, facsimile machine, e-mail, file transfer protocol 19 (FTP), hypertext markup language (HTML), extended markup language (XML), hypertext transport protocol (HTTP), modem, the Internet, a wide-area network 21 (WAN), a local-area network (LAN), diskette, or other removable storage medium.
22 Money Transfer Embodiments 23 In the above descriptions of an exemplary electronic bill payment network 24 (described hereinabove with reference to Figures 5 et seq.), references have been made regarding the extensibility of this network and its internal structure to provide 26 for new, cost-effective financial products and services. Domestic and international 27 person-to-person money transfer services is one such product described here. (Of 28 course, the money transfer technology described in this section may also have 29 applicability to business-to-person, person-to-business, business-to-business, or other types of money transfers.) 31 The current forms of domestic and international money transfer services 32 offered today are very labor intensive for both the person sending the money as well

- 45 -1 as the service provider. The amount of paperwork that has to be filled out by the 2 sender and then manually transcribed into a "communication system" by the service 3 provider has been the ostensible justification to the customer of the high fee structure 4 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 6 service providers in this industry, primarily serving immigrant communities whose 7 members regularly send money to their home country families. Some service 8 providers, such as Western Union, use relatively "high tech" electronic 9 communication services to transfer funds while other small service providers use "low tech" courier services to physically transport funds to their intended destination.
11 Currently, there are several organizations that sell domestic or international 12 electronic person-to-person money transfers as long as the sending and receiving 13 parties deposit and pick up the remitted funds within the same organizational network 14 of geographically dispersed branch offices. Fees for this service can range upwards from $35 per transfer. However, convenient remittance locations for the local sender 16 may not have corresponding convenient delivery locations for the remote receiver, or 17 vice-versa.
18 In a system consistent with the present invention, domestic person-to-person 19 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, 21 providing funds that are subsequently accessible at a convenient local automated teller 22 machine (ATM) or for a debit card purchase.
23 Future international (e.g., Mexican) person-to-person money transfers can be 24 coordinated with appropriate financial organizations or banks that commonly distribute a form of debit card to their customer base. These organizations would 26 distribute to their customer base plastic bar coded deposit-only cards keyed directly to 27 their debit card, which may then be sent to a remitter in another country (e.g., the 28 United States). Using that bar coded plastic deposit-only card instead of a bar coded 29 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 31 international money transfers could cost far less than the fees charged today for this 32 equivalent service.

- 46 -1 The complete details of a bar coded bill payment "signature" are described 2 hereinabove in the section entitled "Bar Coding Validation" with respect to Figures 10 3 and 11, wherein a structure of successive data envelopes of embedded "signature"
4 data fields are employed, consisting of a series of format designators, data and check digits. In the examples of Figures 10 and 11, which illustrate two arbitrary format 6 designator values, the customer account number consisted of one numeric field whose 7 associated check digit was the trailing digit of either a divulged format (=
3) or an 8 unknown format (= 4) to which the biller appended a check digit according to a 9 specified algorithm. In both cases, there is an independent mechanism in place to mathematically check the validity of the customer account number.
11 In the person-to-person electronic money transfer embodiment described in 12 this section, the retail based electronic bill payment infrastructure is utilized, with the 13 modification that the biller identification number is now used to identify the 14 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 16 number system consisting of an ABA (American Banking Association) number (8 17 digits plus a check digit), uniquely identifying the U.S. bank institution, and a local 18 account numbering convention within that banking institution. While the format 19 designator = 4 validation template scheme can reliably be used to implement a generalized person-to-bank account remittance mechanism within the structure of the 21 electronic bill payments infrastructure, the definition of a new format designator 22 validation template would offer several advantages: An additional customer account 23 number validation step further reduces data errors. Within the full customer specified 24 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 26 recognition of the fact that there are many fewer bank based or money transfer 27 payment networks than billers. With a reduced number string, shorter bar code 28 strings fit more appropriately on small banking deposit slips that measure, on average, 29 6" wide by 3" high.
Figure 23 illustrates an exemplary specification for the new format designator 31 = S format. As shown, the bar code 2300 comprises a 1-digit format designator value 32 = S; the number of components (2 fixed length (3,9), 1 variable length) by definition;

-47-1 2-digit payment network identification number; 1 check digit of preceding 2 digits 2 using 37 weights, MOD10 algorithm; 8-digit ABA number (51066065); 1 check digit 3 of preceding 8 digits using 37137137 weights, MOD 10 algorithm; entire customer 4 bank account number (5106606550766936692) using 1212... weights, split MOD10 with added check digit to be discarded before presentment to the destination payment 6 network (4); and calculated check digit of level 3 envelope using 2121...
weights, 7 split MOD 10 algorithm (4).
8 As illustrated in Figure 24, this bar code 2401 appearing on a bank deposit slip 9 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, 11 identification card, smart card, or card bearing at least one name corresponding to an 12 account number encoded in said bar code) could be presented at a retail checkout 13 aisle, equipped for bill payment transactions, to initiate domestic person-to-person 14 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
16 machine or to make payment from a debit card keyed or associated with that account.
17 The ATM or debit card PIN (personal identification number) provides the same level 18 of access security to the receiver of these person-to-person money transfers as exists 19 for local funds that already reside in the account.
To implement an international (i.e., any-person-to-any-person electronic 21 money transfer) using the retail based electronic bill payment infrastructure, the biller 22 identification number may be used to uniquely identify the target destination payment 23 network. In the case of a foreign payment network based on a system of debit card 24 accounts, the format designator = 4 validation template scheme can reliably be used to implement and validate any generalized account numbering scheme to remit funds. A
26 new format designator validation template definition offers extended customer 27 account number verification advantages only if the destination payment network is 28 willing to divulge its mathematical or other method of customer account numbering 29 validation scheme.
In a hypothetical exemplary scenario consistent with the invention, a national 31 chain of retail gas stations/convenience supermarket stores called GasoMax is located 32 throughout the whole of Mexico, serving the public at large. GasoMax issues PIN

-48-1 protected debit cards to all their customers, in effect, setting up a pseudo-bank 2 account for each of them. Instead of carrying cash, these customers deposit or apply 3 money to these accounts so that they can later purchase food staples or convenience 4 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 6 are included (and/or a bar code might be printed on the debit card itself).
The debit 7 card can either be used to deposit local money into their account or to withdraw 8 money in the form of purchases at the national chain GasoMax gas stations.
Figure 9 25 illustrates an exemplary GasoMax debit card 2500, which resembles a standard debit card. Figure 26 illustrates an exemplary deposit-only card 2600 comprising a 11 bar code 2601 consistent with the invention. In this exemplary scenario, the bar 12 coded deposit-only card 2600 (or, alternatively, a bar code printed on the standard 13 debit card) would be used in U.S. retail stores that offer access to the electronic bill 14 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 16 GasoMax bar coded deposit-only card 2600 is making a payment to a destination 17 payment network (Payment Network = 5 l, using a standard Format Designator = 4 18 description). Payments remitted to this payment network are automatically converted 19 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 21 $300 remittance as a foreign exchange (FX) fee on top of the base $35 remittance fee.
22 In the recent past, wire transfer companies have been sanctioned for these usurious 23 currency exchange practices. GasoMax would have a greater incentive to offer a 24 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 26 customer base to shop for goods and services through its chain of gas station 27 supermarkets that also offers a convenient money transfer service, as an affinity draw 28 or loyalty program, for relatives working outside of the country to support their loved 29 ones in Mexico.
Several further examples of "real-life" scenarios demonstrating the utility of 31 an improved payment network consistent with the invention are provided, as follows:

-49-1 Example 1: Payment for Mobile Telephone Service 2 A client procures a mobile phone subscription from a well-known national 3 vendor. The client gives his place of employment as his cell phone billing address.
4 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 6 changing his mobile phone billing address and continues to use his mobile phone 7 regularly, until one day his mobile phone stops working. When he calls the customer 8 service office to inquire about the matter, he finds out that his mobile phone usage is 9 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 11 accept credit card payments and only accepts a check payment for the total past due 12 amount. The company restores his service ten days after receiving and processing his 13 check.
14 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, 16 as described hereinabove. The mobile phone company would have been 17 electronically notified minutes after his retail payment, so that his cell phone service 18 could be restored within an hour, rather than days.
19 Example 2: Payment for Internet-Based Auction The business model for the Internet-based auction (e.g., eBay) is very basic in 21 concept, a meeting place for bringing together Internet buyers and sellers, wherein an 22 electronic framework displays sellers' goods and services. When a sale is completed 23 between a seller and a buyer, the online auction house charges a sales commission. It 24 is the responsibility of the seller and the buyer to establish a lowest common denominator payment exchange method. Individuals selling items, are generally not 26 equipped to process Mastercard or VISA credit or debit cards. If the seller accepts a 27 personal check payment from the buyer, shipment of the sold item is delayed until the 28 buyer check clears. A buyer can mitigate a seller shipment delay if he is willing to go 29 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 31 register personal financial information about their respective bank accounts to transfer 32 money, as well as pay yet another sales commission charge. In general, none of these

-50-1 payment alternatives are particularly attractive if a buyer or seller desires any degree 2 of financial confidentiality.
3 With an electronic payment network consistent with the invention in place, an 4 online auction house could provide a cost-effective and value-added anonymous payment alternative within its framework of auction services. When a sale is 6 completed, the online auction house provides the means for the buyer to print out a 7- bar coded invoice statement, citing the online auction house as the biller of record 8 with a transaction identification number. Instead of purchasing a money order, which 9 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 11 next business day, it notifies the seller of the completed payment via e-mail and then 12 sends a check for that payment amount to the seller. Aside from exchanging their 13 mailing addresses, both buyer and seller maintain their financial privacy.
14 This same sales paradigm would also work well for home shopping television channel environments, (e.g., Home Shopping Network, QVC), wherein the "express"
16 payment option could be used when buyer desire is at its highest level.
17 Example 3: Automobile Insurance Payment 18 Insurance companies have varying grace periods within which to pay their 19 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 21 installment plan of smaller payments may alternatively be offered. If a premium 22 payment is not received, a cancellation notice is sent toward the end of the payment 23 grace period specifying a "hard" cancellation date. If a policy is canceled due to non-24 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.
26 Therefore, given the gravity of the possible consequences, time is of the essence when 27 it comes to paying insurance premiums on time - whether for car insurance, home 28 insurance or personal life insurance. Mailed late payments may not be delivered and 29 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
31 confirmed electronic payment made using an enhanced bill payment network

-51-1 consistent with the invention would provide a way for both the insurance company 2 and insureds to know precisely when premiums are paid.
3 Example 4: Payment to College Student 4 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
6 printed bar coded bill payment "signature" on out-of town bank checking account 7 deposit slips would enable remote deposits with a simple cash, check, debit card or 8 any credit card payment at a local supermarket. A college-bound child could have 9 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 11 resolution mode) will generally perform the job equally well. Funds deposited with 12 this payment mechanism are electronically available the very next morning for 13 withdrawal from a local ATM cash-dispensing machine. For a small fee (e.g., about a 14 dollar), this service is much faster, more convenient to all parties involved and cost-effective than any existing person-to-person money transfer service.
16 Further Alternate Embodiments 17 The present invention may use the public Internet and Internet compatible 18 HTTP and UDP protocols for the network interconnections described herein, as well 19 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, 21 as well as any other components described herein may be implemented in software, 22 hardware, or a combination of both, and may be separate components or be integrated 23 into other components described above. Likewise, the processes described herein 24 may be separate or combined and may run on common, shared, or separate machines, and as integrated or separate software modules.
26 Additionally, scanning bar codes, in methods consistent with the invention, 27 may be performed using, e.g., wand or handheld scanning devices, scanning devices 28 mounted to or near a point of sale system, and other such scanning devices, and such 29 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 31 with the invention may alternatively be coupled to or integrated into a PDA, handheld 32 or pocket computer, as well as~ a mobile telephone or other portable, wireless, or

-52-1 computerized device. Thus, it is contemplated that an account corresponding to a 2 mobile telephone or other such device, or other credit or debit account corresponding 3 to the user of such a device, could be automatically debited for payment to a payee, in 4 methods consistent with the invention.
It will be appreciated by those skilled in the art that, although the functional 6 components of the above described embodiments of the system of the present 7 invention are embodied as one or more distributed computer program processes, data 8 structures, dictionaries or other stored data on one or more conventional general 9 purpose computers (e.g. IBM-compatible, Apple Macintosh, and/or RTSC
microprocessor-based computers), mainframes, minicomputers, conventional 11 telecommunications (e.g. modem, DSL, satellite and/or ISDN communications), 12 memory storage means (e.g. RAM, ROM) and storage devices (e.g. computer-13 readable memory, disk array, direct access storage) networked together by 14 conventional network hardware and software (e.g. LAN/WAN network backbone systems and/or Internet), other types of computers and network resources rnay be used 16 without departing from the present invention.
17 The invention as described herein may be embodied in one or more computers 18 residing on one or more server systems, and input/output access to the invention may 19 comprise appropriate hardware and software (e.g. personal and/or mainframe computers provisioned with Internet wide area network communications hardware 21 ~ and software (e.g. CQI-based, FTP, Netscape NavigatorTM or Microsoft Internet 22 ExplorerTM HTML Internet browser software, and/or direct real-time TCP/IP
23 interfaces accessing real-time TCP/IP sockets) for permitting human users to send and 24 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.
26 Likewise, it is contemplated that the above-described servers consistent with the 27 present invention may be remote Internet-based servers accessible through 28 conventional communications channels (e.g. conventional telecommunications, 29 broadband communications, wireless communications) using conventional browser software (e.g. Netscape NavigatorTM or Microsoft Internet ExplorerTM), and that the 31 present invention should be appropriately adapted to include such communication 32 functionality. Additionally, those skilled in the art will recognize that the various

-53-1 components of the system of the present invention can be remote from one another, 2 and may further comprise appropriate communications hardware/software and/or 3 LAN/WAN hardware andlor software to accomplish the functionality herein 4 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 6 network.
7 Moreover, each of the functional components of the present invention may be 8 embodied as one or more distributed computer program processes running on one or 9 more conventional general purpose computers networked together by conventional networking hardware and software. Each of these functional components may be 11 embodied by running distributed computer program processes (e.g., generated using 12 "full-scale" relational database engines such as IBM DB2TM, Microsoft SQL
Server 13 TM, Sybase SQL Server TM, or Oracle 8.0 ~ database managers, and/or a JDBC
14 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 16 IBM SB2 TM or HP 9000 ~ computer systems) including appropriate mass storage, 17 networking, and other hardware and software for permitting these functional 18 components to achieve the stated function. These computer systems may be 19 geographically distributed and connected together via appropriate wide- and local-area network hardware and software.
21 Primary elements of the invention may be server-based and may reside on 22 hardware supporting an operating system such as Microsoft Windows NT/2000TM
or 23 UNIX. Clients may include computers with windowed or non-windowed operating 24 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 26 ~, Windows CE TM -based or other handheld computer, a network- or web-enabled 27 mobile telephone or similar device, or any other computer capable of TCP/IP
or other 28 network-based interaction. The communications media described herein (generally 29 referred to using the generic term "network") may be a wired or wireless network, or a combination thereof.
31 Alternatively, the aforesaid functional components may be embodied by a 32 plurality of separate computer processes (e.g. generated via dBase TM, Xbase TM, MS

-54-1 Access TM or other "flat file" type database management systems or products) running 2 on IBM-type, Intel Pentium TM or RISC microprocessor-based personal computers 3 networked together via conventional networking hardware and software and including 4 such other additional conventional hardware and software as is necessary to permit S these functional components to achieve the stated functionalities. In this alternative 6 configuration, since such personal computers typically are unable to run full-scale 7 relational database engines of the types presented above, a non-relational flat file 8 "table" may be included in at least one of the networked personal computers to 9 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 11 NT/2000 TM or Windows 9S/98/METM operating system. The aforesaid functional 12 components of a system consistent with the present invention may also comprise a 13 combination of the above two configurations (e.g. by computer program processes 14 running on a combination of personal computers, RISC systems, mainframes, 1 S symmetric or parallel computer systems, and/or other appropriate hardware and 16 software, networked together via appropriate wide- and local-area network hardware 17 and software).
18 As those in the art will recognize, possible embodiments of the invention may 19 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 21 may comprise security means in the including one or more of the following:
password 22 or PIN number protection, use of a semiconductor, magnetic or other physical key 23 device, biometric methods (including fingerprint, nailbed, palm, iris, or retina 24 scanning, handwriting analysis, handprint recognition, voice recognition, or facial 2S imaging), or other security measures known in the art. Such security measures may 26 be implemented in one or more processes of the invention.
27 Source code may be written in an object-oriented or non-object-oriented 28 programming language using relational or flat-file databases and may include the use 29 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 31 screen displays illustrated herein at Figures 1 S-21 are provided by way of example -SS-1 only, and are not to be construed as limiting the invention or any component thereof 2 to the exemplary embodiments illustrated therein.
3 Furthermore, it is contemplated that the system and method described herein 4 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 6 invention. Such users may pay for the use of the invention based on the number of 7 files, messages, bills, or other units of data sent or~received or processed, based on 8 bandwidth used, on a periodic (weekly, monthly, yearly) or per-use basis, or in a 9 number of other ways consistent with the invention, as will be appreciated by those skilled in the art.
11 Those skilled in the art will recognize that the present invention may be 12 implemented in hardware, software, or a combination of hardware and software.
13 Finally, it should also be appreciated from the outset that one or more of the 14 functional components may alternatively be constructed out of custom, dedicated electronic hardware and/or software, without departing from the present invention.
16 Thus, the present invention is intended to cover all such alternatives, modifications, 17 and equivalents as may be included within the spirit and broad scope of the invention 18 as defined only by the hereinafter appended claims.

Claims (124)

What is claimed is:

1. A bill payment system comprising:

a biller generating at least one invoice for at least one customer, said invoice comprising a unique bar code, said bar code comprising data identifying at least said customer and said biller; and a scanning apparatus configured to scan said bar code, said scanning apparatus being capable, based on the identifying data of said bar code and a payment made by said customer, of concurrently transmitting or initiating transfer of funds to said biller in a predetermined amount and transmitting or initiating transfer of data to said biller regarding said payment.

2. A system according to claim 1, wherein said funds are transmitted or transferred as an electronic funds transfer.

3. A system according to claim 1, wherein said funds are transmitted or transferred via the Automated Clearing House.

4. A system according to claim 1, wherein said bar code comprises a plurality of validation levels.

5. A system according to claim 1, wherein said data comprises the date and time said customer makes said payment.

6. A system according to claim 1, wherein said apparatus is integrated into a point-of-sale system.

7. A system according to 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, and retail store.

8. A system according to claim 1, wherein said bar code is in a location selected from the group consisting of: on the front of said invoice, on the reverse of said invoice, detachably printed on said invoice, and on a separate piece of paper from said invoice.

9. A system according to claim 1, wherein said data identifying said biller is assigned by a central registry authority.

10. A system according to claim 1, wherein said apparatus is configured to print a receipt evidencing said payment.

11. A bill payment method comprising:
generating an invoice for at least one customer, said invoice comprising a unique bar code, said bar code comprising data identifying at least said customer and said biller; and permitting a third party to scan said bar code and, based on the identifying data of said bar code and a payment made by said customer, to concurrently transmit or initiate transmission of funds to said biller in a predetermined amount and transmit or initiate transmission of data to said biller regarding said payment.

12. A method according to claim 11, wherein said funds are transmitted or transferred as an electronic funds transfer.

13. A method according to claim 11, wherein said funds are transmitted or transferred via the Automated Clearing House.

14. A method according to claim 11, wherein said bar code comprises a plurality of validation levels.

15. A method according to claim 11, wherein said data comprises the date and time said customer makes said payment.

16. A method according to claim 11, wherein said scanning is performed at a point-of-sale system.

17. A method according to claim 11, wherein said scanning is performed 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, and retail store.

18. A method according to claim 11, wherein said bar code is in a location selected from the group consisting of on the front of said invoice, on the reverse of said invoice, detachably printed on said invoice, and on a separate piece of paper from said invoice.

19. A method according to claim 11, wherein said data identifying said biller is assigned by a central registry authority.

20. A method according to claim 11, further comprising printing a receipt evidencing said payment.

21. A bill payment network comprising:

a plurality of billers, each said biller generating an invoice for at least one customer, said invoice comprising a unique bar code, said bar code comprising data identifying at least said customer and said biller; and a plurality of third parties in communication with said billers, each said third party capable of scanning said bar code and, based on the identifying data of said bar code and a payment made by said customer, of concurrently transmitting or initiating transfer of funds to said biller in a predetermined amount and transmitting or initiating transfer of data to said biller regarding said payment.

22. A network according to claim 21, wherein said funds are transferred or transmitted as an electronic funds transfer.

23. A network according to claim 21, wherein said funds are transferred or transmitted via the Automated Clearing House.

24. A network according to claim 21, wherein said bar code comprises a plurality of validation levels.

25. A network according to claim 21, wherein said data comprises the date and time said customer makes said payment.

26. A network according to claim 21, wherein said third party is capable of performing said scanning using a point-of-sale system.

27. A network according to claim 21, 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, and retail store.

28. A network according to claim 21, wherein said bar code is in a location selected from the group consisting of on the front of said invoice, on the reverse of said invoice, detachably printed on said invoice, and on a separate piece of paper from said invoice.

29. A network according to claim 21, wherein said data identifying said biller is assigned by a central registry authority.

30. A network according to claim 21, wherein said third party is configured to print a receipt evidencing said payment.

31. A bill payment method comprising:

receiving an invoice from a biller, said invoice comprising a unique bar code, said bar code comprising data identifying at least a customer and said biller;
and permitting a third party in communication with said biller to scan said bar code and, based on the identifying data of said bar code and a payment made by said customer, to concurrently transmit or initiate transfer of funds to said biller in a predetermined amount and transmit or initiate transfer of data to said biller regarding said payment.

32. A method according to claim 31, wherein said funds are transferred or transmitted as an electronic funds transfer.

33. A method according to claim 31, wherein said funds are transferred or transmitted via the Automated Clearing House.

34. A method according to claim 31, wherein said bar code comprises a plurality of validation levels.

35. A method according to claim 31, wherein said data comprises the date and time said customer makes said payment..

36. A method according to claim 31, wherein said scanning is performed at a point-of-sale system.

37. A method according to claim 31, wherein said scanning is performed 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, and retail store.

38. A method according to claim 31, wherein said bar code is in a location selected from the group consisting of on the front of said invoice, on the reverse of said invoice, detachably printed on said invoice, and on a separate piece of paper from said invoice.

39. A method according to claim 31, wherein said data identifying said biller is assigned by a central registry authority.

40. A method according to claim 31, further comprising printing a receipt evidencing said payment.

41. A payment network comprising:
at least one payor;
at least one payee maintaining an account corresponding to said payor;

a payment system adapted first to receive a payment from said payor, and subsequently, to simultaneously transmit or initiate transfer of funds to said payee in a predetermined amount based on said payment and transmit or initiate transfer of data to said payee regarding said payment, said data including the date and time said payment system received said payment from said payor;

wherein said payee credits said account corresponding to said payor in the amount of said payment as of said date and time said payment system receives said payment from said payor.

42. A bill payment network comprising:
at least one payor;
a plurality of billers, each said biller maintaining an account corresponding to at least one said payor;

a bill payment system adapted first to receive a payment from at least one said payor, and subsequently, to simultaneously transmit or initiate transfer of funds to said biller in a predetermined amount based on said payment and transmit or initiate transfer of data to said biller regarding said payment, said data including the date and time said system received said payment;

wherein said biller credits said account corresponding to said payor in the amount of said payment as of said date and time said bill payment system receives said payment from said payor.

43. A payment network comprising:
at least one payor;
at least one payee maintaining an account corresponding to said payor;
a payment system adapted first to receive a payment from said payor, and subsequently, to simultaneously transmit or initiate transfer of funds to said payee in a predetermined amount based on said payment and transmit or initiate transfer of data to said payee regarding said payment, said data including the date and time said payment system received said payment from said payor;

wherein said payee agrees to credit said account corresponding to said payor in the amount of said payment as of said date and time said payment system receives said payment from said payor.

44. A bill payment network comprising:

at least one payor;

a plurality of billers, each said biller maintaining an account corresponding to at least one said payor;

a bill payment system adapted first to receive a payment from at least one said payor, and subsequently, to simultaneously transmit or initiate transfer of funds to said biller in a predetermined amount based on said payment and transmit or initiate transfer of data to said biller regarding said payment, said data including the date and time said system received said payment from said payor;

wherein said biller agrees to credit said account corresponding to said payor in the amount of said payment as of said date and time said bill payment system receives said payment from said payor.

45. A payment network as claimed in claim 41, wherein said payment system transmits or initiates transfer of said data and said funds to said payee in said predetermined amount on the same calendar or business day or next calendar or business day following the date said payment system receives said payment from said payor, or within 24 hours or less of the date and time said payment system receives said payment from said payor.

46. A bill payment network as claimed in claim 42, wherein said bill payment system transmits or initiates transfer of said data and said funds to said biller in said predetermined amount on the same calendar or business day or next calendar or business day following the date said bill payment system receives said payment from said payor, or within 24 hours or less of the date and time said bill payment system receives said payment from said payor.

47. A payment network as claimed in claim 43, wherein said payment system transmits or initiates transfer of said data and said funds to said payee in said predetermined amount on the same calendar or business day or next calendar or business day following the date said payment system receives said payment from said payor, or within 24 hours or less of the date and time said payment system receives said payment from said payor.

48. A bill payment network as claimed in claim 44, wherein said bill payment system transmits or initiates transfer of said data and said funds to said biller in said predetermined amount on the same calendar or business day or next calendar or business day following the date said bill payment system receives said payment from said payor, or within 24 hours or less of the date and time said bill payment system receives said payment from said payor.

49. A payment network as claimed in claim 41, wherein said payment system identifies the payee said payor is paying by scanning a bar code comprising information corresponding to said payee.

50. A bill payment network as claimed in claim 42, wherein said bill payment system identifies the biller said payor is paying by scanning a bar code comprising information corresponding to said biller.

51. A payment network as claimed in claim 43, wherein said payment system identifies the payee said payor is paying by scanning a bar code comprising information corresponding to said payee.

52. A bill payment network as claimed in claim 44, wherein said bill payment system identifies the biller said payor is paying by scanning a bar code comprising information corresponding to said biller.

53. A system as claimed in claim 5, wherein said biller applies said payment made by said customer against said invoice as of said date and time said customer makes said payment.

54. A method as claimed in claim 15, wherein said biller applies said payment made by said customer against said invoice as of said date and time said customer makes said payment.

55. A network as claimed in claim 25, wherein said biller applies said payment made by said customer against said invoice as of said date and time said customer makes said payment.

56. A method as claimed in claim 35, wherein said biller applies said payment made by said customer against said invoice as of said date and time said customer makes said payment.

57. A payment system comprising:
a payor;
a payee furnishing said payor with a unique bar code, said bar code comprising data identifying at least said payor and said payee; and a scanning apparatus configured to scan said bar code, said scanning apparatus being capable, based on the identifying data of said bar code and a payment made by said payor, of electronically transmitting to said payee or initiating a transfer to said payee of both funds in a predetermined amount and data comprising the date and time said payor makes said payment.

58. A payment method comprising:
scanning a unique bar code for a payor, said bar code comprising data identifying at least said payor and a payee;
receiving a payment from said payor; and based on the identifying data of said bar code and said payment, electronically transmitting or initiating a transfer to said payee both funds in a predetermined amount and data comprising the date and time said payor makes said payment.

59. A method of providing for payment of bills by payors to billers, comprising:
making available to one or more billers a standard format for representing on a printed document data including biller identification and payor account identification;
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 from one of said scanning apparatus data comprising third party identification, biller identification, payor account identification and payment amount; and providing information to a payment network to effect transmission of funds from an account of said third party to an account of one of said billers identified by said biller identification in an amount identified by said payment amount and concurrently effecting transmission of payment information to said biller.

60. A method as claimed in claim 59, wherein said payment information comprises the date and time said payment is made.

61. 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.

62. A system as claimed in claim 61, wherein said funds are transmitted or transferred as an electronic funds transfer or via the Automated Clearing House.

63. A system according to claim 61, wherein said apparatus is adapted to print a receipt evidencing said payment.

64. A system as claimed in claim 61, wherein said bar code comprises a plurality of validation levels.

65. A system as claimed in claim 61, wherein said data comprises the date and time said payor makes said payment.

66. A system as claimed in claim 61, wherein said apparatus is integrated into a point-of sale system.

67. A system as claimed in claim 61, 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.

68. A system as claimed in claim 61, 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.

69. A system as claimed in claim 61, further comprising an automatic caller response system and/or Internet access to said data by said payee and/or said payor.

70. A system as claimed in claim 61, 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.

71. A system as claimed in claim 61, 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.

72. A system as claimed in claim 61, 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.

73. 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.

74. A method as claimed in claim 73, wherein said transmission or transfer of funds is an electronic funds transfer or via the Automated Clearing House.

75. A method as claimed in claim 73, further comprising printing a receipt evidencing said payment.

76. A method as claimed in claim 73, wherein said bar code comprises a plurality of validation levels.

77. A method as claimed in claim 73, wherein said data comprises the date and time said payor makes said payment.

78. A method as claimed in claim 73, 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.

79. A method as claimed in claim 73, 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.

80. A method as claimed in claim 73, 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.

81. A method as claimed in claim 73, further comprising permitting access to said data by said payee and/or said payor via an automatic caller response system and/or the Internet.

82. A method as claimed in claim 73, 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.

83. A method as claimed in claim 73, 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.

84. A method as claimed in claim 73, wherein said payee further comprises accounting software, wherein said step of transmitting or transferring said data to said payee occurs via said accounting software.

85. 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.

86. A money transfer system as claimed in claim 85, wherein said apparatus is further capable of transmitting data or initiating a data transfer to a payee regarding said payment.

87. A money transfer system as claimed in claim 85, wherein said destination payment network comprises a plurality of organizations having a common account numbering scheme.

88. A money transfer system as claimed in claim 87, wherein at least one said organization is identified in said bar code by an American Bankers Association (ABA) number.

89. A money transfer system as claimed in claim 85, 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.

90. A money transfer system as claimed in claim 85, wherein said funds are transmitted or transferred as an electronic funds transfer or via the Automated Clearing House.

91. A money transfer system as claimed in claim 85, wherein said apparatus is adapted to print a receipt evidencing said payment.

92. A money transfer system as claimed in claim 85, wherein said bar code comprises a plurality of validation levels.

93. A money transfer system as claimed in claim 86, wherein said data comprises the date and time said payor makes said payment.

94. A money transfer system as claimed in claim 85, wherein said apparatus is integrated into a point-of sale system.

95. A money transfer system as claimed in claim 85, 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.

96. A money transfer system as claimed in claim 85, 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.

97. A money transfer system as claimed in claim 86, further comprising an automatic caller response system and/or Internet access to said data by said payee and/or said payor.

98. A money transfer system as claimed in claim 85, 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.

99. A money transfer system as claimed in claim 85, 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.

100. A money transfer system as claimed in claim 86, further comprising accounting software, wherein said system is adapted to transmit or initiate transfer of said data to said payee via said accounting software.

101. 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 funds 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.

102. A method as claimed in claim 101, further comprising transmitting data or initiating a data transfer to a payee regarding said payment.

103. A method as claimed in claim 101, wherein said destination payment network comprises a plurality of organizations having a common account numbering scheme.

104. A method as claimed in claim 103, wherein at least one said organization is identified in said bar code by an American Bankers Association (ABA) number.

105. A method as claimed in claim 101, 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.

106. A method as claimed in claim 101, wherein said funds are transmitted or transferred as an electronic funds transfer or via the Automated Clearing House.

107. A method as claimed in claim 101, further comprising printing a receipt evidencing said payment.

108. A method as claimed in claim 101, wherein said bar code comprises a plurality of validation levels.

109. A method as claimed in claim 102, wherein said data comprises the date and time said payor makes said payment.

110. A method as claimed in claim 101, wherein said apparatus is integrated into a point-of-sale system.

111. A method as claimed in claim 101, 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.

112. A method as claimed in claim 101, 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.

113. A method as claimed in claim 102, further comprising providing an automatic caller response system and/or Internet access to said data for use by said payee and/or said payor.

114. A method as claimed in claim 101, 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.

115. A method as claimed in claim 101, 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.

116. A method as claimed in claim 102, further comprising transmitting or initiating a transfer of said data to said payee via accounting software.

117. 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.

118. A deposit slip as claimed in claim 117, wherein said bar code comprises a plurality of validation levels.

119. A printed bar code comprising:
data identifying at least an account number and a destination payment network corresponding to said account number.

120. A printed bar code as claimed in claim 119, wherein said bar code comprises a plurality of validation levels.

121. 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.

122. A method as claimed in claim 121, 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.

123. 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.

124. A method as claimed in claim 123, wherein said payment information comprises the date and time said payment is made.