WO2003094124A2

WO2003094124A2 - Method and apparatus for employing checks

Info

Publication number: WO2003094124A2
Application number: PCT/US2001/043645
Authority: WO
Inventors: Jay S. Walker; Peter Kim; Brian M. Dugan; Michiko Kobayashi; Andrew P. Golden; James A. Jorasch; Geoffrey M. Gelman
Original assignee: Walker Digital, Llc
Priority date: 2001-11-14
Filing date: 2001-11-14
Publication date: 2003-11-13
Also published as: AU2002219821A1

Description

METHOD AND APPARATUS FOR EMPLOYING CHECKS

CROSS-REFERENCE TO RELATED U.S. APPLICATIONS

This application claims priority from U.S. Provisional Patent Application Serial No. 60/206,328, filed May 23, 2000, the content of which is hereby incorporated by reference herein in its entirety.

FIELD OF THE INNENTION

The present invention relates generally to payment techniques, and more specifically to methods and apparatus for employing checks.

BACKGROUND OF THE INNENTION To purchase an item over the Internet (e.g., to purchase an item while "online"), a customer typically must provide a credit card account number as payment for the item. However, because of personal preferences, poor credit and/or a lack of a credit line, many potential customers do not purchase items while on-line (e.g., because the customers either refuse or are unable to provide credit card information over the Internet).

One technique for addressing customer preferences and/or credit issues is to allow customers to employ a bank check to pay for items ordered on-line. Such a technique is popular because the use of checks and the sense of comfort, of security and of control associated with recording check information in a checkbook and balancing a checkbook are entrenched in modern society. For example, the chairman of the Federal Reserve has stated that Americans write 68 billion checks per year, and that this number is expected to increase in the future. (See, for example, "Central Bank Seen Moving Toward Shift in Checking", The New York Times, Late Edition - Final, Section C, page 7, column 1, Business/Financial Desk (April 11, 2000)).

While the use of checks does address many customer preference and credit issues, conventional check usage is inconvenient. For instance, to pay for an item ordered on-line using a check, a customer typically must (1) manually fill out the check; (2) sign the check; (3) place the check in an envelope; (4) seal the envelope; (5) address the envelope; (6) place proper postage on the envelope; and (7) mail the envelope. Often, a merchant will not ship a product until a check has been received and cleared, which may take in excess of a week if an out of state check is employed. Merchants also may expend considerable resources processing checks (e.g., resources of an Accounts Receivable Department that must manually deposit each check, verify that each check clears, credit a customer account based on each check, etc.). Accordingly, the use of checks to pay for on-line purchases is time consuming (e.g., due to the time required to fill out and mail a check, as well as the time required for a check to arrive and clear, and due to the time required to process a check) and costly (e.g., due to postage and paper check charges and check processing expenses).

In general, the time and cost requirements of paying by check are universal (e.g., are not limited to on-line purchases). Even customers that pay for purchases via a credit card typically re-pay their credit card company by check, and pay for other recurring expenses by check (e.g., utility bills, cable bills, rent payments, finance charges, etc.). Each payment by check requires the above-mentioned time and cost commitments.

Attempts have been made to "centralize" bill payments so as to reduce the number of checks that a customer writes each month (e.g., for recurring expenses such as utility bills, cable bills, rent payments, etc.). For example, centralized customer bill-paying services typically allow customers to send bills to a central location, so that the central service may pay each bill. In some instances the central service may use the customer's own checking account when paying each bill.

Centralized customer bill-paying services suffer from several drawbacks. Most centralized services target recurring expenses, and provide no assistance with on-line purchases. Further, many centralized services require lengthy registration and credit checking processes that may frustrate a customer and that may raise privacy concerns of the customer (e.g., by requiring the customer to send in voided checks as part of the registration process, by requiring the customer to provide credit references, by requiring the customer to provide personal information such as household income, etc.). Additionally, some customers prefer not to relinquish control over bill paying to a centralized service (e.g., out of fear of dishonest conduct or mistakes by the centralized service).

Accordingly, a need remains for improved methods and apparatus for employing checks.

SUMMARY OF THE INVENTION

To overcome the drawbacks of the prior art, novel methods and apparatus for employing checks are provided. In a first embodiment of the invention, a method for processing a payment is provided that includes receiving a first check for a first payment, the first check containing first payment account information that identifies a first account (e.g., receiving a first check mailed to a merchant by a customer for payment for an item purchased on-line by the customer). The method further includes requesting approval to charge the first account for a second payment (e.g., requesting the customer to authorize the merchant to charge the first account during a subsequent purchase by the customer).

In a second embodiment of the invention, a method for processing a payment is provided that includes (1) receiving a first check for a first payment, the first check containing first payment account information that identifies a first account; (2) outputting data based on the first check (e.g., a visual representation of the first check or of a second check that is based at least in part on the first check); and (3) requesting approval to charge the first account for a second payment.

In a third embodiment of the invention, a method for processing a payment is provided that includes (1) storing first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; (2) associating the first payment account information with a customer account (e.g., associating the first payment account information with an account that a customer has with a merchant); (3) outputting data based on the first check; and (4) requesting approval to charge the first account for a second payment.

Systems, apparatus and computer program products are provided for carrying out the above-described embodiments and numerous other embodiments of the present invention. Each computer program product described herein may be carried by a medium readable by a computer (e.g., a carrier wave signal, a floppy disc, a hard drive, a random access memory, etc.).

In one or more embodiments of the invention, an apparatus is provided for processing a payment. The apparatus includes means for storing first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment. The apparatus further includes means for requesting approval to charge the first account for a second payment. With these and other advantages and features of the invention that will become hereinafter apparent, the nature of the invention may be more clearly understood by reference to the following detailed description of the invention, to the appended claims and to the several drawings attached herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.

FIG. 1 is a schematic diagram of a novel system for processing a payment from a customer;

FIG. 2 is a schematic diagram of an exemplary embodiment of the controller of FIG. 1;

FIG. 3 illustrates a sample of the contents of the customer database of FIG.

2; FIG. 4 illustrates a sample of the contents of the transaction database of

FIG. 2;

FIG. 5 A illustrates a first sample of the contents of the received check database of FIG. 2;

FIG. 5B illustrates a second sample of the contents of the received check database of FIG. 2;

FIG. 6 illustrates a sample of the- contents of the created check database of FIG. 2; FIG. 7 is a flow chart of an exemplary process of the novel system of FIGS. 1-6 useful in describing the general operation of the novel system;

FIG. 8 illustrates an exemplary check that may be output by the controller of FIGS. 1-6; FIG. 9 illustrates an exemplary embodiment for the customer terminal of

FIG. 1;

FIG. 10 is a flow chart of a first exemplary process by which the controller of FIGS. 1-6 may process a payment; and

FIG. 11 is a flow chart of a second exemplary process by which the controller of FIGS. 1-6 may process a payment.

DETAILED DESCRIPTION OF THE INNENTION

Novel methods, apparatus, systems and computer program products are provided that allow a customer to make a first payment with a check and thereafter to authorize subsequent payments to an account identified by the check without the customer having to employ additional checks. For example, if a customer selects a first book from an on-line book store, and pays for the first book with a first check (e.g., by mailing the first check to the book store), in accordance with one or more embodiments of the invention, the book store may (1) obtain payment account information from the first check (e.g., a checking account number, routing data, etc.); and (2) store the payment account information (e.g., by associating the payment account information with a customer account of the customer).

If the customer wishes to purchase a second book during a subsequent online transaction with the on-line book store, the on-line book store may request the customer's authorization to charge the purchase price of the second book to the account identified by the stored payment account information obtained from the first check received by the on-line book store. The on-line book store, for example, may display a visual representation of the first check (or of a second check that is based on the first check) and may request that the customer "sign" the visual representation of the first/second check (e.g., via a computer mouse, via a trackball, via a stylus, or via some other computer input device). Once the customer has approved charging of the payment for the second book to the account identified by the stored payment account information, the on-line book store may "process" the payment (e.g., create a check based on the stored payment account information and process the check through a check clearing house, perform an electric, automated clearing house transaction, etc.). In this manner, a customer may purchase items over the Internet without having to provide credit card information, debit card information or other personal information. Because payment account information is obtained from a check used to pay for an item, a merchant rather than a customer performs any registration or set-up process required for the merchant to charge subsequent payments to a checking or other financial account of the customer (e.g., the customer need never send a voided check to the merchant or fill out any additional forms).

As will be described further below, embodiments of the invention may be employed with any merchant (e.g., whether or not the merchant is an on-line merchant) and may be used to pay for any item (e.g., a product, a service, a finance charge, etc.). Numerous other options also are provided.

Through use of one or more embodiments of the present invention, a customer who has previously made a first payment to a merchant using a check (e.g., a payment for a product, for a service or for a finance charge) may make a second payment (e.g., a check-based payment) to the merchant without having to mail or otherwise deliver another check to the merchant. For example, if a customer purchases an item from a merchant using a first check (e.g., by presenting the first check to the merchant, by mailing the first check to the merchant, etc.), through use of at least one embodiment of the invention, the merchant may retrieve and store payment account information from the first check. During a subsequent transaction with the customer (e.g., whether at a store of the merchant, whether during a telephone call, whether while the customer is on-line with the merchant, etc.), the customer may pay for another item by authorizing the merchant to charge an account identified by the payment account information retrieved from the first check. In this manner, a merchant may increase revenues from customers that (1) do not have credit cards, but that nonetheless wish to shop over the Internet; or (2) do not want to provide credit card information over the Internet, but that wish to shop over the Internet. In general, a merchant may increase customer loyalty, and thus increase revenues, by having payment account information (e.g., checking account information) stored for a customer (e.g., because the customer may easily and conveniently pay for items purchased from the merchant by merely authorizing the merchant to charge one or more payments to a checking account). Merchant costs also may be reduced as electronically collecting a payment is less expensive than processing a check and/or a pay stub.

In addition to merchant benefits, embodiments of the present invention provide numerous customer advantages. For example, through use of one or more embodiments of the invention, a customer need never send more than one check to a merchant, a customer need never mail a voided check to a merchant, and a customer need never perform a lengthy and/or cumbersome registration process for a merchant (e.g., a particularly painstaking experience when the customer shops with many different merchants). In at least one embodiment of the invention, a customer may shop or transact business over the Internet without the use of a credit card or a debit card, and without providing any account information. In other embodiments of the invention, a customer may enter a check number when the customer authorizes a charge to the customer's checking account. In this manner, the customer may easily enter/record each authorized checking account charge within the customer's checkbook; and may integrate both the conventional use of paper checks and the use of checks in accordance with the present invention within one checkbook so that neither approach disrupts the other

RELEVANT TERMINOLOGY As used herein, the term "check" refers to a bank check, a credit card check, a debit card check or any other conventional check. A check may be provided/received by providing/receiving the check itself, a copy of the check, an electronic version of the check (e.g., a scanned, electronic image of the check), a facsimile of the check, an e-mail version of the check, etc. Check information includes any information present on a check including, for example, checking account information, routing information, customer name information, customer address information, check number information, bank information, payee information, payment amount information, date information, memo information, etc. Payment account information may include check information and any other information that may be employed to identify an account.

A merchant may be any provider of a product or a service including but not limited to a retailer, a wholesaler, a manufacturer, a credit card company, a bank, a utility company, a cable company, a mortgage lender, a government entity, etc. An item may be a product, a service, a finance charge/interest payment, a tax payment, an installment payment or any other article/unit for which payment may be tendered.

EXEMPLARY EMBODIMENT OF THE INVENTIVE SYSTEM

FIG. 1 is a schematic diagram of a novel system 100 for processing a payment from a customer. The novel system 100 includes a customer terminal 102 in communication with a controller 104, and a retailer terminal 106 in communication with the controller 104. The novel system 100 also may include a customer bank 108 in communication with the customer terminal 102, and a retailer bank 110 in communication with the retailer terminal 106 and the customer bank 108. Although only one customer terminal and one retailer terminal are shown in FIG. 1, it will be understood that any number of customer and/or retailer terminals may be in communication with the controller 104. More than one controller, more than one customer bank and more than one retailer bank also may be employed.

The customer terminal 102 and the retailer terminal 106 each may comprise, for example, any device capable of communicating with the controller 104 such as a personal computer, a lap top computer, a mainframe computer, a personal digital assistant (PDA), a set top box, a facsimile machine, a pager or the like. The customer terminal 102 and the retailer terminal 106 each may be in communication with the controller 104 via a WEB-based connection, via a local area network (LAN), via a wide area network (WAN), via other forms of internet protocol (IP) networks (e.g., intranets or extranets), via a publicly switched telephone network (PSTN) or via any other known communications medium. In at least one embodiment of the invention, the controller 104 is operated by the retailer terminal 106, and the retailer terminal 106 may include a video terminal that is directly connected to the controller 104.

The customer bank 108 and the retailer bank 110 each may comprise any conventional financial institution capable of processing checks and/or electronic payments such as a bank, a credit card company, a debit card company, etc. The customer terminal 102 and the customer bank 108, the retailer terminal 106 and the retailer bank 110, and/or the customer bank 108 and the retailer bank 110 similarly may be in communication via a WEB-based connection, via a LAN, via a WAN, via any type of IP network, via a PSTN, via mail, via facsimile, via a financial clearing house network, etc.

As described further below, in one or more embodiments, the controller 104 may be a WEB server administered by a retailer, and the customer terminal 102 may be a computer of a customer that is in communication with the controller 104 (e.g., via a dial-up connection, via a DSL connection, via a TI connection, etc.). Through use of the customer terminal 102, the customer may browse a WEB site of the controller 104 and may perform on-line transactions (e.g., pay for items) in accordance with the present invention.

Those skilled in the art will understand that devices in communication with each other need only be "capable of communicating with each other and need not be continually transmitting data to or receiving data from each other. On the contrary, such devices need only transmit data to or receive data from each other as necessary, and may actually refrain from exchanging data most of the time. For example, a device in communication with another device via the Internet may not transmit data to the other device or receive data from the other device for weeks at a time. Further, devices may be in communication even though steps may be required to establish a communication link (e.g., dialing a network service provider).

For convenience the novel system 100 is described herein primarily with reference to a customer 112 that employs the customer terminal 102 and with reference to a retailer 114 that employs the retailer terminal 106. However, it will be understood that the customer 112 may represent one or more parties (e.g., one or more persons, businesses, government entities, etc., that are authorized to employ a customer account of the retailer 114) and that the retailer 114 may represent one or more retailers.

EXEMPLARY EMBODIMENTS OF THE CONTROLLER 104

FIG. 2 is a schematic diagram of an exemplary embodiment of the controller 104 of FIG. 1. The controller 104 may be implemented as a system controller, as a dedicated hardware circuit, as an appropriately programmed general purpose computer, or as any other equivalent electronic, mechanical or electro-mechanical device.

With reference to FIG. 2, the controller 104 comprises a processor 202, such as one or more conventional microprocessors (e.g., one or more Intel® Pentium® processors). The processor 202 is in communication with a communication port 204 through which the processor 202 communicates with other devices/parties (e.g., with the customer terminal 102, with other customer terminals (not shown), with the retailer terminal 106, with other retailer terminals (not shown), with the customer bank 108 and/or with the retailer bank 110). The communication port 204 may include multiple communication channels for simultaneous communication with, for example, the customer terminal 102, other customer terminals (not shown), the retailer terminal 106, other retailer terminals (not shown), the customer bank 108 and/or the retailer bank 110. As stated, devices in communication with each other need not be continually transmitting to each other. On the contrary, such devices need only transmit to each other as necessary, may actually refrain from exchanging data most of the time, and may require several steps to be performed to establish a communication link between the devices.

The processor 202 also is in communication with a data storage device 206. The data storage device 206 may comprise an appropriate combination of magnetic, optical and/or semiconductor memory, and may include, for example, Random Access Memory (RAM), Read-Only Memory (ROM), a compact disc and/or a hard disk. The processor 202 and the data storage device 206 each may be, for example, located entirely within a single computer or other computing device; or connected to each other by a communication medium, such as a serial port cable, a telephone line or a radio frequency transceiver. Alternatively, the controller 104 may comprise one or more computers that are connected to a remote server computer (not shown) for maintaining databases.

In an embodiment wherein the controller 104 is employed by (e.g., is operated by) a retailer (e.g., retailer 114 of FIG. 1), the data storage device 206 may store, for example, (i) a program 208 (e.g., computer program code and/or a computer program product) adapted to direct the processor 202 in accordance with the present invention, and particularly in accordance with the processes described in detail hereinafter with regard to the controller 104; (ii) a customer database 210 adapted to store information regarding customers of the retailer 114; (iii) a transaction database 212 adapted to store information regarding transactions of the retailer 114 (e.g., an identifier of a transaction, an identifier of a customer that participated in a transaction, an item purchased or sold during a transaction, etc., as described below); (iv) a received check database 214 adapted to store information regarding checks received by the retailer 114; and (v) a created check database 216 adapted to store information regarding checks created by the controller 104 and/or by the retailer 114. The controller 104 may be similarly configured for use by any merchant (e.g., a retailer, a wholesaler, a manufacturer, a utility company, etc.).

The program 208 may be stored in a compressed, an uncompiled and/or an encrypted format, and may include computer program code that allows the controller 104 to:

1. employ the communication port 204 to receive payment account information (e.g., check information such as a checking account number, routing data, etc.) obtained from a first check sent to the retailer 114 by the customer 112 for a first payment (e.g., for an item purchased by the customer 112);

2. store the payment account information in the received check database 214 of the data storage device 206;

3. employ the communication port 204 to output data to the customer 112 based on the first check (e.g., output a representation of the first check or a representation of a second check that is based on the first check to the customer 112); and

4. employ the communication port 204 to receive approval of the customer 112 to charge a second payment to an account identified by the payment account information stored in the received check database 214. The computer program code required to implement the above functions (and the other functions described herein) can be easily developed by a person of ordinary skill in the art, and is not described in detail herein. The controller 104 may include any peripheral devices (e.g., telephone keypads, handsets, headsets, microphones, speakers, keyboards, computer displays, etc.) required to implement the above functionality. The program 208 also may include program elements such as an operating system, a database management system and "device drivers" that allow the processor 202 to interface with computer peripheral devices (e.g., a video display, a keyboard, a mouse, etc.).

Note that instructions of the program 208 may be read into a main memory (not shown) of the processor 202 from a computer-readable medium other than the data storage device 206, such as from a ROM or from a RAM. While execution of sequences of instructions in the program 208 causes the processor 202 to perform the process steps described herein, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of the present invention. Thus, embodiments of the present invention are not limited to any specific combination of hardware and software. The processor 202 also may be in communication with a clock (not shown) that supplies time and date information to the processor 202 and that may comprise, for example, a clock internal to the processor 202, a clock external to the processor 202 or a clock embodied within the program 208 (e.g., based on a system clock not shown). Samples of the contents of the customer database 210, of the transaction database 212, of the received check database 214 and of the created check database 216 are shown in FIGS. 3-6, respectively. The specific data and fields illustrated in these figures represent only one embodiment of the records stored in the databases of the invention. The data and fields of these databases, as well as the number of databases, can be readily modified, for example, to include more or fewer data fields. A single database also may be employed. Note that in the databases of the controller 104, a different reference numeral is employed to identify each field of each database. However, in at least one embodiment of the invention, fields that are similarly named (e.g., customer identification fields, received check identification fields, etc., described below) store similar or the same data in a similar or in the same data format. The customer database 210 contains information related to customers of the retailer 114. FIG. 3 illustrates a sample of the contents of the customer database 210. As shown in FIG. 3, the customer database 210 contains customer information related to five customers identified in records 302-310, respectively. Specifically, for each customer of the retailer 114, the customer database 210 contains records having fields corresponding to, for example, (1) a customer identifier (ID) 312, used by the controller 104 to identify the customer; (2) a customer name 314; (3) an identifier of a first check received from the customer (first received check identifier 316); (4) an identifier of a second check received from the customer (second received check identifier 318); and (5) additional received check identifiers 320. Other customer information not shown in FIG. 3 which may be stored within the customer database 210 includes credit card information, debit card information, customer address information and any information relevant to the controller 104's operations. Note that the customer database 210 (and the transaction database 212, the received check database 214 and the created check database 216) may be populated with data provided to the controller 104 via the communication port 204, and that the data may be provided to the controller 104 from the customer terminal 102 (e.g., during an on-line transaction with the customer 112), directly from the customer 112 (e.g., during a telephone order, based on a completed mailed order form, etc.), from the retailer terminal 106, directly from the retailer 114, from other customers or retailers and/or from any other source. With reference to the customer database 210 of FIG. 3, the record 302 illustrates exemplary data for a customer C- 123456 (customer identifier 312) named Jeremiah Buckley (customer name 314) that has submitted three checks (identified by received check identifiers RC-2000777, RC-4911208 and RC- 9999999 in fields 316-320) to the retailer 114. As will be described further below, in at least one embodiment of the invention, payment account information is stored by the controller 104 for each check received by the retailer 114 from a customer if the received check contains payment account information that is different from payment account information previously stored for the customer (e.g., different routing data, a different checking account number, etc.). As can be seen with reference to the exemplary record 302, Jeremiah Buckley has provided the retailer 114 with three checks each having different payment account information.

The transaction database 212 contains information related to transactions of the retailer 114 (e.g., purchases by customers identified in the customer database 210). FIG. 4 illustrates a sample of the contents of the transaction database 212. As shown in FIG. 4, the transaction database 212 contains transaction information related to nine transactions identified in records 402-418, respectively. Specifically, for each transaction of the retailer 114, the transaction database 212 contains records having fields corresponding to, for example, (1) a transaction identifier (ID) 420 that identifies the transaction of the retailer 114; (2) an item identifier 422 that identifies an item (or items) purchased by a customer during the transaction; (3) a customer identifier 424 that identifies a customer that participated in the transaction with the retailer 114; (4) a received check identifier 426 that identifies a check that was received by the retailer 114 for payment for any items purchased during the transaction (if applicable); and (5) payment account information 428 that identifies an account to which the retailer 114 charged payment for any items purchased during the transaction (if applicable). Other transaction information not shown in FIG. 4 which may be stored within the transaction database 212 includes, for example, the date and/or the time of each transaction, other payment information such as credit card information or debit card information (if an item was paid for with a credit card or with a debit card), past transactions of a customer, etc. With reference to the transaction database 212 of FIG. 4, the record 412 illustrates exemplary data for a transaction T-8765432 (transaction identifier 420) that involves the purchase of an item P-0001 (item identifier 422) by a customer C- 987654 (customer identifier 424). As shown in the record 412, the customer C- 987654 paid for the item P-0001 with a check identified by received check identifier RC-8211814 (received check identifier 426). Payment account information from the customer C-987654's check (RC-8211814) has been stored by the controller 104 in the received check database 214 (as described below with reference to FIGS. 5A and 5B) and may be used during subsequent transactions with the customer C-987654. For example, the record 414 illustrates exemplary data for a transaction T-8765498 that involves a subsequent purchase of an item P- 1582 by the customer C-987654. As shown in the record 414, the customer C- 987654 paid for the item P-1582 by authorizing the controller 104 (or the retailer 114) to charge the payment for the item to a checking account identified by the payment account information 767676767-676767 (payment account information 428) associated with the customer C-987654. In this example, the payment account information 428 represents routing data (e.g., automated clearing house (ACH) data) obtained from the check submitted to the retailer 114 by the customer C-987654 (e.g., the check identified by received check identifier RC-8211814 that was for payment for the item P-0001).

The received check database 214 contains information related to checks received by the retailer 114. FIG. 5 A illustrates a first sample of the contents of the received check database 214. As shown in FIG. 5 A, the received check database 214 contains information for seven checks received by the retailer 114. The seven checks are identified in records 502-514, respectively. Specifically, for each check received by the retailer 114, the received check database 214 contains records having fields corresponding to, for example, (1) a received check identifier 516 that identifies the check received by the retailer 114; (2) a customer identifier 518 that identifies a customer associated with the check received by the retailer 114 (e.g., a customer that mailed the check to the retailer 114); (3) a payee name 520 that identifies the payee specified on the check received by the retailer 114; (4) a payment amount 522 that identifies the amount specified on the check received by the retailer 114; (5) routing data 524 that identifies the ACH number (or other routing data) specified on the check received by the retailer 114; and (6) a check number 526 that identifies a check number specified on the check received by the retailer 114. Any other information may be captured from a check received by the retailer 114 and may be stored within the received check database 214 (e.g., customer name information, customer address information, the name of the customer's bank or financial institution, etc.).

As will be described below with reference to FIGS. 7-11, the controller 104 may employ the information stored within the received check database 214 to create a visual representation of each check received by the retailer 114. For example, a visual representation of a check (previously submitted to the retailer 114 by a customer) may be displayed to the customer when the controller 104 requests authorization from the customer to charge payment for an item to an account identified by the check (as described below). Alternatively, or additionally, the controller 104 may provide (e.g., display, verbally communicate, etc.) only a portion of the information stored for each check to the customer, such as the check number, the routing data, etc. Note that while the databases of the present information have been and will continue to be described primarily with reference to information obtained from checks sent to the retailer 114, it will be understood that the controller 104 may be operated by an entity separate from the retailer 114 that receives checks on behalf of the retailer 114 and that provides payment account information and other relevant information to the controller 104.

In embodiments of the invention wherein the controller 104 displays a visual representation of a received check to a customer (as described below), the received check database 214 may store an image of each check received by the retailer 114 (e.g., a scanned image stored as a JPG or TIF file) rather than information obtained from each check. For example, FIG. 5B illustrates a second sample of the contents of the received check database 214 wherein an image file is stored for each check received by the retailer 114 (e.g., in an image file of check field 528) rather than payee, amount, routing data and check number information. Specifically, each record 502-514 of the received check database of 214 of FIG. 5B has an image file of check field 528 rather than the payee field 520, the payment amount field 522, the routing data field 524 and the check number field 526 of the received check database 214 of FIG. 5 A. The remainder of the fields in each database record of the received check database 214 of FIG. 5B are identical to those of the received check database 214 of FIG. 5 A. The created check database 216 contains information related to checks created at least in part by the controller 104 (or by the retailer 114). FIG. 6 illustrates a sample of the contents of the created check database 216. As shown in FIG. 6, the created check database 216 contains information for two checks identified by record 602 and record 604, respectively. Specifically, for each check created by the controller 104 (or by the retailer 114), the created check database 216 contains records having fields corresponding to, for example, (1) a created check identifier 606 that identifies the controller/retailer created check; (2) a customer identifier 608 that identifies the customer for which the check was created; (3) a payee name that identifies the payee specified on the created check; (4) a payment amount 612 that identifies the amount specified on created check; (5) routing data 614 that identifies the ACH number (or other routing data) specified on the created check; and (6) a check number 616 that identifies a check number specified on the created check. Any other relevant information may be stored in the created check database 216 such as customer name information, customer address information, customer financial institution information, etc.).

EXEMPLARY OPERATION OF THE NOVEL SYSTEM 100

FIG. 7 is a flow chart of an exemplary process 700 of the novel system 100 of FIGS. 1-6 useful in describing the general operation of the novel system 100. In the exemplary process 700, the operation of the novel system 100 is described with reference to the customer terminal 102 and the retailer terminal 106. It will be understood that a similar process may be performed using any other customer terminal, using multiple customer terminals, using any other retailer terminal and/or using multiple retailer terminals. The specific operation of the controller 104 is described below with reference to FIGS. 10-11.

With reference to FIG. 7, in step 702 the process 700 begins. In step 704, the retailer 114 receives a first check from the customer 112 for payment for a first item. The item may be, for example, a product, a service, a finance charge or an interest payment, a tax payment, an installment payment or any other article/unit for which payment may be tendered. For example, the controller 104 may be a WEB server that operates a WEB site for the retailer 114 (or that operates a WEB site that is "linked" to a WEB site operated by the retailer 114), and the customer 112 may employ the customer terminal 102 to browse the retailer 114's WEB site and purchase an item on-line. The first check received from the customer 112 thus may represent payment for an item purchased on-line by the customer 112. Alternatively, the payment may be for an item ordered via a telephone, via an e- mail, via facsimile, via mail, or via any other mechanism, or the payment may be for an item purchased in a "bricks and mortar" store or in an outlet of the retailer 114.

The first check may be delivered to the retailer 114 by any delivery method. For example, the first check may be handed to a store clerk of the retailer 114 or sent to the retailer 114 via mail, via e-mail (e.g., if the check is scanned or already exists in electronic form), via any other network (e.g., a LAN, a WAN, an intranet, an extranet, etc.), via facsimile, etc. The first check may take any form (e.g., a "paper" check, an electronic check, etc.). In at least one embodiment of the invention, the retailer 114 need only be provided certain information from the first check (e.g., routing data, customer address information, checking account number or any other relevant check information).

In step 706 the controller 104 stores payment account information from the first check (e.g., payment account information "captured" from the check by the retailer 114). For example, the retailer 114 may (1) scan the check and provide an image of the check to the controller 104 for storage within the received check database 214 of FIG. 5B (in which case the payment account information comprises an image of the check); (2) employ optical character recognition software to identify relevant check information on the check (e.g., customer name and/or address information, payee name information, payment amount information, routing data, check number information, etc.) and provide the check information to the controller 104 for storage within the received check database 214 of FIG. 5 A (in which case the payment account information comprises check information); and/or (3) manually examine the check and/or manually provide check information to the controller 104 for storage within the received check database 214 of FIG. 5A (in which case the payment account information comprises check information). Note that if the controller 104 is a "third party service" that processes payments for the retailer 114 (and possibly for other retailers), the controller 104 may perform any or all of the above functions. For example, if the customer 112 presents the first check to a clerk at a store of the retailer 114, payment account information may be captured from the check by (1) capturing an image of the check and/or check information at the store; (2) forwarding the check to a central location (e.g., either a location of the retailer 114 or of the controller 104) and capturing an image of the check and/or check information at the central location; and/or (3) capturing an image of the check and/or check information at multiple locations. The captured payment account information may be stored with other forms of payment account information such as credit card information, debit card information, etc. Either before, during or after the controller 104 has stored the payment account information, in step 708 the controller 104 associates the payment account information with a customer account of the customer 112. For example, as shown in FIG. 5 A, check information such as payee name, payment amount, routing data and check number is associated with a customer account by associating the check information with a customer identifier 518 (e.g., the check information and the customer identifier are stored in the same record). Any other data formatting techniques or schemes may be employed to associate (e.g., link) check information with a customer identifier/account. As used herein, a "customer account" may simply comprise an identifier for a customer, or may comprise additional information (e.g., customer name information, customer mailing address information, customer billing address information, etc.). The payment account information also may be associated with a customer account in any other database or storage medium.

Note that at any time before, during or after the process 700, the retailer 114 may process the first payment by any conventional check handling process. For example, during an exemplary check handling process, the following steps are performed: (1) the retailer 114 delivers (e.g., physically or electronically via the retailer terminal 106) the first check to the retailer bank 110; (2) the retailer bank 110 sends the first check to a Federal Reserve Bank; (3) the Federal Reserve Bank increases a Reserve account of the retailer bank 110 by the amount of the first check; (4) the Federal Reserve Bank decreases a Reserve account of the customer bank 108 by the amount of the first check; (5) the retailer bank 110 increases a bank account of the retailer 114 by the amount of the first check; and (6) the customer bank 108 decreases a bank account of the customer 112 by the amount of the first check. Any other means for handling the first check may be employed, such as via direct communication of check information between the retailer bank 110 and the customer bank 108.

In step 710, the controller 104 receives a request from the customer 112 (or any authorized user of the customer 112's customer account, collectively referred to herein as "the customer 112") to pay for a second item. The second item may be a product, a service, a finance charge, etc., or may be the same item as the first item (e.g., if the customer 112 merely wishes to make an additional payment for the first item).

In step 712, data based on the first check received from the customer 112 is output by the controller 104 to the customer terminal 102, and in step 714, the controller 104 requests approval of the customer 112 to charge payment for the second item to an account identified by the first check received from the customer 112 (step 704). Step 712 and step 714 may be performed in any order or may be performed simultaneously.

The data output by the controller 104 (step 712) may comprise any data that identifies the account such as, for example, (1) a visual representation of the first check (e.g., a scanned image of the first check stored within the received check database 214 of FIG. 5B, a recreated image of the first check based on check information obtained from the first check using optical character recognition software and stored within the received check database 214 of FIG. 5 A, a recreated image of the first check based on check information manually retrieved from the first check and stored within the received check database 214 of FIG. 5A, etc.); (2) a portion of the check information captured from the first check and stored in the received check database 214 of FIG. 5 A (e.g., sufficient information to allow the customer 112 to identify the account); and/or (3) a visual representation of a second check that is based on the first check (e.g., a second check having the same account number and/or routing data as the first check and that may have a similar look to the first check received from the customer 112). FIG. 8 illustrates an exemplary check 800 that may be output by the controller 104 to the customer terminal 102. As shown in FIG. 8, the check 800 contains a customer name and address field 802, a customer bank name field 804, a date field 806, a first check number field 808, a payee field 810, an amount field 812, a memo field 814, a signature field 816, a routing data field 818, a checking account number field 820 and a second check number field 822. Any other check information also may be present on the check 800.

If the check 800 represents a "second check" (rather than an image of the first check), the controller 104 may automatically fill in any of the fields 802-822. For example, in at least one embodiment of the invention, in step 712 the controller 104 may:

1. generate the second check 800 based on the first check received by the retailer 114 from the customer 112; 2. fill in the customer name and address field 802 of the second check 800 based on the information stored in the customer database 210;

3. fill in the customer bank name field 804, the routing data field 818 and the checking account number field 810 of the second check 800 based on the information stored in the received check database 214;

4. fill in the date field 806 of the second check 800 based on the date that the customer 112 wishes to make the second payment;

5. prompt the customer 112 to provide a check number for the second check 800 (e.g., to allow the customer 112 to record the transaction in a checkbook) or generate a check number and fill in the first check number field 808 and the second check number field 822 of the second check 800 based on the check number;

6. fill in the payee field 810 of the second check 800 based on the name of the retailer 114;

7. fill in the amount field 812 of the second check 800 based on the payment amount for the second item (or prompt the customer 112 to specify a payment amount); and/or

8. fill in the memo field 814 of the second check 800 based on the item being paid for.

Thereafter, in step 714, the controller 104 may request approval of the customer 112 to charge payment for the second item to the account identified by the check 800 by requesting the customer 112 to sign the check 800 (e.g., using any computer input device such as a computer mouse, a trackball or a stylus). FIG. 9 illustrates an exemplary embodiment for the customer terminal 102 wherein a computer monitor 902 of the customer terminal 102 displays the check 800 and wherein the customer 112 may employ a computer mouse 904 to sign the check 800 (as illustrated by arrow/cursor 906). Note that if a visual representation of the first check is displayed on the computer monitor 902, the customer 112 may be requested to "re-sign" the first check.

The customer 112 also may approve the request to charge payment for the second item to the account identified by the check 800 by employing a keyboard 908 of the customer terminal 102 (e.g., to provide a password), or by an other means (e.g., via telephone, via facsimile, via e-mail, via a cryptographic or biometric signature, etc.).

After receiving the customer 112's approval (step 714) to charge the payment for the second item to an account identified by payment account information obtained from the first check (steps 704-708), in step 716 the controller 104 processes the payment for the second item. For example, the controller 104 may generate a "paper" check based on the first check (e.g., by printing the above-described second check signed by the customer 112, by creating a new check, etc.) and may process the paper check as if the check was received from the customer 112 (e.g., by processing the paper check through a conventional check clearing house). In this manner, the customer 112 may receive the paper check with the customer 112's next checking account statement (in addition to any "conventional" paper checks generated by the customer 112 that the customer 112 may receive with the checking account statement). Alternatively, the controller

104 may process the payment as an electronic check transaction (e.g., via a debit of the customer 112's checking account or via some other electronic clearing house transaction).

In step 718, the process 700 ends. Numerous alternative processes may be performed by the novel system 100 as described further below with reference to FIGS. 10 and 11.

FIRST EXEMPLARY PROCESS OF THE CONTROLLER 104 FIG. 10 is a flow chart of a first exemplary process 1000 by which the controller 104 may process a payment from the customer 112. The process 1000 and the other processes described below with reference to the controller 104 may be embodied within computer program code of the program 208 and may each comprise a computer program product. With reference to FIG. 10, the process 1000 begins in step 1002. In step

1004, the controller 104 receives and stores payment account information within the received check database 214 (e.g., an image of a check received from the customer 112, check information received from the customer 112, etc). As stated, the payment account information may be obtained from a first check received by the retailer 114 from the customer 112 for payment for a first item; and the payment account information identifies an account (e.g., a checking account or some other payment account) against which the first check was/is drawn. The controller 104 (or the retailer 114) may verify that the payment account information obtained from the first check has not previously been stored by the controller 104 (e.g., to verify that the customer 112 has not already submitted a check from the same checking/payment account). For example, the controller 104 may query the received check database 214 to determine if the payment account information obtained from the first check has been previously stored. In one or more embodiments of the invention, the controller 104 may store payment account information for multiple accounts (e.g., if the customer 112 makes payments using checks issued from different financial institutions or from multiple accounts with the same financial institution as described below with reference to FIG. 11). In step 1006, the controller 104 associates the payment account information with a customer account of the customer 112. Steps 1004 and 1006 may be performed in any order, or may be performed simultaneously. In step 1008, the controller 104 (or the retailer 114) receives a request from the customer 112 to purchase a second item. For example, the request may be received from the customer 112 while the customer 112 browses a WEB site operated by the retailer 114 (and/or a WEB site operated by the controller 104 on behalf of the retailer 114), while the customer 112 is shopping at a store or an outlet of the retailer 114, based on a telephone or mail order, etc. In general, the customer 112 may purchase the second item from the same retailer that provided the first item (retailer 114), or the second item may be purchased from a different retailer (e.g., another retailer that has access to the controller 104 or that otherwise shares customer information with the retailer 114). The second item may be the same type of item as the first item (e.g., as identified by a SKU number, by a UPC number or by some other identifier), or may be a different type of item. In response to the request to purchase the second item, in step 1010 the controller 104 outputs data based on the first check received from the customer 112 for the first item, and in step 1012, the controller 104 requests approval of the customer 112 to charge payment for the second item to an account identified by the previously stored payment account information (step 1004). The data output by the controller 104 may be, for example, a visual representation of the first check received from the customer 112, various check information (e.g., routing data, a checking account number, etc.) obtained from the first check or a visual representation of a second check as previously described.

Requesting the customer 112 to approve charging of the purchase price of the second item may include, for example, directing the customer 112 to a WEB site of the retailer 114 (e.g., and requesting the customer 112 to perform some action while at the WEB site such as requesting the customer 112 to check a "checkbox" that authorizes the controller 104 to automatically charge payments to an account identified by the previously stored payment account information), sending an e-mail to the customer 112 (e.g., and requesting a response to the e- mail), requesting a signature of the customer 112 (e.g., via a computer input device, via stylus of a PDA, etc.), by calling or by requesting the customer 112 to call the controller 104 or the retailer 114, etc.

In at least one embodiment of the invention, the customer 112 may specify an amount that the customer 112 wants to charge to an account identified by the previously stored payment account information (obtained from the first check). For example, the customer 112 may wish to charge a portion of a payment for the second item to a checking account identified by the first check and a portion of the payment for the second item to a credit card account. In embodiments wherein the controller 104 generates a "paper" check for payment for the second item, the controller 104 may request that the customer 112 provide a check number for the paper check (e.g., so that the customer 112 may easily record the second payment within the customer 112's checkbook). Likewise, checks generated by the controller 104 (e.g., checks generated while a customer is "on-line" with the controller 104 if the controller 104 is a WEB server) may be given a different numbering scheme than the checks written by the customer 112 (e.g., so that the customer 112 need not throw away any checks from the customer 112's checkbook). For example, the check numbers of checks generated by the controller 104 during on-line transactions may end with the letters "OL" (e.g., to differentiate these on-line checks from paper checks written from the customer 112's checkbook).

In step 1014, the controller 104 receives the customer 112's approval to charge the purchase price of the second item to an account identified by the previously stored payment account information obtained from the first check (step 1004). In step 1016, the controller 104 processes the payment for the second item (e.g., by creating a paper check conforming to ACH standards or via any of the other previously described means). Note that the retailer 114 rather than the controller 104 may process the second payment.

As stated, in at least one embodiment, the controller 104 may communicate with the customer 112 via a WEB-based interface (e.g., to output data based on checks received from the customer 112, to request approval to charge payments to one or more accounts, etc.). For example, the controller 104 may send a first HTTP transmission to the customer terminal 102 to request approval to charge a payment for a second item to an account identified by payment account information previously obtained from a check submitted to the retailer 114 by the customer 112 (e.g., an HTTP transmission that represents alphanumeric characters that identify the checking account to which the controller 104 wishes to charge a payment, an HTTP transmission that represents an image of a previously submitted check, etc.). HTTP transmissions are known in the art, and may comprise, for example, transmissions via post commands. The customer terminal 102 may receive the first HTTP transmission and display contents of the HTTP transmission (e.g., on the computer monitor 902 of FIG. 9). In response to the first HTTP transmission, the customer 112 may employ the customer terminal 102 to send a second HTTP transmission to the controller 104 (e.g., an HTTP transmission that represents alphanumeric characters, such as a password, that indicate the customer 112's approval to charge the second payment, an HTTP transmission that represents an image of a signature of the customer 112 or of a signed check, etc.). As an example of the operation of the controller 104, assume that the customer 112 wishes to purchase a red sweater from a company named LOTS-A- SWEATERS, Inc. The customer 112 logs onto a WEB site of LOTS-A- SWEATERS, Inc. (having a URL address ofwww.lotsasweaters.com), and orders the red sweater from the WEB site. To pay for the red sweater, the customer 112 mails a check to LOTS-A-SWEATERS, Inc. In accordance with one or more embodiments of the invention, LOTS-A-SWEATERS, Inc. employs the controller 104 to store payment account information from the check received from the customer 112 (e.g., an image of the check in the received check database 214), and mails the red sweater to the customer 112. A few weeks later, the customer 112 logs back onto www.lotsasweaters.com and places an order for a blue sweater. Because the controller 104 has stored payment account information for the customer 112, the controller 104 outputs an image of the check previously received from the customer 112 for payment for the red sweater, an image of a new check (e.g., a check having a payee field that reads LOTS-A-SWEATERS, Inc. and the amount field filled out with the proper cost of the blue sweater plus any applicable tax and shipping charges) and the message:

Is this the same checking account that you would like us to charge for payment for the blue sweater? Please consult your checkbook to verify the checking account number. If the information is correct, simply approve the payment amount, specify a check number and sign the signature area of the new check using your mouse. For your own records, please record the check number you specified.

After the customer 112 has signed the new check, the controller 104 (or the retailer 114) may create a paper check based on the signed check and may process the paper check through a check clearing house. As a result, the customer 112 will receive a copy of the paper check in the customer 112's next monthly bank statement. Alternatively, the customer 112 may pay for the red sweater (with a check) at an outlet operated by LOTS-A-SWEATERS, Inc., a salesperson at the outlet may capture and store payment account information from the check, and the customer 112 then may visit lotsasweaters.com to purchase the blue sweater (e.g., and pay for the blue sweater by authorizing the controller 104 to charge an account identified by the stored payment account information). In general, payment account information may be captured and stored by the controller 104 and/or by any merchant (e.g., whether for on-line purchases, whether for telephone purchases, whether for purchases at a store/outlet, etc.), and stored payment account information may be employed to charge payment for any item regardless of where the item is purchased (e.g., whether purchased on-line, whether purchased via a telephone call, whether purchased at a store/outlet, etc.). Note that the customer 112 may be given the option to decline the charging of a payment to an account identified by stored payment account information (e.g., and given the option to make the payment with another paper check or by any other means).

SECOND EXEMPLARY PROCESS OF THE CONTROLLER 104

FIG. 11 is a flow chart of a second exemplary process 1100 by which the controller 104 may process a payment from the customer 112. The process 1100 begins in step 1102. In step 1104, the controller 104 stores first payment account information within the received check database 214 (e.g., an image of a first check received from the customer 112, check information received from the customer 112, etc). The first payment account information may be obtained from a first check received from the customer 112 for payment for a first item; and the first payment account information identifies a first account (e.g., a first checking account) against which the first check is drawn. In step 1106, the controller 104 associates the stored, first payment account information with a customer account of the customer 112. Steps 1104 and 1106 may be performed in any order, or may be performed simultaneously.

In step 1108, the controller 104 stores second payment account information within the received check database 214 (e.g., an image of a second check received from the customer 112, check information received from the customer 112, etc). The second payment account information may be obtained from a second check received from the customer 112 for payment for a second item (e.g., a second item purchased by the customer 112 from the retailer 114 using a different checking account than was employed to pay for the first item); and the second payment account information identifies a second account (e.g., a second checking account that is different than the previously identified, first checking account) against which the second check is drawn. In step 1110, the controller 104 associates the stored, second payment account information with the customer account of the customer 112. Steps 1108 and 1110 may be performed in any order, or may be performed simultaneously. In step 1112, the controller 104 (or the retailer 114) receives a request from the customer 112 to purchase a third item. In response to the request to purchase the third item, in step 1114 the controller 104 outputs data based on the first check received from the customer 112 for the first item and data based on the second check received from the customer 112 for the second item; and in step 1116, the controller 104 requests that the customer 112 select one of the first account (identified from the first payment account information obtained from the first check received from the customer 112 (step 1104)) and the second account (identified from the second payment account information obtained from the second check received from the customer 112 (step 1108)) to which to charge payment for the third item. For example, the controller 104 may display a visual representation of the first check and/or of the second check, may provide the customer 112 with check information based on the first check and/or the second check, or may provide the customer 112 with any other information that may identify the first and the second accounts to the customer 112. The data output by the controller 104 also may include a visual representation of a third check (based on either the first check or the second check). The customer 112 may be requested to sign any visual representation of a check.

In step 1118, based on the customer 112's selection of an account (step 1116), the controller 104 (or the retailer 114) processes the payment for the third item (e.g., by creating a paper check conforming to ACH standards or via any of the other previously described means so as to charge the selected account for payment for the third item). In step 1120 the process 1100 ends.

The foregoing description discloses only exemplary embodiments of the invention, modifications of the above disclosed apparatus and method which fall within the scope of the invention will be readily apparent to those of ordinary skill in the art. For instance, the items paid for by the customer 112 in accordance with one or more embodiments of the invention may comprise finance charges, utility service charges, cable charges, taxes or any other charges, and the controller 104 may automatically prompt the customer 112 to authorize payments (e.g., with periodic account balance statements). For example, if a customer 112 pays for an electric bill with a check made out to a local utility company (e.g., by mailing the check or presenting the check in person), the utility company may employ embodiments of the invention to store payment account information from the check. Thereafter, the utility company may include, for example, an authorization box, an authorization form or some other authorization request on the customer 112's next monthly electric bill that requests that the customer 112 authorize the utility company to charge payment for the electric bill to an account identified by the payment account information stored by the utility company (e.g., to charge the checking account against which the original check sent to the utility company was written). The authorization request may include a new check created by the utility company that merely requires the customer 112's signature (e.g., the customer 112's signature may by the requested authorization). The customer 112 may authorize the payment by mailing back an authorization form/stub, by calling the utility company, by e-mailing the utility company, by visiting a WEB site of the utility company, etc. The items paid for by the customer 112 in accordance with one or more embodiments of the invention may be the same item (e.g., a plurality of payments toward a credit card balance). Further, the controller 104 may request that the customer 112 specify a payment amount to be charged to a financial account (e.g., how much of a credit card balance should be paid). As an additional example, assume the customer 112 purchases a tape recorder for $100 using a credit card from Credit Card Company B, Inc ("CCCB, Inc."). The customer 112 receives a credit card statement from CCCB, Inc., and mails a check for $100 to CCCB, Inc. in payment of the customer 112's credit card balance. Thereafter, the customer 112 purchases a compact disc for $20 by using the credit card from CCCB, Inc. A month later, the customer 112 receives a credit card statement from CCCB, Inc. that requests the customer 112's approval for CCCB, Inc. to withdraw $20 from a checking account identified by the check previously mailed to CCCB, Inc. from the customer 112 (e.g., the check for $100). If the customer 112 approves the $20 withdrawal, CCCB, Inc. may process the payment of the $20 as an electronic check transaction (or by any other means known in the art). The controller 104 also may verify that a financial account has sufficient funds prior to charging a payment to the account. With reference to the customer 112 of FIG. 1, for example, the controller 104 may verify that an account of the customer 112 has sufficient funds via one or more communications with the customer bank 108 (e.g., via e-mail, via a telephone call, via facsimile, etc.). In addition to withdrawing funds from an account, embodiments of the present invention may be employed to deposit funds into, an account identified by a check received from the customer 112. For example, if in the above scenario, a credit for $15 is posted to the customer 112's credit card account after CCCB, Inc. has withdrawn $20 from the customer 112's checking account, CCCB, Inc. may choose to credit $15 to the customer 112's checking account (e.g., using payment account information previously obtained from the $100 check received from the customer 112). A merchant also may choose to deposit funds into an account identified by a check received from a customer if the customer wins a sweepstakes, a lottery and/or a game of skill sponsored by the merchant (e.g., an on-line lottery or sweepstakes that the customer is automatically entered in if the customer visits a WEB site of the merchant and/or purchases a product from the merchant, a game of skill that the customer may play while the customer browses a WEB site of the merchant, etc.). The controller 104 may form part of a centralized bill-paying service to which each customer of the service need only send one check (e.g., a check for payment of the fee that the bill paying service charges for its services). Thereafter, all payments that the centralized bill-paying service makes on behalf of a customer may be based on payment account information from the one check that was received from the customer. The centralized bill-paying service also may request authorization for each bill paid by the service (e.g., via mail, via e-mail, via facsimile, etc.), and may generate a "paper" check for each bill to be paid and may send each paper check to a customer for signature. Other centralized sites may be employed that allow a customer to write and/or sign checks while on-line in accordance with embodiments of the invention. For example, a central site may be a person-to-person marketplace that not only brokers transactions between parties, but facilitates payments between parties using on-line checks. In at least one embodiment, two merchants may share payment account information of a customer (e.g., if the customer consents to the sharing of information). For example, a first merchant that is participating in a transaction with a customer may communicate with a second merchant, and may receive payment account information from the second merchant (e.g., payment account information obtained from a check mailed to the second merchant by the customer), and may request approval of the customer to charge payment for the transaction to an account identified by the payment account information received from the second merchant. Likewise, a customer service representative (e.g., from a bank) may store payment account information for a customer and may share the payment account information with one or more merchants.

Rather than having the customer "sign" a visual representation of a check (e.g., via a computer mouse, via a trackball, via a stylus, or via some other computer input device), a biometric reader (e.g., a thumb print reader, a retinal scanner, etc.) may be employed to verify the identity of the customer. Likewise, the customer may be requested to enter a password in order to authorize the controller 104 to charge a payment to an account of the customer, or the customer may be requested to enter a password in order to view any payment account information of the customer (e.g., payment account information such as an account number, routing data, an image of a check, etc.). Any other techniques may be similarly employed to prevent unauthorized users from accessing the customer's personal/financial information.

Accordingly, while the present invention has been disclosed in connection with the exemplary embodiments thereof, it should be understood that other embodiments may fall within the spirit and scope of the invention as defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method for processing a payment comprising: receiving a first check for a first payment, the first check containing first payment account information that identifies a first account; and requesting approval to charge the first account for a second payment.

2. The method of claim 1 wherein receiving the first check comprises receiving the first check via mail.

3. The method of claim 1 wherein receiving the first check comprises receiving the first check via e-mail.

4. The method of claim 1 wherein receiving the first check comprises receiving the first check via facsimile.

5. The method of claim 1 wherein receiving the first check is performed by a first merchant and wherein requesting approval to charge the first account is performed by the first merchant.

6. The method of claim 1 wherein receiving the first check is performed by a first merchant and wherein requesting approval to charge the first account is performed by a second merchant.

7. The method of claim 1 wherein the first payment is for a first item.

8. The method of claim 7 wherein the first item comprises at least one of a product, a service and a finance charge.

9. The method of claim 7 wherein the second payment is for a second item.

10. The method of claim 7 wherein the second payment is for the first item.

11. The method of claim 1 wherein the first payment account information comprises routing data.

12. The method of claim 11 wherein the routing data comprises automated clearing house data.

13. The method of claim 1 further comprising storing the first payment account information.

14. The method of claim 13 wherein storing the first payment account information comprises storing the first payment account information in a database.

15. The method of claim 13 wherein storing the first payment account information comprises capturing the first payment account information from the first check.

16. The method of claim 15 wherein capturing the first payment account information from the first check comprises scanning at least a portion of the first check.

17. The method of claim 15 wherein capturing the first payment account information from the first check comprises entering the first payment account information via at least one of a keyboard and a keypad.

18. The method of claim 13 further comprising associating the first payment account information with a customer account.

19. The method of claim 18 wherein requesting approval to charge the first account for the second payment comprises: receiving a request to purchase an item, the request being received from a user of the customer account; and requesting approval to charge the first account for the second payment for the item in response to receiving the request to purchase the item.

20. The method of claim 18 further comprising: receiving a second check for the second payment, the second check containing second payment account information that identifies a second account; storing the second payment account information; and associating the second payment account information with the customer account.

21. The method of claim 20 further comprising requesting approval to charge at least one of the first account and the second account for a third payment.

22. The method of claim 21 wherein requesting approval to charge at least one of the first account and the second account for the third payment comprises: displaying at least a first identifier of the first account; displaying at least a second identifier of the second account; and requesting selection of one of the first and the second accounts.

23. The method of claim 20 further comprising outputting data based on the second check prior to requesting approval.

24. The method of claim 1 further comprising outputting data based on the first check prior to requesting approval.

25. The method of claim 24 wherein outputting data based on the first check comprises outputting a visual representation of the first check.

26. The method of claim 24 wherein outputting data based on the first check comprises outputting at least a portion of the first payment account information.

27. The method of claim 24 wherein outputting data based on the first check comprises outputting a visual representation of a second check.

28. The method of claim 27 further comprising completing at least an amount field of the second check based on the second payment.

29. The method of claim 27 wherein requesting approval to charge the first account for the second payment comprises requesting a party to sign the visual representation of the second check.

30. The method of claim 29 wherein requesting the party to sign the visual representation of the second check comprises mailing the second check to the party.

31. The method of claim 29 wherein requesting the party to sign the visual representation of the second check comprises e-mailing the second check to the party.

32. The method of claim 29 wherein requesting the party to sign the visual representation of the second check comprises requesting the party to sign the second check using a computer input device.

33. The method of claim 32 wherein the computer input device comprises at least one of a computer mouse, a trackball and a stylus.

34. The method of claim 27 further comprising requesting a party to specify a check number for the second check.

35. The method of claim 1 further comprising requesting a party to specify a check number for the second payment.

36. The method of claim 1 further comprising charging the first account for the second payment.

37. The method of claim 36 wherein charging the first account comprises creating a paper check based on the first payment account information.

38. The method of claim 37 further comprising processing the paper check through a check clearing house.

39. The method of claim 36 wherein charging the first account comprises electronically processing the second payment as an automated check clearing house transaction.

40. The method of claim 1 further comprising verifying that the first account has sufficient funds for the second payment.

41. The method of claim 1 further comprising depositing funds into the first account.

42. A method for processing a payment comprising: receiving a first check for a first payment, the first check containing first payment account information that identifies a first account; outputting data based on the first check; and requesting approval to charge the first account for a second payment.

43. A method for processing a payment comprising: storing first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; associating the first payment account information with a customer account; outputting data based on the first check; and requesting approval to charge the first account for a second payment.

44. A method for processing a payment comprising: receiving a request to make a first payment; and determining if a previous payment was made with a check, and if so: requesting approval to charge the first payment to an account identified by the check.

45. The method of claim 44 wherein receiving a request to make the first payment comprises at least attempting to purchase a product.

46. The method of claim 44 wherein receiving a request to make the first payment comprises at least registering to receive a service.

47. A method for processing a payment comprising: receiving a request to make a first payment; and determining if a previous payment was made with a first check, and if not: receiving a second check for the first payment, the second check containing payment account information that identifies an account; and requesting approval to charge a second payment to the account.

48. A computer-based method for processing a payment comprising: storing first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; sending a first HTTP transmission to a party, the first HTTP transmission representing a request for approval to charge the first account for a second payment; receiving a second HTTP transmission from the party, the second HTTP transmission representing an approval to charge the first account for the second payment; and charging the first account for the second payment.

49. The computer-based method of claim 48 wherein the first HTTP transmission further comprises a visual representation of the first check.

50. A method for processing a payment comprising: storing first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; and requesting approval to charge the first account for a second payment.

51. A system for processing a payment comprising: a merchant terminal having: a first processor; and a first storage device coupled to the first processor, the first storage device storing a program for controlling the first processor and the first processor operative with the program to: store first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment to a merchant; output data based on the first check, the data representing at least one of a visual representation of the first check and a visual representation of a second check that is based at least in part on the first check; and request approval to charge the first account for a second payment to the merchant; and customer terminal in communication with the merchant terminal, the customer terminal having: a second processor; and a second storage device coupled to the second processor, the second storage device storing a program for controlling the second processor and the second processor operative with the program to: receive the data output by the merchant terminal; display at least a portion of the received data; receive approval of a customer to charge the second payment to the first account; and communicate the approval of the customer to the merchant terminal.

52. An apparatus for processing a payment comprising: a processor; and a storage device coupled to the processor, the storage device storing a program for controlling the processor and the processor operative with the program to: store first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; and request approval to charge the first account for a second payment.

53. An apparatus for processing a payment comprising: a processor; and a storage device coupled to the processor, the storage device storing a program for controlling the processor and the processor operative with the program to: store first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; output data based on the first check; and request approval to charge the first account for a second payment.

54. An apparatus for processing a payment comprising: a processor; and a storage device coupled to the processor, the storage device storing a program for controlling the processor and the processor operative with the program to: receive a request to make a first payment; and determine if a previous payment was made with a check, and if so: request approval to charge the first payment to an account identified by the check.

55. An apparatus for processing a payment comprising: a processor; and a storage device coupled to the processor, the storage device storing a program for controlling the processor and the processor operative with the program to: receive a request to make a first payment; and determine if a previous payment was made with a first check, and if not: store payment account information that identifies an account, the payment account information being obtained from a second check for the first payment; and request approval to charge a second payment to the account.

56. A computer program product comprising: a medium readable by a computer, the computer readable medium having: program code adapted to store first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; and program code adapted to request approval to charge the first account for a second payment.

57. A computer program product comprising: a medium readable by a computer, the computer readable medium having: program code adapted to store first payment account information that identifies a first account, the first payment account information being obtained from a first check for a first payment; program code adapted to output data based on the first check; and program code adapted to request approval to charge the first account for a second payment.

58. A computer program product comprising: a medium readable by a computer, the computer readable medium having: program code adapted to receive a request to make a first payment; and program code adapted to determine if a previous payment was made with a check, and if so: request approval to charge the first payment to an account identified by the check.

59. A computer program product comprising: a medium readable by a computer, the computer readable medium having: program code adapted to receive a request to make a first payment; and program code adapted to determine if a previous payment was made with a first check, and if not: store payment account information that identifies an account, the payment account information being obtained from a second check for the first payment; and request approval to charge a second payment to the account.

60. An apparatus for processing a payment comprising: means for receiving checking account information obtained from a first check received in payment of a first charge; means for storing at least an indicator of a checking account identified by the received checking account information; means for identifying the checking account to a party during an online transaction; and means for requesting the party to approve payment of a second charge from the checking account.

61. A method for processing a payment comprising: a step for receiving a first check for payment of a first charge; a step for capturing at least an identifier of a checking account from the first check; a step for identifying the checking account to a party; and a step for requesting the party to approve payment of a second charge from the checking account.

62. A method of payment comprising: submitting a first check for a first payment, the first check containing first payment account information that identifies a first account; receiving data based on the first check that identifies the first account; and approving charging of a second payment to the first account.

63. A method for processing a payment comprising: receiving first check information for a first payment, the first check information containing first payment account information that identifies a first account; outputting a visual representation of a check based on the first check information; and requesting approval to charge the first account for a second payment.

64. The method of claim 63 wherein the first check information comprises routing data.

65. The method of claim 63 wherein receiving first check information for the first payment comprises receiving check information verbally.

66. The method of claim 63 wherein receiving first check information for the first payment comprises receiving check information via an HTTP transmission.

67. A method for processing a payment comprising: storing first payment account information that identifies a first account, the first payment account information being obtained from first check information received for a first payment; associating the first payment account information with a customer account; outputting a visual representation of a check based on the first check information; and requesting approval to charge the first account for a second payment.

68. A method for processing a payment comprising: receiving a first check, the first check containing first payment account information that identifies a first account; and after receiving the first check, requesting approval to charge the first account for a second payment