WO2001037172A1 - Cash payment system - Google Patents

Cash payment system Download PDF

Info

Publication number
WO2001037172A1
WO2001037172A1 PCT/US2000/031239 US0031239W WO0137172A1 WO 2001037172 A1 WO2001037172 A1 WO 2001037172A1 US 0031239 W US0031239 W US 0031239W WO 0137172 A1 WO0137172 A1 WO 0137172A1
Authority
WO
WIPO (PCT)
Prior art keywords
customer
account
website
merchant
cash
Prior art date
Application number
PCT/US2000/031239
Other languages
French (fr)
Inventor
Jacques Blinbaum
Lawrence Chaleff
Original Assignee
Jacques Blinbaum
Lawrence Chaleff
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jacques Blinbaum, Lawrence Chaleff filed Critical Jacques Blinbaum
Priority to AU16066/01A priority Critical patent/AU1606601A/en
Publication of WO2001037172A1 publication Critical patent/WO2001037172A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/24Credit schemes, i.e. "pay after"

Definitions

  • the present invention relates generally to the field of transactions conducted over electronic communication networks. More specifically, the present invention is related to purchasing goods via the Internet and connected communication networks using a payment system other than credit or debit cards.
  • a debit card is obtained through a financial institution which a consumer patrons for holding their money. These debit cards are typically tied to an account held by the consumer at the financial institution and charges made using the debit card are withdrawn directly from the consumers account. Therefore, in order to obtain a debit card, the consumer has to have opened an account with a financial institution. While most consumers do have an account with a financial institution, for various reasons, many opt not to obtain a debit card. In addition, while most consumers have an account with a financial institution in countries such as the United States, this is not true in other countries, therefore, completely preventing these consumers from this option.
  • the system of the present invention comprises a central site which is able to perform monetary transactions, e.g. electronic funds transfer (EFT), between affiliated merchant payment systems and any one of a number of cash depositories, e.g. banks.
  • EFT electronic funds transfer
  • Customers register with the central site and receive an account with the site. After receiving an account, the customers then deposit money into an account controlled by the central site at one of the cash depositories. The deposited money is credited to the customers account with the central site. After depositing money into the account controlled by the site, the customer then shops at an affiliated merchant.
  • EFT electronic funds transfer
  • the merchant queries the central site for approval for the sale. Once the merchant receives approval, the sale is consummated and the site transfers the appropriate amount of money from the cash depository to the merchant to effect payment for the good or service.
  • the customer shops at an unaffiliated merchant.
  • the customer visits the central site and provides the necessary information about the item the customer wishes to purchase and the merchant the customer wishes to purchase the item from.
  • the item is then purchased from the merchant by the site on behalf of the customer by consummating the purchase and transferring the appropriate amount to the merchant.
  • the system is transparent to the customer.
  • the merchant Upon indicating a willingness to purchase an item from a merchant, the merchant indicates an appropriate cash depository to the customer for payment.
  • the customer deposits the money at the depository into an account controlled by the central site. Once the money is deposited, the central site transfers the money to the merchant.
  • the central site is capable of transferring funds between an account controlled by the central site at a first bank or other depository, to an account controlled by the customer at a second bank or other depository.
  • the site is utilized to allow the customer to make deposits into their account at any local depository such that they no longer need to be proximate to the bank having the customer's account.
  • the customer deposits the money into the account controlled by the central site at the first bank.
  • the central site then transfers the money to the customer's account at the second bank.
  • the customer receives a card which is utilized to make purchases when the customer is physically located at a store of the merchant in a manner similar to a debit or credit card.
  • money supporting the use of this card is deposited by the customer into an account controlled by the central site at a cash depository, thereby freeing the customer from the need to deposit money to support the use of the card to a single bank or other financial institution, as is the case of a debit card.
  • FIGS. 1 collectively, illustrate the physical computing hardware of the present invention.
  • FIGs 2a-2b collectively, illustrate an overview of the process of the preferred embodiment of the present invention
  • Figures 3a-3f collectively, illustrate the interactions and process flow between different parties for various embodiments of the present invention.
  • Figure 4 illustrates generally the software architecture of the present invention.
  • Figure 5 illustrates the additional client functions of the present invention.
  • FIGS 6a-6f collectively, illustrate the methods of performing the additional functions of the system which relate to client account functions.
  • FIGS 7a-7d collectively, illustrate the methods of performing the additional functions of the system which relate to client financial transaction functions.
  • Figure 8 illustrates the additional merchant functions of the present invention.
  • FIGS 9a-9d collectively, illustrate the methods of performing the additional functions of the system which relate to merchant account functions.
  • Figure 10 illustrate the methods of performing the additional functions of the system which relate to merchant promotion functions.
  • website is utilized. While the system of the present invention is envisioned as particularly suited to performing electronic commerce transactions utilizing the World Wide Web (WWW) via the Internet, the use of this terminology and the embodiments specifically describing the communications network as the WWW and the Internet should not be seen as limiting for the present invention.
  • website generally refers, jointly or separately, to the interface (e.g., web page in the preferred embodiment) presented to a user of the system, the underlying software and architecture to perform the functions of the system and the physical computing/electronic hardware which supports the interface and functions.
  • the use of the terms customer, consumer and client are considered to be synonymous throughout this disclosure.
  • Figure 1 illustrates the preferred physical computing/electronic hardware implementation of the website and transaction center that, as will be described below, effects the transfer of money between a cash depository (described below) and a merchant (described below).
  • the website acts to coordinate the payment of funds for purchases by messaging the transaction center to inform it as to the transactions it is to perform, and receives messages from the transaction center about account balances and other account information.
  • Website 100 provides the services of account numbers, updating account information, deleting accounts, canceling accounts, reactivating accounts, account statements and cash payments, while transaction center 102 provides the services of money transfers, deposits received, account registration, withdraws and canceling transfers.
  • the transaction center is separate from the website of the present invention
  • the hardware and software implementing the functions of the transaction center is integrated with the website of the present invention.
  • the following description starting with figure 3 will be made with regard to an implementation in which functions of the transaction center are integrated with the website in order to simplify the discussion.
  • any "instructing”, “transmitting to,” or “receiving from” between the website to transaction center is regarded as messages or instructions passed between the coordinating functions of the website and the funds transferring functions of the website.
  • figure 1 1 illustrates the preferred messaging for the preferred implementation in which the transaction center is separate from the website.
  • website hardware includes a router 1 14 for routing packets between website 100 and transaction center 102.
  • Database 108 implements the database functions of the website and maintains information related to registration, account, shopping and profile information.
  • Application server 104 provides the website application service which performs the appropriate processing to implement the functions of the website, including serving pages to end users. All the interactions with the end user are performed by application server 104 in conjunction with database 108. After all the information is processed by the website application, a message is sent to the MQSeries Server 110 which is responsible along with second MQ Series Server 118 for managing the messages between transaction center 102 and the website 114.
  • Router 116 routes packets to Transaction center 102.
  • a DCOM transaction server 120 performs the appropriate processing to implement the functions of transaction center 102.
  • DCOM transaction server 120 utilizes SQL server 122 to perform the processing.
  • SQL server implements the database functions of transaction center 102 and maintains information related to registration and financial transactions.
  • additional hardware is used as is appropriate in the art. For example, a firewall may be utilized to provide security to website 100.
  • redundant servers may be used to effect load balancing and to provide for fault tolerance.
  • Figure 2a provides a general overview of the main process of the present invention.
  • a customer accesses the website and applies for and receives an account
  • a customer decides to place money into their account. To do so, the customer answers a number of questions which determine the amount the customer wants to add to their account and a local cash depository which the customer deposits money at to credit their website account. After this determination, a compensation record is displayed containing an indication of the local depository and an indication of an account number held by the website at the local cash depository and further information indicating the cash deposit is to be credited to a customer's account with the website. The customer then prints this compensation record, takes it to the indicated local cash depository and deposits the desired amount of money at the depository 202. At any time later, the customer then visits an affiliated merchant to shop and decides to make a purchase.
  • the customer Upon indicating a desire to purchase an item, the customer provides information designating his account at the website.
  • the affiliated merchant interacts directly with the web site receiving a confirmation approving the amount of the purchase 206.
  • the sale is consummated as between the merchant and the customer.
  • the amount of the purchase is then transferred to the merchant by the website and the customer's account is debited 208.
  • Figure 2b illustrates the steps performed when the merchant interacts with the website to obtain approval and payment.
  • the merchant contacts the website and provides the pertinent information related to the potential sale 212.
  • the website then introduces a client identification screen to the client so that the client can be appropriately identified by entering a personal identification number (PIN) and a password 214.
  • PIN personal identification number
  • the determination of whether the identity of the customer is valid is then made, along with a determination of the customer's balance 216. If the validity cannot be confirmed or the balance is insufficient for the purchase, an error message informs the client 218.
  • the website requests confirmation of the purchase 220. When confirmed, the website then performs the transactions and debits the customer's account 222.
  • Figure 3a provides an overview of the relationship of electronic interactions between different parties associated with the system of the present invention.
  • the parties associated with the website 300 of the present invention generally comprise customers 302 who purchase goods and services from retailers, affiliated retailers 304 who sign up with website 300, unaffiliated retailers 308 who have not signed up with website 300 and cash depositories 306 which accept cash deposited by customers 302.
  • customer 302 electronically interacts with website 300, affiliated retailer 304 and non-affiliated retailer 308, as will be described below.
  • Website 300 electronically interacts with cash depositories 306, non-affiliated retailers 308 and affiliated retailers 304.
  • Figures 3b-3d illustrate specific interactions between website 300 and the different associated parties.
  • Figure 3b illustrates the interactions for a website customer purchasing goods or services from an affiliated retailer by entering through website 300.
  • customer 302 registers with website 300 to become a website customer. After registering, customer 302 answers a number of questions which are utilized to determine an appropriate local depository, such as a local bank, retail location, post office, kiosk, automatic teller machines, etc., to deposit cash which is to be credited to their customer account provided by the service of website 300.
  • an appropriate local depository such as a local bank, retail location, post office, kiosk, automatic teller machines, etc.
  • website 300 presents to customer 302 a document which customer 302 prints including: an indication of an appropriate local cash depository of cash depositories 308, an indication of an account number held by website 300 at the local cash depository, and further information indicating the cash deposit is to be credited to customer's account with website 300.
  • Website 300 arranges with the local depository for the deposit to be made by customer 302.
  • Customer 302 deposits money at the local cash depository which confirms to website 300 that the deposit has been made.
  • Customer 302 then enters website 300 and navigates to an affiliated retailer 304 and places an order.
  • affiliated retailer 304 requests approval from website 300 to authorize the sale.
  • website 300 communicates an approval to affiliated retailer 304, effects a transfer of funds to affiliated retailer 304 and debits the customer's account.
  • affiliated retailer 304 then ships the product directly to customer 302.
  • Figure 3 c illustrates the interactions for a website customer purchasing goods and services from a non-affiliated retailer.
  • Customer 302 initially registers with website 300 and deposits money with a local depository which confirms customer's deposit to website 300 as previously described.
  • Website customer 302 visits the non-affiliated retailer 306, locates items they wish to purchase and then enters website 300.
  • Customer 302 provides the information required to make the purchase from non-affiliated retailer 306 to website 300.
  • Website 300 then approves the purchase and debits the customer ' s account.
  • Website 300 places the order with non-affiliated retailer 306 and performs the appropriate transfer of funds to non- affiliated retailer 306.
  • Non-affiliated retailer 306 then ships the product directly to customer 302.
  • website 300 contacts non-affiliated retailer 306 to offer non-affiliated 306 the services of website 300.
  • Figure 3d illustrates the interactions for a non-website customer purchasing goods and services from an affiliated retailer.
  • Non-website customer 302 visits affiliated retailer 304 and determines a purchase they wish to make.
  • Customer 302 is directed to website 300 where customer 302 registers and deposits money at a local depository which confirms the deposit as previously described.
  • Customer 302 then makes the purchase in the same manner as described in conjunction with figure 3b.
  • customer 302 can visit affiliated retailer 306 directly.
  • customer 302 is supplied with a physical card which contains customer information encoded thereon. Interactions between customer and a retailer are then physical, as the customer visits a brick and mortar store of a retailer and utilizes the physical card to effect a purchase in a manner similar to a credit or debit card.
  • deposits supporting the use of the card are able to be made in a variety of different locations, rather than at a specified financial institution as is the case for debit or pre-paid credit cards.
  • the physical card is one which is re-used, or alternatively disposed of when the amount deposited has been exhausted.
  • the system and method of the present invention is utilized for banks and other financial institutions.
  • the system is utilized to transfer funds from a local depository to an account of the customer at a bank of the customer.
  • a service is provided which allows customers the capability of depositing funds into their bank accounts from virtually anywhere, i.e. they do not have to make deposits at their financial institution's point of presence.
  • This embodiment is illustrated in figure 3e.
  • customer 300 desires to make a deposit into a bank account customer 302 owns at bank 310, however, customer 302 is unable to do so directly because bank 302 does not have a point of presence proximate to the location of customer 302.
  • Customer 302 receives an indication of a local depository from depositories 308 and information indicating an account to deposit money at the local depository. Once the money has been deposited at the local depository, website 306 effects a transfer of the funds to the customer's bank account at bank 310.
  • transactions are handled transparently to customer 302 by the system of the present invention. In this embodiment, as illustrated in figure 3f, customer 302 visits affiliated retailer 302 and purchases an item.
  • affiliated retailer 304 then indicates to customer 302 the location of a local depository and appropriate information as to which account to deposit the money for the purchase. Customer 302 then deposits the money at the local depository which confirms the deposit with website 300. Website 300 then transfers the funds to affiliated retailer 304, which then ships the product to customer 302.
  • FIG 4 generally illustrates the software architecture 400 of website 300.
  • Authentication and verification module 401 authenticates and validates all customers who use the payment system 300.
  • Authentication module 401 acts as the interface between customer 302 and the website 300 itself, processing all informational and transactional requests regarding the customer's account.
  • Authentication module 401 communicates with registration module 402, which performs the required processing of the necessary information when a customer opens a new account.
  • Authentication module 401 additionally communicates with account management module 406.
  • Account management module 406 performs and maintains all transactions relating to the customer's account. In order to perform the necessary transactions, account management module 406 communicates with cash depository database module 404 and account validation module 410. Cash depository database module 404 maintains, tracks and performs all of the third party financial transactions within the worldwide network of cash depositories 306. Cash depository database module 404 performs the transactions utilizing cash depository translation modules 408. Cash depository translation modules 408 are the interfaces between each depositories computer system and website 300. These modules perform all of the required translations for the specific financial transactions between website 300 and the depository's computer system. Account validation module 410 communicates with affiliated retailer database module 412.
  • affiliated retailer database module 412 maintains tracks and performs all third party point of sale transactions within the network of affiliated merchants. affiliated retailer database module 412 performs these transactions utilizing affiliated retailer translation module 414. This module is the interface between each independent affiliated merchant's point of sale system and performs the required translations and payment authorizations between website 300 and affiliated merchants.
  • account validation module 410 communicates with on-the-fly transaction processor module 416. This module provides authorizations to unaffiliated merchants when a customer wishes to make payments utilizing their account. It performs all required translations and payment authorizations between website 300 and unaffiliated merchants.
  • website 300 In addition to the functions of performing the actual transactions, website 300 also supports interfaces and processing to allow merchants, customers and other users to interface with the system to perform registration, check account information, receive support, etc.
  • Figure 5 illustrates the additional functions provided to the clients of the system by these interfaces and processing.
  • the client is provided with an interface 500 in order to determine the amount of money in their account at a given time.
  • the other functions are generally divided into account functions 502, information functions 504, promotion functions 506 and financial transaction functions 508.
  • Account functions 502 provide the client with the capability of registering with the system, if not already registered, viewing and changing their account information, canceling their account and changing their password.
  • Information functions 504 provide clients with the ability to obtain expert answers to "frequently asked questions" from a library of information, via an e-mail request for information, via a "live chat" with customer service, or via a telephone call to the call center
  • Provided by the transaction functions are the capabilities to obtain an account statement showing previous purchases/uses of their account, make further deposits to their account, make withdrawals from their account and to transfer money from their account.
  • Figures 6a-6e illustrate the methods to perform the various account functions.
  • Figure 6a illustrates the client registration function. The client initiates the client registration function 600 and provides the requested information 602.
  • Website 300 validates some of the information 604, such as whether the zip code is a valid zip code; the date of birth is a valid date of birth, etc.
  • website 300 requests that the client verify the information 606 and once verified, a new account number is generated 608, the user is shown the term and conditions governing the use of the system 610 and client data of the system is updated to include the newly registered client 612.
  • an activation code is sent to the client, preferably via e-mail.
  • the client must activate their registration using the registration code sent by e-mail, as illustrated in figure 6b.
  • Website 300 identifies the client and requests the activation code 620. Once the client enters the activation code, website 300 verifies the code and, if correct, activates the client's account 622.
  • Figure 6c illustrates the view client information function.
  • the client logs onto the system and selects the view client information option from account functions 624.
  • the system then retrieves the client's account information and displays it to the client 626.
  • Figure 6d illustrates the change client information function.
  • the client logs onto the system and selects the change information option from the account functions 628.
  • the client's information is then retrieved and displayed to the client 630.
  • the client is then able to change their information and resubmit it to the system.
  • the system receives the resubmission 632, the client data on the system is updated
  • Figure 6e illustrates the cancel registration function.
  • the client logs onto the system and selects the cancel registration option from the account functions 635.
  • the website then solicits the username and password of the client and requests confirmation of the cancellation 636.
  • the website determines if the client still has a balance in their account 638. If there is still a balance, the system confirms the address of the client so that a check for the balance remaining can be sent to the client 640. The account is then cancelled 642.
  • Figure 6f illustrates the change password function.
  • the client logs onto the system and selects the change password option from the account functions 644.
  • the client then enters their old password as confirmation of their identity, then their new password twice, so as to confirm the validity of the new password, as is standard in the art 646.
  • the website then confirms the change has been made and updates the password 648.
  • Figures 7a-7d illustrate the methods to perform the various financial transaction functions.
  • Figure 7a illustrates the view account statement function.
  • the client logs onto the system and selects the view account statement option from the financial transaction functions 700.
  • the client selects a period for which the account statement information is to be displayed 702.
  • the website then retrieves the client's account statement, which contains the transactions made by the client for the period selected, and displays it to the client 704.
  • Figure 7b illustrates the deposit function.
  • the client logs onto the system and selects the deposit option from the financial transaction functions 706.
  • the client then provides information regarding the depository and the amount to be deposited 708.
  • the website then generates a compensation record and displays it to the client so that the client can print it out and deposit the money at the depository 710.
  • Figure 7c illustrates the withdraw function.
  • the client logs onto the system and selects the withdraw option from the financial transaction functions 712.
  • the clients balance is then displayed by the website 714.
  • the client enters the amount of the withdraw 716 and the website determines if the amount indicated is available 718. If the amount is not available, an error message informs the client that they cannot withdraw that amount, and requests the client to enter a new amount 722. If it is, the website verifies the clients address so that a check can be sent to the client for the amount of the withdraw 720.
  • Figure 7d illustrates the transfer function.
  • the client logs onto the system and selects the transfer option from the financial transaction functions 724.
  • the clients balance is then displayed to the client 726 and the client indicates the amount of the transfer to the website 728.
  • the website determines if this is a valid amount 730 and if not informs the client 732. If it is a valid amount, the system requests the name of the person the money is to be transferred to 734. Once the client supplies the name, the website determines if the recipient of the transaction is a client of the website. If not, a new account is set up for the recipient and the money is transferred to that account 738. If the recipient is a client of the website, the money is transferred directly to their account 740.
  • Figure 8 illustrates the additional functions provided to the merchants of the system.
  • the merchant is provided with account functions 800 and promotion functions 802.
  • Account functions 800 provide the client with the capability of registering with the system, if not already registered, viewing their account information, changing their password, and viewing their account statement.
  • Promotion functions 802 provide the client with the capability of registering promotions.
  • Figures 9a-9d illustrate the methods to perform the various merchant account functions.
  • Figure 9a illustrates the methods for merchant registration. The merchant visits the website and selects the registration option 900. Then the merchant provides the necessary information requested by the website 902. The website then adds the merchant to the merchant database 904.
  • Figure 9b illustrates the method for the view merchant information function.
  • the merchant logs onto the system and selects the view client information option from account functions 906.
  • the system then retrieves the client's account information and displays it to the client 908.
  • Figure 9c illustrates the change password function.
  • the merchant logs onto the system and selects the change password option from the account functions 910.
  • the merchant then enters their old password as confirmation of their identity, then their new password twice, so as to confirm the validity of the new password, as is standard in the art 912.
  • the website then confirms the change has been made and updates the password 914.
  • Figure 9d illustrates the view account statement function.
  • the merchant logs onto the system and selects the view account statement option from the financial transaction functions 916.
  • the client selects a period for which the account statement information is to be displayed 918.
  • the website then retrieves the merchant's account statement, which contains the transactions made by the merchant for the period selected, and displays it to the merchant 920.
  • Figure 10 illustrates the register for a promotion function of the promotion functions.
  • the merchant logs onto the system and selects the register a promotion option from the promotion functions 922.
  • the system then prompts the merchant for and the merchant provides information on the promotion such as a description and the promotion value 924.
  • the website then confirms that the information has been received by displaying a confirmation message to the merchant 926.
  • Figure 1 1 illustrates the messaging between website 1 100 and transaction center 1102 in an embodiment in which website 1100 coordinates payments and transaction center 1 102 performs the transfer of funds. Discussion of figure 1 1 will be made with respect to the preferred embodiment or the present invention, however, is readily applicable to the alternative embodiments described above, and as above, one of skill in the art is capable of any requisite modifications to conform with the requirements of the alternative embodiments.
  • Transaction center 1 102 maintains the accounts for the customers of the system of the present invention, while website 100 maintains a client database reflecting information about the account such as the balance of the account. Before utilizing the account, client 1 104 must first deposit funds into a cash depository.
  • client 1 104 provides information relevant to the amount to be deposited along with other information and receives a compensation record (indicated in drawing as FCB Hardcopy) which client 1 104 prints and utilizes during the deposit of funds.
  • website 1 100 receives deposit data from transaction center 1 102 in order to update it's client database to reflect the amount in the client's account.
  • the deposits data provides confirmation to website 1100 that the deposits have been made.
  • transaction center 1 102 also provides operational status and account balance data to website 1 100 so that website's client database reflects the amount and status of the client's account. This transfer is performed, for example, periodically or when purchases are being made and approved, or based on any other appropriate schedule.
  • client 1 104 When making a purchase, client 1 104 indicates at the merchant's site the desire to pay utilizing their website account. Merchant 1 106 then makes an approval request to website 1 100. Website 1 100 then requests and receives authorization from client, as previously described by presenting a screen for client to enter username and PIN information. Website 1 100 then determines whether client 1 104 has an account balance equal to or greater than the amount of the payment for the purchase. If the balance is greater than or equal the purchase amount, website 1 100 sends approval data to merchant. Website 1 100 then records the transaction and sends purchasing data, such as merchant and client identification and purchase amount to transaction center 1 102. Transaction center then performs the appropriate transfer of funds utilizing the purchase data.
  • purchasing data such as merchant and client identification and purchase amount
  • transaction center 1 103 other data is passed between website 1 100 and transaction center 1 103 in order to enact the other functions provided by website 1 100 as previously described. For instance, transfer and withdraw data are sent for transfers withdraws. In addition, any information relevant to registration, cancellation, etc. is passed between website 1 100 and transaction center 1 102 so that transaction center 1 102 is capable of maintaining/generating/deleting accounts.
  • the present invention may be implemented on a conventional IBM PC or equivalent, multi-nodal system (e.g. LAN) or networking system (e.g. Internet, WWW, wireless web). All programming, GUIs, databases and data related thereto are stored in computer memory, static or dynamic, and may be retrieved by the user in any of: conventional computer storage, display (i.e. CRT) and/or hardcopy (i.e. printed) formats.
  • CONCLUSION A system and method has been shown in the above embodiments for the effective implementation of a cash payment system for payment over electronic communication systems.

Abstract

A website (100) which is able to perform monetary transactions, e.g. electronic funds transfer (EFT), between affiliated merchant payment systems and any one of a number of cash depositories, e.g. banks, is provided to allow customers to perform electronic purchases without the need for a debit or credit card. Customers register with the website (100) and receive an account with the site. After receiving an account, the customers then deposit money into an account controlled by the website (100) at one of the cash depositories. The deposited money is credited to the customers account with the website. The account with the website (100) is then utilized by customers to perform electronic purchases over a communication network. The system allows customers to make electronic purchases without a debit or credit card.

Description

CASH PAYMENT SYSTEM
This application claims the benefit of pending provisional application 60/165,734, filed November 15, 1999.
BACKGROUND OF THE INVENTION Field of Invention
The present invention relates generally to the field of transactions conducted over electronic communication networks. More specifically, the present invention is related to purchasing goods via the Internet and connected communication networks using a payment system other than credit or debit cards.
Discussion of Prior Art
Purchasing of goods and services conducted over communication networks, particularly the Internet and World Wide Web, is becoming more prevalent as the underlying technology becomes more mature and is better able to support such transactions. Currently, payment for goods and services purchased over communication networks is reliant on credit or debit cards. Such reliance, however, presents barriers to a universal acceptance or ability of consumers to purchase goods and services over these communication networks as credit cards and debit cards are only available to a limited segment of a population, and, indeed, in some countries are not available at all.
As credit card issuers are essentially providing purchasing power to a consumer up front, without any guarantee of return on the amount they have provided, the issuer performs checks on a consumers prior credit history. These checks are utilized by the issuer to make a decision as to whether or not the consumer presents a risk of default on the credit extended to them. Consequently, this determines whether the consumer is able to obtain a credit card. Some of the consumers who are unable to obtain credit cards, however, still have cash with which they are able to make an instant purchase. As such, there is further demand existent in the market which is unable to contribute to profits obtainable by retailers and suppliers conducting business via these communication networks.
Concomitant with these drawbacks, there are other difficulties with acceptance of credit card payments over communication networks, such as the Internet, as they are dependent upon a system of authorization regulations, international restrictions and cultural factors that severely limit the number of users.
There are burdens additionally associated with debit cards. Typically, a debit card is obtained through a financial institution which a consumer patrons for holding their money. These debit cards are typically tied to an account held by the consumer at the financial institution and charges made using the debit card are withdrawn directly from the consumers account. Therefore, in order to obtain a debit card, the consumer has to have opened an account with a financial institution. While most consumers do have an account with a financial institution, for various reasons, many opt not to obtain a debit card. In addition, while most consumers have an account with a financial institution in countries such as the United States, this is not true in other countries, therefore, completely preventing these consumers from this option. Even when consumers do have debit cards, they do not use them for purchases over communication networks as they have fears about the security of these networks and the fact that a debit card is typically tied directly to an account of the consumer that holds the bulk of their financial assets. If an unscrupulous individual steals the debit card number, that individual could effectively bankrupt the consumer.
Other problems associated with debit cards are the limited manner in which consumers can make money available to support a transaction made with a debit card. As previously described, the debit card is tied to an account of the user at a specific financial institution. For most consumers depositing into this account is not a problem, as the account is located proximate to the place where the consumer lives. However, most financial institutions do not have points of presence in all areas the consumer may be visiting, or in which they may live. This coupled with the fact that the consumer can only place money in their account, generally, at a point of presence of that financial institution, makes it potentially difficult for a consumer to provide the money supporting a debit card transaction as they must deposit the money in their own account at their own financial institution.
Certain efforts have been made in an attempt to open the market in electronic commerce to consumers who do not have or do not wish to use credit or debit cards.
An example of these attempts is websites that are focused on establishing electronic cash accounts for children. These sites are limited in their approach as they rely on an established relationship with a financial institution (bank, credit card company, debit card) and, therefore, an adult is usually required to participate in the transaction, usually by making deposits into the children's accounts via credit card or bank transfer. Another model uses the "prepaid phone card" model. Here the customer purchases a prepaid cash value card and logs onto a website to transfer the card value into online credit. This model is also limited in that it requires retail locations to sell these cards and remit the cash to the card issuer. Issues of distribution logistics and costs, collection, security, and vendor commissions make this model difficult to implement and operate.
What is needed is a system and method to provide a purchasing portal for electronic commerce which eliminates the need to use credit and debit cards to effect payment for goods and services purchased over communication networks such as the Internet. SUMMARY OF THE INVENTION
The present invention provides for a system and method for making electronic purchases over a communication network without the need for credit or debit cards. In one embodiment, the system of the present invention comprises a central site which is able to perform monetary transactions, e.g. electronic funds transfer (EFT), between affiliated merchant payment systems and any one of a number of cash depositories, e.g. banks. Customers register with the central site and receive an account with the site. After receiving an account, the customers then deposit money into an account controlled by the central site at one of the cash depositories. The deposited money is credited to the customers account with the central site. After depositing money into the account controlled by the site, the customer then shops at an affiliated merchant. Once the customer has indicated a willingness to purchase a good or service from the merchant, the merchant queries the central site for approval for the sale. Once the merchant receives approval, the sale is consummated and the site transfers the appropriate amount of money from the cash depository to the merchant to effect payment for the good or service.
In a second embodiment of the present invention, the customer shops at an unaffiliated merchant. When the customer then wishes to make a purchase from the merchant using the system of the present invention, the customer visits the central site and provides the necessary information about the item the customer wishes to purchase and the merchant the customer wishes to purchase the item from. The item is then purchased from the merchant by the site on behalf of the customer by consummating the purchase and transferring the appropriate amount to the merchant.
In a third embodiment of the present invention, the system is transparent to the customer. Upon indicating a willingness to purchase an item from a merchant, the merchant indicates an appropriate cash depository to the customer for payment. In order to complete the transaction, the customer deposits the money at the depository into an account controlled by the central site. Once the money is deposited, the central site transfers the money to the merchant.
In a fourth embodiment of the present invention, the central site is capable of transferring funds between an account controlled by the central site at a first bank or other depository, to an account controlled by the customer at a second bank or other depository. In this embodiment, the site is utilized to allow the customer to make deposits into their account at any local depository such that they no longer need to be proximate to the bank having the customer's account. To make a deposit into their account, the customer deposits the money into the account controlled by the central site at the first bank. The central site then transfers the money to the customer's account at the second bank.
In a fifth embodiment, the customer receives a card which is utilized to make purchases when the customer is physically located at a store of the merchant in a manner similar to a debit or credit card. However, money supporting the use of this card is deposited by the customer into an account controlled by the central site at a cash depository, thereby freeing the customer from the need to deposit money to support the use of the card to a single bank or other financial institution, as is the case of a debit card.
BRIEF DESCRIPTION OF THE DRAWINGS
Figures 1 , collectively, illustrate the physical computing hardware of the present invention.
Figures 2a-2b, collectively, illustrate an overview of the process of the preferred embodiment of the present invention Figures 3a-3f, collectively, illustrate the interactions and process flow between different parties for various embodiments of the present invention.
Figure 4 illustrates generally the software architecture of the present invention. Figure 5 illustrates the additional client functions of the present invention.
Figures 6a-6f, collectively, illustrate the methods of performing the additional functions of the system which relate to client account functions.
Figures 7a-7d, collectively, illustrate the methods of performing the additional functions of the system which relate to client financial transaction functions.
Figure 8 illustrates the additional merchant functions of the present invention.
Figures 9a-9d, collectively, illustrate the methods of performing the additional functions of the system which relate to merchant account functions.
Figure 10 illustrate the methods of performing the additional functions of the system which relate to merchant promotion functions.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
While this invention is illustrated and described in a preferred embodiment, the device may be produced in many different configurations, forms and materials. There is depicted in the drawings, and will herein be described in detail, a preferred embodiment of the invention, with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and the associated functional specifications for its construction and is not intended to limit the invention to the embodiment illustrated. Those skilled in the art will envision many other possible variations within the scope of the present invention.
During the following detailed description the term "website" is utilized. While the system of the present invention is envisioned as particularly suited to performing electronic commerce transactions utilizing the World Wide Web (WWW) via the Internet, the use of this terminology and the embodiments specifically describing the communications network as the WWW and the Internet should not be seen as limiting for the present invention. In addition, the use of the term website herein generally refers, jointly or separately, to the interface (e.g., web page in the preferred embodiment) presented to a user of the system, the underlying software and architecture to perform the functions of the system and the physical computing/electronic hardware which supports the interface and functions. The use of the terms customer, consumer and client are considered to be synonymous throughout this disclosure.
Figure 1 illustrates the preferred physical computing/electronic hardware implementation of the website and transaction center that, as will be described below, effects the transfer of money between a cash depository (described below) and a merchant (described below). In this case, the website acts to coordinate the payment of funds for purchases by messaging the transaction center to inform it as to the transactions it is to perform, and receives messages from the transaction center about account balances and other account information. Website 100 provides the services of account numbers, updating account information, deleting accounts, canceling accounts, reactivating accounts, account statements and cash payments, while transaction center 102 provides the services of money transfers, deposits received, account registration, withdraws and canceling transfers.
While in the preferred embodiment, the transaction center is separate from the website of the present invention, it is also envisioned that the hardware and software implementing the functions of the transaction center is integrated with the website of the present invention. As such, generally, the following description starting with figure 3 will be made with regard to an implementation in which functions of the transaction center are integrated with the website in order to simplify the discussion. When integrated, any "instructing", "transmitting to," or "receiving from" between the website to transaction center is regarded as messages or instructions passed between the coordinating functions of the website and the funds transferring functions of the website. After the discussion with reference to an embodiment in which transaction center and website are integrated, figure 1 1 illustrates the preferred messaging for the preferred implementation in which the transaction center is separate from the website. Generally, website hardware includes a router 1 14 for routing packets between website 100 and transaction center 102. Database 108 implements the database functions of the website and maintains information related to registration, account, shopping and profile information. Application server 104 provides the website application service which performs the appropriate processing to implement the functions of the website, including serving pages to end users. All the interactions with the end user are performed by application server 104 in conjunction with database 108. After all the information is processed by the website application, a message is sent to the MQSeries Server 110 which is responsible along with second MQ Series Server 118 for managing the messages between transaction center 102 and the website 114.
Router 116 routes packets to Transaction center 102. A DCOM transaction server 120 performs the appropriate processing to implement the functions of transaction center 102. DCOM transaction server 120 utilizes SQL server 122 to perform the processing. SQL server implements the database functions of transaction center 102 and maintains information related to registration and financial transactions. While not shown, additional hardware is used as is appropriate in the art. For example, a firewall may be utilized to provide security to website 100. In addition, redundant servers may be used to effect load balancing and to provide for fault tolerance.
Figure 2a provides a general overview of the main process of the present invention. A customer accesses the website and applies for and receives an account
200. At any time after receiving their account, a customer decides to place money into their account. To do so, the customer answers a number of questions which determine the amount the customer wants to add to their account and a local cash depository which the customer deposits money at to credit their website account. After this determination, a compensation record is displayed containing an indication of the local depository and an indication of an account number held by the website at the local cash depository and further information indicating the cash deposit is to be credited to a customer's account with the website. The customer then prints this compensation record, takes it to the indicated local cash depository and deposits the desired amount of money at the depository 202. At any time later, the customer then visits an affiliated merchant to shop and decides to make a purchase. Upon indicating a desire to purchase an item, the customer provides information designating his account at the website. The affiliated merchant interacts directly with the web site receiving a confirmation approving the amount of the purchase 206. Upon receiving an approval, the sale is consummated as between the merchant and the customer. The amount of the purchase is then transferred to the merchant by the website and the customer's account is debited 208.
Figure 2b illustrates the steps performed when the merchant interacts with the website to obtain approval and payment. After the customer indicates a purchase and that they will pay using the system of the present invention 210, the merchant contacts the website and provides the pertinent information related to the potential sale 212. The website then introduces a client identification screen to the client so that the client can be appropriately identified by entering a personal identification number (PIN) and a password 214. The determination of whether the identity of the customer is valid is then made, along with a determination of the customer's balance 216. If the validity cannot be confirmed or the balance is insufficient for the purchase, an error message informs the client 218. If the customer and balance is confirmed, the website then requests confirmation of the purchase 220. When confirmed, the website then performs the transactions and debits the customer's account 222.
Figure 3a provides an overview of the relationship of electronic interactions between different parties associated with the system of the present invention. The parties associated with the website 300 of the present invention generally comprise customers 302 who purchase goods and services from retailers, affiliated retailers 304 who sign up with website 300, unaffiliated retailers 308 who have not signed up with website 300 and cash depositories 306 which accept cash deposited by customers 302. Generally customer 302 electronically interacts with website 300, affiliated retailer 304 and non-affiliated retailer 308, as will be described below. Website 300 electronically interacts with cash depositories 306, non-affiliated retailers 308 and affiliated retailers 304.
Figures 3b-3d illustrate specific interactions between website 300 and the different associated parties. Figure 3b illustrates the interactions for a website customer purchasing goods or services from an affiliated retailer by entering through website 300. Before making any purchases, customer 302 registers with website 300 to become a website customer. After registering, customer 302 answers a number of questions which are utilized to determine an appropriate local depository, such as a local bank, retail location, post office, kiosk, automatic teller machines, etc., to deposit cash which is to be credited to their customer account provided by the service of website 300. Preferably, website 300 presents to customer 302 a document which customer 302 prints including: an indication of an appropriate local cash depository of cash depositories 308, an indication of an account number held by website 300 at the local cash depository, and further information indicating the cash deposit is to be credited to customer's account with website 300. Website 300 arranges with the local depository for the deposit to be made by customer 302. Customer 302 deposits money at the local cash depository which confirms to website 300 that the deposit has been made. Customer 302 then enters website 300 and navigates to an affiliated retailer 304 and places an order. Affiliated retailer 304 requests approval from website 300 to authorize the sale. Upon approval, website 300 communicates an approval to affiliated retailer 304, effects a transfer of funds to affiliated retailer 304 and debits the customer's account. Affiliated retailer 304 then ships the product directly to customer 302.
Figure 3 c illustrates the interactions for a website customer purchasing goods and services from a non-affiliated retailer. Customer 302 initially registers with website 300 and deposits money with a local depository which confirms customer's deposit to website 300 as previously described. Website customer 302 then visits the non-affiliated retailer 306, locates items they wish to purchase and then enters website 300. Customer 302 provides the information required to make the purchase from non-affiliated retailer 306 to website 300. Website 300 then approves the purchase and debits the customer's account. Website 300 then places the order with non-affiliated retailer 306 and performs the appropriate transfer of funds to non- affiliated retailer 306. Non-affiliated retailer 306 then ships the product directly to customer 302. Preferably, in addition, website 300 contacts non-affiliated retailer 306 to offer non-affiliated 306 the services of website 300. Figure 3d illustrates the interactions for a non-website customer purchasing goods and services from an affiliated retailer. Non-website customer 302 visits affiliated retailer 304 and determines a purchase they wish to make. Customer 302 is directed to website 300 where customer 302 registers and deposits money at a local depository which confirms the deposit as previously described. Customer 302 then makes the purchase in the same manner as described in conjunction with figure 3b.
Modifications to the manner in which various types of customers and retailers interact with the system are possible without departing from the scope of the present invention. For instance, rather than visiting an affiliated retailer 306 through website 300, website customer 302 can visit affiliated retailer 306 directly. In addition, while the interactions between customer 302 and the retailers have been described as electronic, in a further embodiment, customer 302 is supplied with a physical card which contains customer information encoded thereon. Interactions between customer and a retailer are then physical, as the customer visits a brick and mortar store of a retailer and utilizes the physical card to effect a purchase in a manner similar to a credit or debit card. However, used in conjunction with the system of the present invention, deposits supporting the use of the card are able to be made in a variety of different locations, rather than at a specified financial institution as is the case for debit or pre-paid credit cards. The physical card is one which is re-used, or alternatively disposed of when the amount deposited has been exhausted.
In addition, it is envisioned that the system and method of the present invention is utilized for banks and other financial institutions. In this case, rather than funds being transferred in relation to a purchase made, the system is utilized to transfer funds from a local depository to an account of the customer at a bank of the customer. In this manner, a service is provided which allows customers the capability of depositing funds into their bank accounts from virtually anywhere, i.e. they do not have to make deposits at their financial institution's point of presence. This embodiment is illustrated in figure 3e. A customer 302 registered with website
300 desires to make a deposit into a bank account customer 302 owns at bank 310, however, customer 302 is unable to do so directly because bank 302 does not have a point of presence proximate to the location of customer 302. Customer 302 receives an indication of a local depository from depositories 308 and information indicating an account to deposit money at the local depository. Once the money has been deposited at the local depository, website 306 effects a transfer of the funds to the customer's bank account at bank 310. In another embodiment of the present invention, transactions are handled transparently to customer 302 by the system of the present invention. In this embodiment, as illustrated in figure 3f, customer 302 visits affiliated retailer 302 and purchases an item. Affiliated retailer 304 then indicates to customer 302 the location of a local depository and appropriate information as to which account to deposit the money for the purchase. Customer 302 then deposits the money at the local depository which confirms the deposit with website 300. Website 300 then transfers the funds to affiliated retailer 304, which then ships the product to customer 302.
The following discussions will be made specific to the preferred embodiment of the present invention, so as to simplify the following description. The appropriate modifications needed to enact any of the alternative embodiments as described above are within the skill of one in the art.
Figure 4 generally illustrates the software architecture 400 of website 300. Authentication and verification module 401 authenticates and validates all customers who use the payment system 300. Authentication module 401 acts as the interface between customer 302 and the website 300 itself, processing all informational and transactional requests regarding the customer's account. Authentication module 401 communicates with registration module 402, which performs the required processing of the necessary information when a customer opens a new account. Authentication module 401 additionally communicates with account management module 406.
Account management module 406 performs and maintains all transactions relating to the customer's account. In order to perform the necessary transactions, account management module 406 communicates with cash depository database module 404 and account validation module 410. Cash depository database module 404 maintains, tracks and performs all of the third party financial transactions within the worldwide network of cash depositories 306. Cash depository database module 404 performs the transactions utilizing cash depository translation modules 408. Cash depository translation modules 408 are the interfaces between each depositories computer system and website 300. These modules perform all of the required translations for the specific financial transactions between website 300 and the depository's computer system. Account validation module 410 communicates with affiliated retailer database module 412. Affiliated retailer database module 412 maintains tracks and performs all third party point of sale transactions within the network of affiliated merchants. Affiliated retailer database module 412 performs these transactions utilizing affiliated retailer translation module 414. This module is the interface between each independent affiliated merchant's point of sale system and performs the required translations and payment authorizations between website 300 and affiliated merchants.
For unaffiliated merchants, account validation module 410 communicates with on-the-fly transaction processor module 416. This module provides authorizations to unaffiliated merchants when a customer wishes to make payments utilizing their account. It performs all required translations and payment authorizations between website 300 and unaffiliated merchants.
In addition to the functions of performing the actual transactions, website 300 also supports interfaces and processing to allow merchants, customers and other users to interface with the system to perform registration, check account information, receive support, etc. Figure 5 illustrates the additional functions provided to the clients of the system by these interfaces and processing.
As shown, the client is provided with an interface 500 in order to determine the amount of money in their account at a given time. The other functions are generally divided into account functions 502, information functions 504, promotion functions 506 and financial transaction functions 508. Account functions 502 provide the client with the capability of registering with the system, if not already registered, viewing and changing their account information, canceling their account and changing their password. Information functions 504 provide clients with the ability to obtain expert answers to "frequently asked questions" from a library of information, via an e-mail request for information, via a "live chat" with customer service, or via a telephone call to the call center Provided by the transaction functions are the capabilities to obtain an account statement showing previous purchases/uses of their account, make further deposits to their account, make withdrawals from their account and to transfer money from their account. Figures 6a-6e illustrate the methods to perform the various account functions. Figure 6a illustrates the client registration function. The client initiates the client registration function 600 and provides the requested information 602. Website 300 validates some of the information 604, such as whether the zip code is a valid zip code; the date of birth is a valid date of birth, etc. If the values provided are valid, website 300 requests that the client verify the information 606 and once verified, a new account number is generated 608, the user is shown the term and conditions governing the use of the system 610 and client data of the system is updated to include the newly registered client 612. After the update of the database an activation code is sent to the client, preferably via e-mail. To complete registration, the client must activate their registration using the registration code sent by e-mail, as illustrated in figure 6b. Once the client receives the activation code, they log on to website 300 and identify themselves via their username and password 618. Website 300 identifies the client and requests the activation code 620. Once the client enters the activation code, website 300 verifies the code and, if correct, activates the client's account 622.
Figure 6c illustrates the view client information function. The client logs onto the system and selects the view client information option from account functions 624. The system then retrieves the client's account information and displays it to the client 626.
Figure 6d illustrates the change client information function. The client logs onto the system and selects the change information option from the account functions 628. The client's information is then retrieved and displayed to the client 630. The client is then able to change their information and resubmit it to the system. Once the system receives the resubmission 632, the client data on the system is updated
634.
Figure 6e illustrates the cancel registration function. The client logs onto the system and selects the cancel registration option from the account functions 635. The website then solicits the username and password of the client and requests confirmation of the cancellation 636. Once the information is received, the website determines if the client still has a balance in their account 638. If there is still a balance, the system confirms the address of the client so that a check for the balance remaining can be sent to the client 640. The account is then cancelled 642.
Figure 6f illustrates the change password function. The client logs onto the system and selects the change password option from the account functions 644. The client then enters their old password as confirmation of their identity, then their new password twice, so as to confirm the validity of the new password, as is standard in the art 646. The website then confirms the change has been made and updates the password 648.
Figures 7a-7d illustrate the methods to perform the various financial transaction functions. Figure 7a illustrates the view account statement function. The client logs onto the system and selects the view account statement option from the financial transaction functions 700. The client then selects a period for which the account statement information is to be displayed 702. The website then retrieves the client's account statement, which contains the transactions made by the client for the period selected, and displays it to the client 704.
Figure 7b illustrates the deposit function. The client logs onto the system and selects the deposit option from the financial transaction functions 706. The client then provides information regarding the depository and the amount to be deposited 708. The website then generates a compensation record and displays it to the client so that the client can print it out and deposit the money at the depository 710.
Figure 7c illustrates the withdraw function. The client logs onto the system and selects the withdraw option from the financial transaction functions 712. The clients balance is then displayed by the website 714. After the balance is displayed, the client enters the amount of the withdraw 716 and the website determines if the amount indicated is available 718. If the amount is not available, an error message informs the client that they cannot withdraw that amount, and requests the client to enter a new amount 722. If it is, the website verifies the clients address so that a check can be sent to the client for the amount of the withdraw 720.
Figure 7d illustrates the transfer function. The client logs onto the system and selects the transfer option from the financial transaction functions 724. The clients balance is then displayed to the client 726 and the client indicates the amount of the transfer to the website 728. The website determines if this is a valid amount 730 and if not informs the client 732. If it is a valid amount, the system requests the name of the person the money is to be transferred to 734. Once the client supplies the name, the website determines if the recipient of the transaction is a client of the website. If not, a new account is set up for the recipient and the money is transferred to that account 738. If the recipient is a client of the website, the money is transferred directly to their account 740.
Figure 8 illustrates the additional functions provided to the merchants of the system. As shown, the merchant is provided with account functions 800 and promotion functions 802. Account functions 800 provide the client with the capability of registering with the system, if not already registered, viewing their account information, changing their password, and viewing their account statement. Promotion functions 802 provide the client with the capability of registering promotions.
Figures 9a-9d illustrate the methods to perform the various merchant account functions. Figure 9a illustrates the methods for merchant registration. The merchant visits the website and selects the registration option 900. Then the merchant provides the necessary information requested by the website 902. The website then adds the merchant to the merchant database 904.
Figure 9b illustrates the method for the view merchant information function. The merchant logs onto the system and selects the view client information option from account functions 906. The system then retrieves the client's account information and displays it to the client 908.
Figure 9c illustrates the change password function. The merchant logs onto the system and selects the change password option from the account functions 910. The merchant then enters their old password as confirmation of their identity, then their new password twice, so as to confirm the validity of the new password, as is standard in the art 912. The website then confirms the change has been made and updates the password 914.
Figure 9d illustrates the view account statement function. The merchant logs onto the system and selects the view account statement option from the financial transaction functions 916. The client then selects a period for which the account statement information is to be displayed 918. The website then retrieves the merchant's account statement, which contains the transactions made by the merchant for the period selected, and displays it to the merchant 920.
Figure 10 illustrates the register for a promotion function of the promotion functions. The merchant logs onto the system and selects the register a promotion option from the promotion functions 922. The system then prompts the merchant for and the merchant provides information on the promotion such as a description and the promotion value 924. The website then confirms that the information has been received by displaying a confirmation message to the merchant 926.
Figure 1 1 illustrates the messaging between website 1 100 and transaction center 1102 in an embodiment in which website 1100 coordinates payments and transaction center 1 102 performs the transfer of funds. Discussion of figure 1 1 will be made with respect to the preferred embodiment or the present invention, however, is readily applicable to the alternative embodiments described above, and as above, one of skill in the art is capable of any requisite modifications to conform with the requirements of the alternative embodiments. Transaction center 1 102 maintains the accounts for the customers of the system of the present invention, while website 100 maintains a client database reflecting information about the account such as the balance of the account. Before utilizing the account, client 1 104 must first deposit funds into a cash depository. As previously described, client 1 104 provides information relevant to the amount to be deposited along with other information and receives a compensation record (indicated in drawing as FCB Hardcopy) which client 1 104 prints and utilizes during the deposit of funds. Once funds are deposited, website 1 100 receives deposit data from transaction center 1 102 in order to update it's client database to reflect the amount in the client's account. The deposits data provides confirmation to website 1100 that the deposits have been made. In addition to deposit data, transaction center 1 102 also provides operational status and account balance data to website 1 100 so that website's client database reflects the amount and status of the client's account. This transfer is performed, for example, periodically or when purchases are being made and approved, or based on any other appropriate schedule.
When making a purchase, client 1 104 indicates at the merchant's site the desire to pay utilizing their website account. Merchant 1 106 then makes an approval request to website 1 100. Website 1 100 then requests and receives authorization from client, as previously described by presenting a screen for client to enter username and PIN information. Website 1 100 then determines whether client 1 104 has an account balance equal to or greater than the amount of the payment for the purchase. If the balance is greater than or equal the purchase amount, website 1 100 sends approval data to merchant. Website 1 100 then records the transaction and sends purchasing data, such as merchant and client identification and purchase amount to transaction center 1 102. Transaction center then performs the appropriate transfer of funds utilizing the purchase data. As also shown, other data is passed between website 1 100 and transaction center 1 103 in order to enact the other functions provided by website 1 100 as previously described. For instance, transfer and withdraw data are sent for transfers withdraws. In addition, any information relevant to registration, cancellation, etc. is passed between website 1 100 and transaction center 1 102 so that transaction center 1 102 is capable of maintaining/generating/deleting accounts.
The above enhancements for payment systems and their described functional elements are implemented in various computing environments. For example, the present invention may be implemented on a conventional IBM PC or equivalent, multi-nodal system (e.g. LAN) or networking system (e.g. Internet, WWW, wireless web). All programming, GUIs, databases and data related thereto are stored in computer memory, static or dynamic, and may be retrieved by the user in any of: conventional computer storage, display (i.e. CRT) and/or hardcopy (i.e. printed) formats. CONCLUSION A system and method has been shown in the above embodiments for the effective implementation of a cash payment system for payment over electronic communication systems. While various preferred embodiments have been shown and described, it will be understood that there is no intent to limit the invention by such disclosure, but rather, it is intended to cover all modifications and alternate constructions falling within the spirit and scope of the invention, as defined in the appended claims. For example, the present invention should not be limited by software/program, computing environment, specific computing hardware and specific interfaces.

Claims

1. A method of providing a payment for a good or service purchased by a customer performed via an internet website, said method comprising: maintaining a plurality of customer independent accounts at a plurality of cash depositories; receiving a confirmation that said customer has deposited funds into one of said plurality of customer independent accounts; transferring an appropriate payment amount of said deposited funds to a merchant from which said customer has purchased said good or service from in order to effect payment of said good or service.
2. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 1, said method further comprising: receiving a request for registration from said customer registering said customer and generating a virtual cash account for said customer, and establishing an account balance by crediting said virtual cash account with an amount equal to said funds deposited.
3. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 1, said method further comprising: receiving a request from said merchant to approve said purchase made by said customer; determining whether said account balance is equal to or greater than the amount required for payment of said good or service purchased; sending an approval to said merchant in response to said request to approve said purchase for said account balance equal to or greater than the amount required for payment of said good or service.
4. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 1, said method further comprising: generating a compensation record to indicate to said customer one of said cash depositories and said one of said customer independent accounts at said one of said cash depositories into which said customer is to deposit funds.
5. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 1, said method further comprising receiving information from said customer regarding a good or service said customer desires to purchase, and ordering said good or service customer desires to purchase from said merchant.
6. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 1, said method further comprising receiving a request for registration from said customer registering said customer and generating a virtual cash account for said customer; establishing an account balance by crediting said virtual cash account with an amount equal to said funds deposited; generating a compensation record to indicate to said customer one of said cash depositories and said one of said customer independent accounts at said one of said cash depositories into which said customer is to deposit funds. receiving a request from said merchant to approve said purchase made by said customer; determining whether said account balance is equal to or greater than the amount required for payment of said good or service purchased; sending an approval to said merchant in response to said request to approve said purchase for said account balance equal to or greater than the amount required for payment of said good or service.
6. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 7, wherein said central site is a website and said communication networks comprising one or more of LANs, WANs, cellular, Internet, or Web-based networks.
8. A method of providing a payment for a good or service purchased by a customer performed via an internet website, as per claim 1, said method further comprising providing said customer a physical card encoded with virtual cash account information for use by said customer when physically located at said merchant.
9. An e-commerce method of administering virtual purchasing accounts, one or more steps of said method processed across the Internet, said method comprising: for first time users, setting up a virtual purchasing account for each of one or more users; establishing an account balance for said virtual purchasing account by: generating an account deposit request; monitoring receivership of said account deposit request in a remote cash depository; confirming to each of said one or more users an available virtual purchasing account balance based on a previous existing balance and said monitored account deposit; transferring an appropriate monetary amount from said virtual purchasing account to said merchant, and modifying said virtual purchasing account balance to reflect the transfer.
10. An e-commerce method of administering virtual purchasing accounts, one or more steps of said method processed across the Internet, as per claim 9, said method further comprising: receiving a request from said merchant to approve a purchase and an associated cost; determining whether said account balance is equal to or greater than said cost; sending an approval to said merchant for said account balance equal to or greater than said associated cost
11. An e-commerce method of administering virtual purchasing accounts, one or more steps of said method processed across the Internet, as per claim 10, said method further comprising: requesting identification data from said customer; receiving identification data from said customer to confirm said purchase.
12. An e-commerce method of administering virtual purchasing accounts, one or more steps of said method processed across the Internet, as per claim 1 1 , wherein said identification data includes a username and personal identification number.
13. An e-commerce method of administering virtual purchasing accounts, one or more steps of said method processed across the Internet, as per claim 10, said method further comprising providing said customer a physically card encoded with virtual purchasing account information for use by said customer when physically located at said merchant.
14. A method of facilitating deposits of funds into a customer's account at a first financial institution in which a central computing site is capable of transferring funds between a central site account at a second financial institution to a said customer's account at a said first financial institute, said method comprising: indicating to said customer a location of said second financial institution and said central site account at said second financial institution said customer is to deposit funds; receiving a confirmation said funds are deposited in said central site account at said second financial institution, and transferring said funds to said customer's account at said first financial institution from said central site account at said second financial institution.
15. A system for providing payments for goods and services purchased via communication networks without using a debit or credit card, said system comprising: a website, said website providing a customer with an indication of a local cash depository and an account owned by said website at said cash depository said customer is to deposit funds for purchasing said goods and services, said website receiving a confirmation said funds are deposited at said local cash depository in said account owned by said website, said website receiving a purchase approval request from a merchant including information of an attempted purchase by said client, said website sending an approval to said merchant when said funds at least equals a purchase price of said attempted purchase, and a transaction center, said transaction receiving purchasing data from said website in response to said website sending said approval to said merchant, said purchasing data including customer identification data, merchant identification data and said purchase price of said attempted purchase, said transaction center transferring funds equal to said purchase price from said funds deposited in said account owned by said website to said merchant.
16. A system for providing payments for goods and services purchased via communication networks without using a debit or credit card, as per claim 15, wherein said website and said transaction center are integrated into a single system.
PCT/US2000/031239 1999-11-15 2000-11-14 Cash payment system WO2001037172A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU16066/01A AU1606601A (en) 1999-11-15 2000-11-14 Cash payment system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16573499P 1999-11-15 1999-11-15
US60/165,734 1999-11-15

Publications (1)

Publication Number Publication Date
WO2001037172A1 true WO2001037172A1 (en) 2001-05-25

Family

ID=22600222

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/031239 WO2001037172A1 (en) 1999-11-15 2000-11-14 Cash payment system

Country Status (2)

Country Link
AU (1) AU1606601A (en)
WO (1) WO2001037172A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013012141A (en) * 2011-06-30 2013-01-17 Sumitomo Mitsui Banking Corp Transfer processing system and method
US9799014B2 (en) 2011-11-23 2017-10-24 Coinstar Asset Holdings, Llc Mobile commerce platforms and associated systems and methods for converting consumer coins, cash, and/or other forms of value for use with same
CN109118190A (en) * 2018-08-11 2019-01-01 何太阳 A kind of multi-account management method, method of network payment and its payment system and payment system server-side
US10346819B2 (en) 2015-11-19 2019-07-09 Coinstar Asset Holdings, Llc Mobile device applications, other applications and associated kiosk-based systems and methods for facilitating coin saving
US10600069B2 (en) 2010-11-01 2020-03-24 Cardpool, Inc. Gift card exchange kiosks and associated methods of use

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815657A (en) * 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US6014650A (en) * 1997-08-19 2000-01-11 Zampese; David Purchase management system and method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5815657A (en) * 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
US6014650A (en) * 1997-08-19 2000-01-11 Zampese; David Purchase management system and method
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10600069B2 (en) 2010-11-01 2020-03-24 Cardpool, Inc. Gift card exchange kiosks and associated methods of use
JP2013012141A (en) * 2011-06-30 2013-01-17 Sumitomo Mitsui Banking Corp Transfer processing system and method
US9799014B2 (en) 2011-11-23 2017-10-24 Coinstar Asset Holdings, Llc Mobile commerce platforms and associated systems and methods for converting consumer coins, cash, and/or other forms of value for use with same
US10716675B2 (en) 2011-11-23 2020-07-21 Coinstar Asset Holdings, Llc Mobile commerce platforms and associated systems and methods for converting consumer coins, cash, and/or other forms of value for use with same
US11100744B2 (en) 2011-11-23 2021-08-24 Coinstar Asset Holdings, Llc Mobile commerce platforms and associated systems and methods for converting consumer coins, cash, and/or other forms of value for use with same
US10346819B2 (en) 2015-11-19 2019-07-09 Coinstar Asset Holdings, Llc Mobile device applications, other applications and associated kiosk-based systems and methods for facilitating coin saving
CN109118190A (en) * 2018-08-11 2019-01-01 何太阳 A kind of multi-account management method, method of network payment and its payment system and payment system server-side

Also Published As

Publication number Publication date
AU1606601A (en) 2001-05-30

Similar Documents

Publication Publication Date Title
US8447658B2 (en) Electronic bearer bond online transaction system
US20030004828A1 (en) Prepaid card authorization and security system
US20060242058A1 (en) Transaction system
US8286861B2 (en) Cash payment for remote transactions
US20040078276A1 (en) System for electronic merchandising and shopping
US20070282739A1 (en) Computer implemented method and system for rapid verification and administration of fund transfers and a computer program for performing said method
US20020103753A1 (en) Charge splitter application
KR20040010510A (en) System and method for third-party payment processing
WO2008018052A2 (en) Secure mechanism and system for processing financial transactions
WO2000073934A2 (en) Method and apparatus for surrogate control of network-based electronic transactions
US20020046184A1 (en) Method and system for delivering products and services to EFTPOS systems
AU2007299931A1 (en) Staged transaction system for mobile commerce
WO2002029508A2 (en) Broker-mediated online shopping system and method
US7295992B2 (en) Method and system for delivering products and services to a point of sale location
JP2003532170A (en) Systems and methods for secure electronic trading
JP2002074219A (en) Escrow settlement system, escrow settlement method, and computer-readable recording medium on which program is recorded
JP2002279323A (en) Electronic settlement service system and settlement service method
KR20010000805A (en) Improved credit card settlement system in e-commerce and the method thereof
WO2001037172A1 (en) Cash payment system
JP2002175489A (en) Electronic settlement method
EP1744518A2 (en) Transaction system
KR20010069525A (en) Messenger escrow service system and method, medium recorded the same method
KR20010104767A (en) Service system for electronic finance using telecommuication network and method thereof
WO2001022333A9 (en) Electronic prefunded purchasing unit account funding network and method
JP2001297282A (en) Clearance management system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase