CN1599920A - A virtual private lock box - Google Patents

Abstract

A system and method for effectuating Electronic Funds Transfer credit messages. The main structural components of the system include a Payment Portal Processor (PPP), an Internet Pay Anyone (IPA) Account, a Virtual Private Lockbox (VPL) and an associated Account Reporter, the existing EFT networks, and a cash card for accessing a VPL or IP account. The PPP is a software application that provides a secure portal for accessing (linking to) either the user's Demand Deposit Account (DDA) or an IPA account and can be combined with the functionality of a traditional digital Wallet. Consumers use a PPP enhanced Wallet to fund their account, shop on the web, pay bills, pay anyone, store electronic receipts and transaction history, and check their recent PPP enhanced Wallet activity. The IPA account is a special purpose account with limited functionality for making electronic payments in the form of EFT credit messages. The VPL is a limited function receive only account for receiving electronic payments through the EFT. The Account Reporter is a portal to view transaction history and balance of IPA and VPL accounts, provide online, real-time transaction reports, and to reconcile accounts receivable/purchase records against incoming EFT payment records. A physical card can be associated with either an IPA or VPL account in order to provide PIN debit capability.

Description

Virtual Private Lockbox

field of invention

The present invention relates generally to systems and methods for conducting electronic commerce, and more particularly to systems and methods for a payor to issue electronic credit to a payee using an electronic funds transfer system.

Background of the invention

For now, consumers have many ways to purchase electronically on the Internet, such as credit cards, offline charge cards, online charge cards, digital cash and smart cards. Each method has its advantages and disadvantages. The offline debit card uses the traditional transaction credit card system to pay off the payment without the need for a personal identification number (PIN; personal Identification Number). The online debit card To use it, the consumer is required to provide his or her PIN, and the purchase amount is simultaneously debited from the consumer's account. One disadvantage of both online and offline charge cards from the consumer's point of view is that there is no way to reverse or decline the associated transaction. On the contrary, by using a credit card, the consumer can reverse the relevant transaction at a later date, for example, if the item purchased by the consumer has not been delivered.

It is expected that credit cards will be the dominant online point of sale (POS; Point Of Sale) payment option for at least the next 5 years. As new Internet payment mechanisms have emerged rapidly, consumers and dealers have happily conducted many business expansions by using basic credit card functions. To this day, the use of credit cards in the market is still favored by the majority.

Today, there are several large-scale market segments that trade with online payment systems. First, for online digital smart products or services, such as written materials, music, software or games, there are a large number of small payments from consumers to suppliers, which can be "Intraprenur" whose products are sold directly to consumers. , individual or small reseller markets, but also larger intermediaries, either traditional retailers or auctioneers on the one hand, that bring together consumers and sellers to make sales easier. The second large market segment consists of consumer-to-consumer electronic savings. The third and growing market segment pertains to electronic payment methods between businesses and commercial companies.

These market opportunities will continue to expand rapidly, just as the Internet continues to expand. Generally, the Internet is considered to be based on personal computers (PCs) and telephones. However, the paradigm is rapidly changing to include broadband communications via area links such as Digital Subscriber Line (DSL), wireless and two-way cable. The number of terminals served has rapidly expanded, including: cellular phones with video displays and interactive TVs, personal digital assistants (PDAs), and public telephone booths (Kiosks) with Internet access. Changes to both will only increase the number of endpoints and consumers with high volume, micropayment capability needs.

In general, retail consumer sales, as well as business-to-business sales, have grown exponentially on the Internet. Payment for the majority of these sales is expected to be by credit card, which is widely owned and used, supported by the infrastructure in place and provides dealers and consumers with a high degree of assurance of making and receiving payments. Although there are significant differences in the way consumers use credit cards, consumers have traditionally used credit cards for larger purchases. In recent years, charge cards have entered the market and are used as cash and check substitutes for small-quantity transactions in the purchase of consumer products such as food and gasoline.

Charge and credit card transactions are currently processed using Electronic Funds Transfer (EFT) networks. The debit message including the transaction content is sent from the point of origin (for example: point of sale, ATM or an Internet dealer) through the FET network to the financial institution that issued the card (or its representative) . Now, only debit messages are sent over the EFT network, including debit reverse messages. Charge reverse messages reverse a previously processed charge transaction and are generally not considered a credit.

US Patent No. 5,220,501 to Lawlor et al. describes a local banking and bill payment system using FET networks. As described in this patent, the system and method of Lawlor et al. use the EFT network to implement a traditional way of debiting the user's bank account, and then use the traditional way, such as: automatic transfer system (ACH) network or paper check payment. Furthermore, the Lawlor et al. system uses a centralized computer, and the user is connected to the computer via a dedicated telephone link, as opposed to via the Internet.

While credit and charge cards are the most popular forms of payment on the Internet, there are disadvantages associated with these payment types. It is worth noting that each type has a relatively high cost, which includes a handling fee plus a dealer discount of 1.4% or more. This relatively high fee supports the credit card business model. While credit and charge cards can continue to be an important payment option for resellers selling higher-ticket items on the Internet, credit and charge cards are not economical enough for low-cost item purchases. For low-cost items, relatively high transaction processing fees combined with reseller discounts result in transaction processing fees as a relatively high percentage of the total revenue generated from the sale of products. These characteristics of low-cost programs facilitate the adoption of low-cost payment schemes that are guaranteed but do not require the payee to bear the risk and burden of certification.

The Internet is embracing a direct model in which producers of products or services transact directly with consumers. This mode has many implications for payment programs. First, by excluding the relevant middlemen, this direct model is leading to fierce price competition, making the manufacturer's profit thinner and thinner. This competitiveness creates the need to reduce all costs, especially the burden on payment processing costs. The second point is that the Internet has enabled a large number of independent producers to "set up shop" on the Internet and have instant access to the information of many consumers. Third, a large and increasing number of intellectual products such as publications, music, videotapes, software games are more efficiently distributed digitally via the Internet rather than by traditional (paper or disk) media. While this trend has started, the demand for e-commerce is expected to increase significantly as higher bandwidth and higher performance devices enter the market. Many of these purchases are characterized by low cost to the consumer and the ability to purchase individual products (ie, a song, a video, an article, a game, etc.). These features require a low cost form of payment.

Combining these two trends—namely, distributor-to-consumer direct distribution from independent “intrapreneurs,” and the ability to digitally dispense products—creates new commercial centers for instant payments in small, large quantities, and There are guaranteed payments to both consumers and producers. For all of the same reasons above, large intermediaries, such as established online retailers and auction houses, would also benefit from low-cost payment facilities for high-volume micropayments. Online retail currently faces a variety of problems, including low online shopping volume relative to the large number of website visitors; a large number of post-payments for online purchases; non-integrated "patchwork" systems for payment processing; high fraud rates and high processing fees, etc. . All these factors suppress the number of potential customers for comfortable shopping online and reduce the profits of online resellers.

Furthermore, there is as yet no effective way for consumers to pay other consumers using the Internet. All traditional person-to-person transactions involve physical cash or check transactions, not instant digital value transactions. Furthermore, the high cost of retail Wire transfer (ie, West Union) remains an unaffordable cost for a significant proportion of society.

Automated Fund Transfer (ACH) payments have begun to expand to include payments via the Internet. These types of transactions typically include payments related to loans, insurance and facilities. It is predicted that ACH automatic transfer system payment will not be widely used in online POS for two reasons. First, ACH transactions cannot provide transaction authorization, and second, authentication requires a pre-existing relationship between the consumer and the dealer. In addition, ACH payments must be received, credited and debited before funds can be utilized. In contrast to the ACH automatic transfer system, credit cards and offline charge cards require authorization rather than approval. Similarly, online debit cards require authentication (i.e., PIN or other means of authentication), and like credit and charge card transactions, the ACH automatic transfer system requires the user to provide the operator (payee) with the user's account information. "Key". This withdrawal mode to complete payment again adds to the security concerns discussed here (eg fraud).

Two significant disadvantages of some or all of the above models to Internet POS payment methods are: 1 (a pre-existing relationship between a consumer and a dealer must already exist; and 2) the consumer is required to provide the dealer with his or her account and/or PIN. This first shortcoming of several of the aforementioned models cannot practically be overcome because a customer cannot have pre-existing relationships with all possible dealers who do business on the Internet. Regarding consumer account and PIN requirements on the Internet, even though mail order companies have been operating in this manner for several years, many customers are still reluctant to electronically provide their account and PIN numbers to strangers on the Internet.

FIG. 1 illustrates a traditional loan/credit transaction model in which a consumer 100 electronically communicates his payment if he desires to buy a compact disc (CD) from an online retailer 110. Card or credit card number and/or PIN to online retailer 110. When it receives the information from the consumer 100, the online retailer 110 will transmit the proposed transaction to its correspondent bank 120 or the commodity acquirer via the EFT system (not shown) for approval. The dealer's bank 120 then approaches the bank 130 (issuing bank) that issued the charge/credit card to the consumer 100 (issuing bank), and the issuing bank 130 will check the consumer's balance on the card and then decide to approve or reject the relevant offer transaction. This approval or rejection message is passed back to the dealer's bank 120 via the issuing bank 130, which will then notify the online retailer 110 of the approval or rejection. If the account charged to the signed card/credit card is approved, the transaction will be completed by shipping the goods to the consumer 100 via the online retailer 110 .

The aforementioned disadvantages with respect to Internet shopping also apply to electronic bill payment. The first disadvantage, requiring a pre-existing relationship between a customer and a bill payee, is not yet a major concern since such a relationship is generally more likely to already exist between the consumer and the payee (eg: telephone, cable and utility companies); the second disadvantage is that it requires the consumer to provide the payee with his or her account number and/or PIN, which is a major concern with electronic bill payments. While fraud is less common with account payments, some consumers still worry about giving the payee his or her account number, as consumers presumably have regular transactions with the payee. affect the privacy rights of its consumers.

Summary of the invention

The present invention represents a novel embodiment for accomplishing electronic payments that balances existing platforms, traditional payment infrastructure, and currently available web-based technologies to make conducting electronic commerce in virtual and physical business centers possible. The concept of the present invention provides a robust and secure way to allow users (consumers) to shop on the Internet, pay bills and pay virtually anywhere to anyone, without the consumer needing to give away their account number information to the payee. After operators receive instant payment confirmation via the EDI network, they can ship their products in confidence that payment has been received. The present invention further enables small financial transactions and allows the creation of "cash on the web", as well as providing facilities for customer service and records management.

The system components of the present invention include: a payment portal processor; a digital wallet; an Internet Pay Anyone (IPA) account; a Virtual Private Lockbox (VPL); an account reporting program; ; and a cash card. The Payment Portal Processor (PPP) is an application software that adds e-commerce functionality to any Internet browser. This PPP application sits at the front end and provides a secure entry behind it to access (link to) the user's Demand Deposit Account (DDA) and IPA account. PPP enables users to issue electronic credits from their DDA and IPA accounts to any other account via the EFT network.

Although PPP can be used as a stand-alone product, in a preferred embodiment, the functionality of PPP is directly integrated into the PPP-enhanced digital wallet to enhance the consumer's Internet shopping experience. Alternatively, PPP processor hooks can be incorporated into existing digital wallets to add unique payment features to PPP. Additionally, features of online banking (eg, funds exchange) can be incorporated into the PPP to allow maintenance of accounts and funding of IPA accounts. Combined with traditional wallet functions and the account reporting process of the present invention, PPP is used to fund consumer accounts, shop online, pay bills, pay anyone, store electronic receipts and past transaction records, and Review the status of the user's recent account and purchases. Therefore, PPP provides consumers with a safe, risk-free and convenient way to conduct financial transactions on the Internet.

Most of the electronic wallets in the prior art on the Internet are used as a convenient means of transportation, which only provide the function of storing account number information and other filling forms (for example: shipping address). Unlike traditional wallets, the Payment Portal Processor (PPP) Enhanced Wallet of the present invention is associated with one or more DDA and/or IPA accounts. PPP thus provides users with a form of virtual cash that is safe and guaranteed to pay. The PPP further includes a receive and store feature that maintains a transaction history of all payment status with associated accounts linked to the PPP. PPP further has the ability to store and link to PPP account usage related miles, coupons, wagers or other market incentives, PPP Enhanced Wallet enhances the consumer experience in e-commerce, reducing the need to fill out lengthy payment and shipping forms The cumbersome procedures, change it to auto-fill. Resellers also benefit significantly from credit rollouts and automated form filling in PPP-enhanced e-wallets, as research indicates that a majority of e-commerce purchases are abandoned at the point of sale because consumers are unwilling to complete lengthy forms or provide personal Credit card number information. Furthermore, PPP-enhanced e-wallet's automatic form-filling feature reduces delivery errors because the "ship-to" address is automatically filled in, reducing human input errors.

An IPA account is a special purpose account with limited functionality in causing electronic payments. Funds in an IPA account can only be accessed electronically by the account user using standard authentication procedures such as a personal identification number. Such electronic access to IPA accounts can be accomplished via personal computers, card readers, personal digital assistants, interactive television, and cellular telephone technologies, such as: Provide their account information to any stranger. The aforementioned PPP (operated by the user) securely communicates with the IPA account and initiates the associated payment according to the present invention. An important feature of the present invention is completely different from the prior art in that the payment from the IPA account is transferred to the payee in the form of credit in the secure EFT network. As previously stated, currently only credit-related transactions are enabled on the EFT system. The FET credit information of the present invention represents a remarkable progress in the field, and no related content has been disclosed in the prior art in terms of electronic commerce.

Similar to IPA, VPL is a limited function account. While the IPA is electronically accessible, the VPL has built in a "receive only" feature that allows the dealer (or either party) to receive electronic payments via EFT. Therefore, VPL is a secure address that is available to the public as a means of receiving funds. These funds can then be automatically cleared to the user's associated DDA or IPA account, preferably once a day. As will be described further below, there are several VPL account forms according to the present invention: one for the consumer, one for the dealer, and one initially linked to a cash card, as described below. The VPL card is a receive only account which can only be debited through the use of the cash card and PIN. Consumer and dealer VPLs can similarly make PIN debits to access funds in the account. Unlike IPA accounts, VPL accounts cannot be used to initiate FET credit messages. In one embodiment of the present invention, the IPA and VPL accounts are logically one account with two account addresses. An address (the IPA address) known only to the user (and its issuing institution) is used to debit payments from the account. Another address, the VPL address for receiving electronic credits, can be freely published without fear of possible fraud.

The account reporting program is the portal for customers or businesses to view the balance and transaction history of IPA or VPL accounts. In addition to the aforementioned features for use with IPA accounts, the account reporting program includes special features for use by dealers in connection with their VPL accounts. The Account Reporting program provides online, instant transaction reporting, verification of billing receivable/purchase records and incoming EFT payment records. In addition, VPL's transaction history records can be stored in backup and retrieved via the payment search engine in the account reporting program. This provides dealers with powerful tools for data reduction, customer service and order fulfillment (warehousing, shipping, supply chain management) at their fingertips. According to the state of the art, credit card purchases on the Internet are not connected to cash management procedures. Unlike these prior art systems, the VPL, together with the account reporting program, provides dealers with complete shopping and cash management opportunities. The combination of VPL and account reporting program provides dealers with real-time payment receipt verification, accounts receivable function, order fulfillment convenience, commodity control/supply chain management and data reduction functions.

Account Submitter is a flexible component that provides instant payment confirmation, balance reconciliation and record keeping so that dealers can track purchase orders in preparation for immediate actual payment. Each VPL transaction can be stored, retrieved and accessed, store/retrieve. The store/retrieve function is the perfect tool for customer service and data reduction. The account reporting program provides all of the above features without requiring active involvement in the management of funds as required by the prior art.

Using the foregoing architecture, the method of the present invention allows consumers and businesses to safely and economically shop online, pay to any party online, send funds to any party online, pay electronically online, and even use linked cash cards. The method and framework of the present invention can make e-commerce feasible in virtual and real business centers through the use of legacy platforms, traditional payment infrastructure and currently available network-based technologies.

The present invention further solves at least many, if not all, of the aforementioned problems of the prior art. Currently, all Internet transactions use a "pull" technique where the dealer must receive the customer's account number (in some cases a personal number) to complete the payment. The payment method of the present invention instead uses a "push" technique where the user (consumer or business) pushes EFT credit from their IPA or DDA account into the dealer's account without having to provide their own sensitive financial account information.

The invention enhances security because sensitive financial information is not carried over the Internet. All financial transactions are executed via the secure EFT network. The method of the present invention provides buyers and sellers with the comfort that their transactions are secure and private. In addition, since payment confirmation is received immediately via the EFT network, the seller can ensure that the buyer's funds are in "good" condition before completing the shopping transaction (ie, before the goods are released (shipped) to the customer).

The present invention provides significant economic benefits over prior art systems and methods. The essential technology required to implement the invention exists, resulting in relatively reduced start-up costs for organizations implementing the invention. Payments made according to current methods are transmitted via mature, fully implemented FET exchanges, which can also result in lower transaction costs. The payment mechanisms of the prior art are not suitable for handling small transactions. However, the efficient low-cost architecture of the present invention supports payments of any amount and is ideal for small transactions. This architecture not only supports the growing demand for micro-payments for Internet goods such as online articles and music files, but also supports the demand for large-value payments.

With the framework and method of the present invention, the aforementioned two most obvious disadvantages of online shopping in the prior art can be overcome. The buyer (consumer or business) no longer has to provide confidential financial information to some stranger on the Internet. Instead, the buyer deals directly with a trusted institution (in a preferred embodiment, a bank). Also, there is no need for a pre-existing relationship between the customer and the distributor.

For the dealer, the present invention significantly reduces the cost of the transaction compared to using a credit card. This method also helps to reduce the occurrence of credit loss or fraud, and the finality of the transaction from the perspective of the financial institution ultimately substantially excludes the handling of disputes and charging issues. For financial institutions, the present invention virtually eliminates the possibility of fraud inherent in credit card transactions. Because consumers are typically only responsible for the first $50 of a fraudulent transaction, banks typically bear significant costs that accompany fraud. The chances of a computer hacker stealing a customer's account number (eg, a credit card number) from an Internet dealership can be completely ruled out because the dealership never receives such information.

The present invention is not limited to situations where consumers shop from Internet resellers or business-to-business transactions. The method of the present invention has further broad applicability by providing anyone with an account with a financial institution to transfer funds to anyone else with an account with the same or a different financial institution. The PayAnyone feature of the present invention also allows the parties to electronically transfer funds instantly without incurring the cost of today's wire transfer fees.

Brief description of the drawings

For purposes of illustrating the invention, a presently preferred form is shown in the drawings, however, it should be understood that the invention should not be limited to the precise forms shown in the drawings:

Figure 1 illustrates a prior art method of Internet payment process using charge and/or credit cards;

Fig. 2 narrates the first embodiment that the present invention provides Internet shopping;

Figure 3 depicts a preferred embodiment of the payable-anyone mechanism of the present invention;

Figure 4 illustrates a prepaid cash card embodiment of the present invention;

Figure 5 depicts an embodiment of the payable anyone mechanism of the present invention;

Figure 6 illustrates a preferred embodiment of the present invention where the biller directly requests payment of the bill;

Figure 7 illustrates an embodiment of the service provider statement payment integration of the present invention;

Figure 8 illustrates an embodiment of the present invention for customer statement payment integration;

Figure 9 illustrates the structure and procedure for funding an account associated with an electronic wallet in accordance with the present invention.

Detailed Description of the Invention

Different from today's credit card, online and offline billing and other payment modes that currently exist, one of the unique features of the method of the present invention is that for a payment instruction and the subsequent payment process, credit card, online and offline billing In the mode, the buyer provides an instruction to the seller that authorizes the seller to collect funds from the buyer's account. Depending on the system, in the case of online debits, charge instructions result in a guaranteed payment, rather than the longer wait for funds (e.g. checks) in the case of offline debit and credit cards, etc. The difference between the prior art model and the present invention model can be described as the difference between a "pull" and a "pull" model. In today's conventional model, the seller "pulls" payment from the buyer's account using debit instructions, whereas in the present invention, it is the buyer who "pulls" the EFT credit into the seller's account.

FIG. 2 illustrates a first embodiment of the present invention in which consumers (including businesses acting as consumers) can perform Internet shopping. Figure 2 further illustrates the main structural components of the present invention. Component 200 represents the component by which a consumer accesses the Internet. In a preferred embodiment, the workstation 200 is a personal computer loaded with an Internet browser 210 such as Netscape ^(TM) Navigator ^(TM) from Netscape or Microsoft ^(TM) Internet Explorer ^(TM) from Microsoft. In an alternative embodiment, the user can access the Internet using any Internet device (eg, a web-enabled cash dispenser) or personal digital assistant (eg, Palm Pilot ^™ ), cellular phone, or interactive television . The present invention is not limited to any specific physical device, and any device that provides an interface to the Internet can be used. For example a public telephone booth, if it can provide access to the Internet, can also be used to practice the invention.

When the user uses his browser 210 to access the Internet, the electronic wallet 215 is activated by the user. The electronic wallet 215 can be downloaded and installed from an Internet website. Using thin electronic wallet technology, most of the software and database including electronic wallet 21 reside on a main web server, and users access electronic wallet 215 via a website or a button (eg icon) on browser 210 . Some functions of the e-wallet 215 can run on the workstation 200 without being attached to the Internet. In addition to the PC-based access methods described above, the electronic wallet 215 can be loaded onto various non-PC devices, such as personal digital assistants, cell phones, and interactive televisions. The consumer can access the e-wallet 215 by selecting the e-wallet button on the toolbar of the browser 210 or selecting the e-wallet icon on the dealer's network side while logged on to the Internet. For non-PC devices, the Wallet 215 can be launched via a separate application, a browser link, or via a hosting website. In a preferred embodiment of the invention, an enterprise (eg, a bank) operates a server with an e-Wallet 215 application programming interface (API). This embodiment provides additional security for the connection between the Wallet 215 and the user's IPA 230 or other account maintained at the institution.

Figure 2 depicts a preferred embodiment of the present invention in which the e-Purse 215 incorporates all the functionality of the P227 into a single component. Such a PPP-enhanced e-wallet 215 performs all conventional functions of a conventional e-wallet (eg, form filling), and further has the payment function of the PPP 227 as described below. As an alternative to that shown in Figure 3 (discussed below), e-Purse 215 may be a conventional form-filling e-Purse with an appropriate interface to PPP 227, in a third preferred embodiment (as in Figure 5 below As discussed), the electronic wallet 215 is not used, and the PPP 227 operates as a separate component to generate authorization for payments. The following discussion of the PPP Enhanced Wallet 215, particularly the payment functionality, is equally applicable to the PPP 227 used as a standalone component or in conjunction with a traditional Wallet.

User logins to the PPP Enhanced Wallet 215 are secure and encrypted to protect the confidentiality of any financial information associated with the PPP Enhanced Wallet 215 operations. Once accessed, a window containing the PPP Enhanced Wallet 215 will initially appear on the workstation 200 and remain open for the duration of the user's use. This PPP enhanced Wallet 215 window is able to communicate with other browser windows. In a preferred embodiment of the present invention, the user is connected to the PPP-enhanced electronic wallet 215 via the Internet. In an alternative embodiment, the connection from the user's workstation 200 to the PPP-enhanced e-wallet 215 software can be accomplished via a separate dial-up line or a third-party dedicated network.

As one of its primary functions, the PPP Enhanced Wallet 215 acts as an entry to an Internet Payment Account (IPA) or a DDA account 230, provided through PPP 227, as will be described in more detail below narrative. In a preferred embodiment, the PPP Enhanced Wallet 215 stores the following types of information: form filling information such as: credit card number, debit card number, shipping address, alternate shipping address, frequent current account, membership discount Information (e.g., AAA membership, AAR membership), royalty program, and email address; discount information, such as: e-coupons, discounts, and dealer-specific proof of spend; for use with accounts related to PPP 227 Accumulated points or miles; and convenient information, such as: frequently paid VPL numbers (described below), account payment account numbers, receipts, e-commerce bookmarks, shopping lists. A preferred download folder is created on the user's local hard drive. The PPP enhanced e-wallet 215 has a pull-down menu for selecting, editing, updating, filtering, importing and exporting any of the above-mentioned information.

Using the above information, the PPP Enhanced Wallet 215 will automatically fill out the dealer's electronic shopping list with the user's shipping address, email address, discount number, etc. PPP enhanced electronic wallet 215 supports virtual cash (IPA/DDA) payment according to the present invention, traditional credit card and debit card "pull" payment and payment combining the above two types, which will be further described below. When receiving an electronic shopping message from a dealer network terminal 255 (which will be further explained below in conjunction with FIG. 2 ), the PPP enhanced electronic wallet 215 user can: 1) approve a shopping; 3) verify the correctness of the dealer's payee information (proof of the dealer's account 235 at the dealer's bank 275); 4) generate a purchase confirmation 244, which is transmitted to the dealer's network terminal 255 or VPL Reporter 240; and 5) Generate a receipt, which can be stored on the server hosting the PPP Enhanced Wallet 215 or in user storage (eg, hard drive) on the workstation 200 . If a purchase has not been completed, the PPP enhanced electronic wallet 215 user receives a confirmation message indicating that no purchase has been completed.

The PPP Enhanced Wallet 215 includes a "Time Expiration" feature whereby shopping requests that are not approved by the user within a set period of time (eg 10 minutes) will be invalidated. For "pay to anyone" payments (described further below in connection with FIG. 3), the PPP Enhanced Wallet 215 supports a user-defined cancellation period (eg, 30 minutes) during which the user is allowed to overturn the transaction.

An additional feature of the PPP Enhanced Wallet 215 is the establishment of paternal control. When setting up an IPA account, the user is given the opportunity to create secondary (child) IPA and/or VPL accounts, which are controlled by the main (parent) IPA account. For example a parent may need to set up an IPA/VPL account for each of its children. Via the IPA account linked to the parent's PPP Enhanced Wallet 215, the parent can then view and control all movements of the child IPA/VPL account. For example: a parent can limit the flow of funds to child accounts such that they can only receive funds from the parent's account. This will prohibit strangers from sending money to sub-accounts themselves. The parent may also limit the amount or amount of any transaction from the account, or limit (block) any unauthorized payment to the VPL account (eg, associated with an unapproved Internet end).

Using functionality from the online banking service, the PPP enhanced e-wallet 215 can be integrated with (linked to) some or all of the account the user maintains with the bank 220 . Users can thus easily transfer funds, credits, and equivalent credits from one account to another (eg, from a deposit account to an IPA account 230 or VPL account 235). Although in the preferred embodiment of the present invention, the IPA 230 and VPL accounts are maintained in a financial institution (e.g., a bank), it is acceptable that any enterprise that can be connected to the EFT network 270 can maintain the accounts 230, 235 And carry out the operation of the present invention.

The unique transaction number is included in any payment communication with the PPP Enhanced Wallet. All payment communications are stored by the PPP enhanced e-wallet 215 for user review and audit. Examples of stored payment communications include payment messages from the dealer or biller, payment authorization from the PPP enhanced e-wallet 215 to the bank 220, and payment confirmation 244 to the dealer (255 or 240). A transaction number for a particular transaction is included in each communication and to allow instant correlation and indexing of communication records (e.g. balance reconciliation), the PPP Enhanced Electronic Wallet 215 interfaces with the account reporting program described below, which Access to all stored transactions. In a preferred embodiment of the present invention, payment communications are stored in a common database that both the PPP Enhanced Wallet 215 and the account reporting program associated with a particular account can access. Transactions are stored for auditing and disaster recovery purposes. The PPP Enhanced Wallet 215 allows the user to review the history of all transactions, including receipts and messages. These historical items can be categorized by date, function (billing payment, payment to anyone, purchase, etc.), amount, payment initiation or receipt, and distributor.

As described further below, the PPP Enhanced Wallet 215 is responsible for initiating the push out of credit to the dealer's account 235 . For credit rollout over EFT, the PPP Enhanced Wallet 215 requires the dealer's payee information, which uniquely identifies the dealer's Virtual Private Lockbox (VPL) 235 . This payee information includes the dealer bank 275 identification number (typically 6 digits) and the VPL account 235 number (typically 10-13 digits). These payee information constitute addresses to which e-wallet 215 can push the associated credit. Payment communications from the PPP Enhanced Wallet 215 may additionally identify the PPP Enhanced Wallet 215 user by name (if desired) and include a unique transaction number. The PPP Enhanced Wallet 215 can make recurring payments (eg, daily, weekly, etc.), as well as recurring payments (on specific calendar days or on specific days). If the PPP Enhanced Wallet 215 is linked to a DDA account, then DDA charges (e.g. checks, return checks, ACH payments, etc.) Funding charges. Before their first transaction using the PPP Enhanced Wallet 215 , users need to approve and agree to accept the PPP Enhanced Wallet 215 contract, including the condition of refunding any erroneously received earnings.

Before processing any online purchase or making any payment using the method of the present invention, the consumer establishes an Internet Payment Account (IPA) 230 with his bank 220 . Alternatively, a DDA account 230 can be used, but it is less preferred. One of the reasons for this is that, conceivably, only small payments can be withdrawn from the IPA account 230 compared to funds normally maintained in the DDA account, and thus less funds can be maintained in the account.

The IPA account 230 is a specific account according to the present invention used especially in electronic commerce. Once the IPA account 230 is established, the user can draw from their DDA checking or savings account, the consumer's online line of credit (Line of Credit), credit or charge card account held by the bank 220, or any other account from which the customer can transfer funds. account (eg: another DDA account or credit card account at another financial institution), to fund account 230 . The IPA account 230 provides confirmation capabilities for the user to verify that the sums obtained are correct. The IPA account 230 and the VPL account 235 (described below), both allow PIN debit transactions and withdrawals from related accounts.

In a preferred embodiment of the present invention, the IPA account 230 and the VPL account 235 are combined into one account. The IPA account functionality is accessed via the first address to the account, whereby address funds can be transferred from the IPA account. This address is accessible only to the user and it is kept secret with a password and/or PIN. If the user has several IPA accounts, when the user accesses its PPP 227, a single password and/or pin program provides access to all of the user accounts. The function of the VPL makes that individual account appear as a receive-only account and therefore accessible via a second, preferably different, address. According to the invention, the second address can only be used for the receipt of credits, preferably electronic credits. Since this second address can only be used to receive funds, users are free to publish this address without fear of any fraudulent attempts by someone to transfer money from the account. The VPL portion of the account can be accessed for PIN debit transactions as will be further described in connection with the physical card embodiment of the present invention (see FIG. 4).

From the user's point of view, it is preferable to use a separate IPA/VPL account 230 for electronic credit and payment, to provide separate billing from the user's normal DDA. Like its normal account, the transaction history of IPA230 is archived. Since the IPA account 230 is not required to bear interest, it is foreseeable that the user may suitably provide only small amounts of funds to this account for potential online purchases. The user can establish regular (eg weekly) fund transfers of the IPA account 230 . In another alternative embodiment of the present invention, user payments according to the present invention may be made directly to a normal DDA account.

The IPA230 or VPL235 account can have a physical paired card for substantive personal ordering and cancellation transactions, which will be further described below in conjunction with FIG. 4 . Each IPA 230 and VPL 235 account allows physical access to card readers for debit transactions via automated teller machine ATMs or dealer PINs.

One of the most important distinguishing features of the present invention is the use of the existing EFI network 270 . While these networks have provided secure funds transfers for over 270 years, the use of these networks in accordance with the present invention is hitherto unprecedented. In use of the EFT network, the present invention provides instant credit, unlike prior art debit message methods which only provide something like credit in the reversal of a previous debit transaction (e.g., credit card) . The EFT network 270 is used to complete the IPA transaction and realize the function of the IPA report, and can provide funds for the IPA 230 . As with the transmission of instant credit messages, the EFT network 270 transmits messages containing specific transaction codes, account and bank number structures (addresses) for uniquely identifying IPA transactions. Additionally, the EFT network 270 may be used to verify the validity and existence of a destination account as described further below.

As mentioned above, similar to the IPA account 230, the Virtual Personal Lockbox (VPL) 235 is an account with limited functionality. While the IPA 230 is electronically accessible to output payment transactions, the VPL 230 is constructed with EFT network "receive only" functionality. This feature of the VPL account (or a VPL address for a dual address IPA/VPL account) provides the dealer (or other party) to receive electronic credit (eg, payment) via the EFT 270. In this way, VPL 235 is a secure address available to the public as a means of receiving funds. Once received via the VPL account 235, the funds can then be manually or automatically cleared by the dealer bank 275 to one of the owner's other accounts 280 (eg, a DDA or cash concentration account 280). This checkout can be performed once a day, or more or less than once a day, depending on the needs and purposes of the VPL user.

Like the IPA account 230, the VPL 235 can have a physical paired card to make physical purchases and cancel purchases in person. The VPL 235 may allow physical access via an ATM or dealer card reader for personal identification number (PIN) debit transactions using a user credential accessible (address) for debit transactions from the VPL 235. While providing the general functionality of the account (to hold funds), it must be reiterated that the basic functionality of the VPL 235 differs from that of the IPA account 230. The VPL 235 is a secure lockbox into which funds can be transferred, but which cannot be withdrawn (except during a sweep or other PIN transaction as described herein.)

In the preferred embodiment of the present invention, VPL addresses for various dealers or other recipients of electronic payments are available from public directory 325 (see FIG. 3). Since the "receive-only" address of the VPL account 235 is what it publishes in the public directory, dealers and other users of the "receive-only" VPL 235 can allay fears of possible fraudulent situations. In a preferred embodiment of the present invention, this directory of VPL addresses 325 is maintained on an Internet-accessible server and is accessible via a network portal that provides for retrieval, selection, and access to VPL information. Alternatively, directory 325 may be accessed by a personal digital assistant, kiosk, or telephone using voice recognition or other telephony technology. Directory 235 may be used by PPP Enhanced Wallet 215 to verify the accuracy of the VPL address specified in the VPL address before it is ready to send a credit message to the account specified in the VPL address.

As mentioned above, the address for the IPA 230 or VPL 235 consists of the institution identification number (usually 6 digits) where the account is held and the account identification number (usually 10 to 13 digits). For customers (electronic white pages), the directory 235 includes, but is not limited to, the VPL address, the name of the VPL customer, the user's post office address, phone number, and email address. For enterprises (electronic yellow pages), the directory 325 includes but not limited to VPL's address, enterprise name, industry or enterprise type, enterprise post office address, telephone number and email address.

As briefly stated above, the account reporting program 240 is the viewing port for the VPL account 235 which provides online, instant transaction reporting and reconciliation of accounts receivable/order records 250 to incoming EFT payment records 245 . Although originally intended for use by dealers, the functionality of the Account Reporter 240 is incorporated into the PPP 227 e-Purse 215. PPP 227 preferably includes a basic set of customer needs, while account reporting program 245 includes additional features required by dealers and businesses (such as reconcile of purchase records and payment records).

The VPL account 235 updates the account reporting program 240 when payment records (credit messages) and transaction numbers are received via the EFT messaging system 270 . At the same time, any purchase orders 250 (in record form) and payment confirmations (as described below) are passed to the Account Reporter 240 from the dealership and request payment network. As seen in FIG. 2, account reporting program 240 is also capable of receiving purchase confirmation 244 from PPP 227. Purchase confirmations 244 and payment records 245 can be retrieved from the account reporting program 240 in real time. Account Reporter 240 users can go to view records associated with their VPL account 235 on the Internet. Although only one VPL account 235 has been illustrated in FIG. 2 , it can be appreciated that a dealer can maintain several VPLs 235 at the same time. Each of these VPL 235 can be accessed and viewed through a single account reporting program 240, much like a customer can associate several IPA/VPL accounts with their PPP 227 and can use the PPP 227 to view these accounts.

In addition to the basic feature functionality previously described in conjunction with the account reporting program 240 (storing, reviewing, and filtering transaction history), the dealer embodiment of the account reporting program 240 includes additional functionality. The first additional functionality provided by the dealer account reporting program 240 is its reconciliation capability, which matches order requests 250 generated by the dealer network 255 with shopper order confirmations 244 and EFT payment records 245 . Any items that cannot be paired will be flagged by Account Reporter 240 for further review. The dealer reporting program 240 can further provide identification numbers and password security codes, providing various levels of access authorization to users.

In addition, the dealer account reporting program 240 automatically updates the dealer's accounts receivable, merchandise, and fulfillment documents. Combined and sent to a warehouse to initiate product shipment 260, and linked to United Parcel Service (UPS ^™ ), FedEx ^™ or other shipping services to complete the associated shipment. The Account Reporter 240 includes important customer service tools such as the ability to capture/review e-shopping orders/payments in real time and in turn directly email or auto-fax the aforementioned documents to the customer. Account reporting program 240 further provides a data layout tool that collects relevant statistics on buyer/shopper behavior, seasonal and regional buyer and seller trend tracking, and other key demographics. Based on these statistics, dealers can centrally issue, customized electronic coupons via their account reporting program 240 .

In a preferred embodiment of the present invention, a user of an IPA account 230 can specify whether their credits issued from the IPA should include any identifying information (eg, account number, name, . . . ). One of the features of the electronic credit extension of the present invention is that the credit extension can be completely anonymous, and the credit recipient has no way of determining where the credit originates. The credit recipient can use a transaction ID included in the EFT credit rollout to compare the credit received with the proposed shopping plan. In the Internet shopping embodiment described below, the Internet reseller provides the buyer with a transaction ID that the buyer includes in the EFT credit message sent to the Internet reseller's VPL account.

If the user places less emphasis on privacy, the user may include a partial or complete identification of himself in the credit rollout. Provided that the credit push received by the VPL 235 does include some identifying information, the Account Reporting Program 240 may be configured so that the identity of the individual buyer is subject to the prior consent of the user who initiated the Crediting to the VPL 235 before being available for the Account Reporting Program 240 used. To customers, Account Reporter 240 appears as a seamless part of PPP 227, while to Dealers and Enterprises, Account Reporter 240 appears as a stand-alone facility.

Dealer websites 255 are well known to those skilled in the art. The dealer's website 255 usually includes program code (such as HTML, XML or ECML) to obtain the transaction BIN statement (payment information) of the electronic wallet 215 . As further described below, these payment messages typically include the dealer's VPL 235 address, including the dealer's bank 275 address. The payment message allows the consumer to push credit from the IPA account 230 to the VPL account 235 via the EFT system 270 . The dealer website 255 can provide a hot link at the shopping website 255 that goes directly to the buyer's PPP enhanced e-wallet 215 .

Having described the structural components of the preferred embodiment of the present invention, the next discussion is the preferred embodiment of the present invention related to Internet shopping. As in all Figures 2-9, this method step is represented in the small circles in the Figures that are adjacent to and most closely related to the relevant action being taken. In the preferred embodiment, the consumer (user) begins the process steps in 2A by logging on to the Internet, launching the browser 210, and selecting the PPP Enhanced Wallet 215 icon from the browser 210 toolbar. This PPP-enhanced e-wallet does not have to be activated until the user actually wishes to purchase an item, but the PPP-enhanced e-wallet 215 can also be included in the user's favorite shopping site (or payment site as will be mentioned further below) list of links.

In step 2B, the user completes the authentication procedure 205 to correctly identify himself to the PPP enhanced e-wallet 215 . Usually, the verification process includes the user typing the user's ID code and password on the keyboard of the workstation 200 . The user is thus authenticated and authorized to access their PPP enhanced wallet 215 . In step 2C, the user is presented with balance information on the IPA account 230 associated with the PPP enhanced e-wallet 215 and can choose from several options. In a preferred embodiment of the present invention, the options presented to the user may include: shopping online, paying to anyone (see Figures 3 and 5), funding an account (see Figure 9), paying a bill (see Figure 6-8) and view account activity.

Assuming the user has selected the option to shop online at step 2D, the browser 210 may initially point directly to the approved reseller's specific website list (which may also include several VPL addresses for that reseller). Alternatively, the user is free to navigate the Internet to a dealer website of his choice. In step 2E, the user has found and selected a purchase item from the particular dealer's website 255 and more specifically from the dealer's website 255 . Since the PPP enhanced electronic wallet 215 is available, the dealer website 255 identifies the user as a customer of the PPP enhanced electronic wallet 215 . Based on this identification, all shopping fields (shipping address, name, etc.) required by the dealer website 255 are automatically generated from the PPP enhanced e-wallet 215, as previously described. Alternatively, users can sign up to their PPP-enhanced e-wallet 215 after finding purchases from a website. The user can invoke the PPP enhanced wallet 215 by clicking on an icon embedded directly in the dealer's web page 255 , or by clicking on the e-wallet icon on the toolbar of the browser 210 to complete the operation.

In step 2F, the dealer 255 generates and transmits bill payment information to the user, which includes information about future purchases. The information provided by the website 255 in the bill payment message includes, but is not limited to, the following: dealer BIN, dealer account number, transaction ID, and amount of the transaction. In step 2G, a bill payment message is received by the Wallet 215 window. Window displays bill payment messages for user review. If the user changes his or her mind, the user can select an icon on the window to cancel the purchase. If the user does complete the purchase, the subscription item's icon is selected. Even though the above has been described with respect to a single item, it is clear that the above procedures are equally applicable to the shopping cart approach employed by most dealership sites 255 . In this shopping cart approach, after the customer has selected some items to be purchased, the dealer website 255 counts all the items and sends a summarized payment message to the PPP enhanced e-wallet 215 at step 2F.

If the user has selected the purchase item according to the payment message from the dealer's network terminal 255, in step 2H, the PPP 227 part of the PPP enhanced electronic wallet 215 first verifies that the user is in the main IPA account 230 associated with the PPP enhanced electronic wallet 215 balance in . If there are insufficient funds in the IPA account 230, the user is asked if he/she would like to transfer funds from other accounts to the IPA account. Using an online banking program, PPP Enhanced Wallet 215 can transfer funds to IPA Account 230 from any account that PPP Enhanced Wallet 215 has access to. If there are insufficient funds in the IPA account 235, the PPP 227 will generate a payment authorization message to be sent to the bank 220. This payment authorization message 225 includes the payee information (dealer VPL account and bank address) described above, and may also include a user-defined memo field for entering user-desired information (such as "for new mysterious Payment for Books").

In addition to generating and transmitting payment authorization 225, PPP 227 directly transmits an order approval to dealer website 255. Typically, in response to the purchase approval from the user PPP 227, the dealer website 255 creates a purchase record 250 in a database (not shown) for future reconciliation with the actual payment confirmation 244 and/or payment list 245. As illustrated in FIG. 2, the PPP 227 also transmits a payment confirmation 244 to the dealer's website 255 or the dealer's account reporting program 240. In the preferred embodiment, payment confirmation 244 is in the form of an electronic message (eg, an email) to account reporting program 240 . This payment confirmation 244 may be sent before or after the PPP 227 actually transmits the payment authorization 225 to its bank 220 without any confirmation that the approved payment from the bank 220 has actually been transmitted over the EFT network 270. Alternatively, PPP 27 may wait until it has received confirmation from bank 220 that the EFT credit message was actually transmitted over EFT network 270 .

In a preferred embodiment, the banks 220, 275 maintain the above-mentioned database along with the IPA 230 and VPL account 235, which can be used as a backup for all record keeping to feed and retrieve transaction data. Such transaction data includes, but is not limited to, payment authorizations 225, payment confirmations, and records required by account reporting programs 240 including EFT transaction data.

In addition to sending payment approval to the dealer website 255, and sending to the account reporting program 240 payment confirmation, the PPP 227 sends the payment authorization 225 to the user's IPA account 230 so that it can be realized from the user through an EFT credit message on the EFT system 270. Transfer of actual funds from account 230 to dealer account 235 . The consumer bank 220 will require some form of authentication from the PPP 227 for payment authorization. This authentication can take the form of software verification, an encrypted PIN or the maiden name of the consumer when she was a girl. Once the bank 220 has authenticated that the message actually originated from the customer, the bank 220 can then perform payment authentication 225 .

In step 21, once the payment 225 is authenticated received, the user's bank 220 debits the user's IPA account 230, generating an EFT credit message for the total amount of the authorized payment. As mentioned above, EFT credit information is completely different from traditional EFT messages which are debit or reverse debit. Once generated, the EFT credit message is transmitted via the ATM exchange 270 to the dealer's VPL account 235 . Although credit instructions are illustrated in FIG. 2 as being handled directly by accounts 230 and 235, it is welcome that the records are actually handled by the messaging systems and processors of user bank 220, dealer bank 275 and EFT network 270. The EFT credit message is basically a guarantee of payment from the user's bank 220 (which borrows funds from the user's account 230) to the dealer's bank 275 (which funds are credited to the dealer's account 235). Settlement between banks 220 and 275 is normally one day for all outstanding credit and charges between banks 220 and 275, but cash is available from VPL account 235 upon receipt of an EFT message.

After the EFT credit message has been received by the dealer VPL 235, said receipt of the credit is detected by the dealer's account reporting program 245 (step 2J). In response to the credit check, account reporting program 240 preferably generates and stores payment records 245 in the same database in which purchase records 250 were stored in step 2H previously described. Although only a single payment record 245 is illustrated in FIG. 2, it is welcome that there may be two payment records for a single payment transaction. The first payment record 245 may be generated upon receipt of payment information 244 from the user PPP 227. The second payment record 245 can be generated when the EFT credit is actually received on the EFT system 270 .

Once the payment record 245 has been stored, it can be checked for consistency by the account reporting program 240 against the dealer purchase record 250 (step 2K). In this way, the account loop in the dealer's system can be closed in the event that the dealer's invoice (purchase record 250) matches the payment (payment record 245). Alternatively, the account reporting program 240 can check that the two payment records (one from the payment confirmation and one from the EFT credit information) match the purchase record 250 . Because of the Account Biller 240, the dealer has a product that allows for secure transaction fulfillment, auditing functionality, records management, and backup storage capabilities. Once the financial loop is closed after the dealer receives the payment record 245, the dealer can confidently ship the goods 260 to the customer in step 2L. Shipment of goods may be accompanied by physical shipment of items or electronic transmission of digital products such as music files.

In fulfillment of the guarantee established by the EFT credit message, at step 2M, between the user's bank 220 and the dealer's bank 275, funds are settled once a day via the EFT exchange 270. Typically, hundreds of thousands of such payments occur between banks 220 and 275, and for efficiency purposes, the actual net funds payable transfer of funds from one bank to the other is once a day. For example: a bank 220 may have secured US$10,000 in EFT credit messages from one hundred of its customers to another bank 275. On the same day, another bank 275 may have secured US$12,000 in EFT credits to the bank 220 from one hundred of its customers. After the end of the day, the bank 275 transmits only the difference, namely $2,000, to the bank 220, and each bank 220, 275 ensures that the appropriate account in its own bank has been debited or debited for the respective payment. It is easy to imagine that each bank performs this end-of-day settlement with hundreds of other banks, which is how the ATM system 270 currently handles funds transfers. Again on a daily basis, funds received in the dealer's VPL account 235 are automatically cleared into the dealer's cash concentration account 280, which can be a DDA or IPA account.

As is readily appreciated from the above, the PPP-enhanced e-wallet and virtual private lockbox 235 significantly enhance the shopping experience of consumers and dealers when used in online shopping. The present invention completely solves one of the biggest problems of the prior art, which is that customers are hesitant to provide their financial account information on the Internet. Instead of the dealer "pulling in" consumer account information and requiring authentication of the consumer, the PPP Enhanced Wallet 215 "pulls" EFT credit messages to the dealer's virtual dedicated lockbox without the dealer having to seek out the consumer account information. The transaction is virtual and instant, providing privacy and convenience to consumers and guarantees collection of funds, balance checks and supply documentation to dealers.

With regard to authentication, the consumer does not need to authenticate themselves to the dealer since the consumer is issuing their payment to the dealer or other entity or person, rather than the dealer pulling payments from the consumer's account. Instead, the customer authenticates himself to their own bank 220, which executes the EFT credit payment to the dealer's VPL account 235.

This method of the present invention is very attractive to consumers because they can pay any distributor without the need for a pre-existing relationship with that individual or entity. Furthermore, transactions can be conducted anywhere that can access the Internet. The IPA account 230 can be used and managed via a consumer's personal computer, web-enabled ATM, telephone, or any other web-enabled device. The Internet shopping payment method of the present invention is very easy to be adopted by online bank customers. This method provides consumers with the ability to process online purchases without providing any personal confidential financial information to unfamiliar resellers. This method allows the consumer to perform these financial transactions only with her or his own financial institution.

Also have many benefits about the dealer who adopts the method of the present invention to draw money. This approach opens up a whole new buyer/payer world where they would not have an online credit or charge card entry or desire to use an online credit or charge card. It also has fewer requirements on the dealer side, and the dealer only needs to publish its bank 275 and VPL deposit-only account 235 information on the website 255 or other public directories (see 335 in Figure 3). If the dealer is already using traditional credit card methods, the present invention can provide the dealer with significant savings in credit card processing costs, declined or fraudulent payment costs, and double payment costs. The present invention also provides dealers with the function of economically acceptable small payments.

Fig. 3 illustrates a second embodiment of the present invention, whose architecture is as described above, which can be used by users to pay anyone. The PPP 227 of the present invention provides the user with great flexibility. Anyone using PPP 227 can easily send funds to anyone with an IPA/VPL account. This transfer of funds is instant and at no cost to the client, and can be processed in a secure environment.

As previously described in connection with the Internet purchase mode in Figure 2, in the payment to anyone mode of Figure 3, in steps 3A-3C, the user logs on to the Internet, opens his browser (not shown in Figure 3 ) and activate the electronic wallet 215. In the preferred embodiment of FIG. 3, the electronic wallet 215 is a traditional wallet with a suitable interface to the PPP 227. When a user wants to activate the PPP 227, he needs to key in his user ID and password, whereby the user is authenticated and given access to their account 230 associated with the PPP 227. The user is then presented with their account balance information and can choose from several options including Shop Online, Pay Anyone, Pay Bills, Pay Anyone, Wallet, Review Account Activity, Edit Wallet Information or selected to customer service function.

In the embodiment shown in FIG. 3, the user selects the "Pay to Anyone" option from the menu, and in step 3D the user is presented with several options on the Pay to Anyone function menu screen. These options include: manually keying in a payee's VPL number, selecting a previous payee from a drop-down menu, adding/deleting/editing a payee from a drop-down menu, and accessing VPL's online directory of various payee directories (325) Options. In the particular embodiment of FIG. 3, the user enters (or selects) the payee's VPL address, the amount to pay and a description of the reason for the payment, which is optional.

In step 3E, the payment information described above is sent to the payee's electronic wallet 315 (or PPP 227, not shown). The payee's wallet 315 verifies the VPL number specified by the user and provides payment authorization. In step 3F, the payee's electronic wallet 315 confirms that its information is correct, and transmits a payment message to the user (payer), which has the following information: payee BIN, payee account number, transaction ID identification code, payment amount, and an optional note. In step 3G, upon receipt of the payment message, the user reviews the information and selects "Payable". Steps 3D to 3G are optional, since PPP 227 can unilaterally initiate the "push" function of EFT credit information without having contact with the recipient of the credit. In this blind rollout of credit, it is recommended that the online directory 235 be consulted by the PPP 227 to verify the accuracy of the address to which the EFT credit information will be sent.

In step 3H, the user PPP 227 sends a payment authorization 225 to the user's IPA account 230. In parallel, User PPP 227 transmits a Payment Confirmation of the desired payment to Payee's Wallet 315 or Account Reporting Program 340, which generates a desired payment record 350, which User PPP 227 certifies as described above, to allow User The bank 220 correctly identifies the payment authorization 225 . In step 31, the EFT credit message is sent from the user's IPA account 230 through the ATM exchange 270 to the payee's VPL 335. As noted above, the payee's VPL 335 may actually be a receive-only address for the IPA account maintained by the payee.

In an alternative embodiment, the verification message is first transmitted to the destination account 335 via the EFT network 270 . The purpose of the verification message is to verify the existence and identity of the VPL account 355 . In response to receipt of the verification message (assuming the VPL address is correct and the message was received), the VPL account sends back a response message that includes a textual description of the owner/user of the VPL account 335 . This response message can then be displayed to the user via the PPP 227 so that the user can verify that the account 335 to which the user is sending the credit is actually owned/used by the party the user is attempting to send the credit to.

This authentication procedure can be used in the Internet shopping mode described above in connection with FIG. 2 . In fact, the verification procedure helps to prevent any ambiguity in payment messages from dealers (225 in FIG. 2 ) or other payees (represented by e-purse 315 in FIG. Stealing attempt of VPL address in step 3 and step 2F) in Fig. 2. For example: If the payment message originates from AmaZon ^™ and includes the AmaZon's VPL 335 address, the verification process described above via the secure EFT 270 network will inform the user that the VPL 335 is really owned by AmaZon. If a thief (for example: Joe hacker) intercepts the payment message and enters the VPL address it owns, the response message according to the verification procedure will visually inform the user that the VPL address to which the credit will be sent is Owned by Joe Hacker. At this time, the user can give up the transmission of EFT credit and try to identify the real VPL address of AmaZon.

In an alternative verification procedure, PPP 227 may return the VPL address included in the payment message to the sender of the payment message (reseller 255 in FIG. 2 or e-wallet 315 in FIG. 3 ). The sender can then verify for itself that the user has the correct VPL address to which to send the credit. This alternative authentication procedure requires a hacker to truncate and alter 2 separate messages. While better than no authentication, this alternative procedure is still less absorbing than EFT Network 270 authentication because it takes place in the unsecured Internet space.

Returning to Figure 3, in response to receipt of the EFT credit message by payee VPL 335, payment record 345 is thus generated (step 3J). After receipt 345 of the payment record, the payee's e-wallet 315 or account reporting program 340 can check the actual payment record 345 and the expected payment record 350 at step 3K. Further in response to receipt of the EFT credit message, the payee's bank 375 credits the payee's VPL account 335 and the collected funds are immediately available to the payee. These funds can in turn be used to shop online, pay bills, make payments to anyone or can be withdrawn using cards at automated teller machines (ATMs) as described below.

At the end of the payment to anyone process, as in the preferred embodiment illustrated in FIG. 2, funds are settled once a day between the user bank 220 and the payee bank 375 (step 3M), and the funds can be cleared to Payee's DDA or other IPA account 380 (step 3N).

The payment-to-any procedure described above is a very attractive payment method for consumers. For example: Consumers may be purchasing items or services in response to a classified advertisement (electronic or traditional newspaper) or via an electronic auction site (eg: eBay ^™ ). In any of these instances, the consumer can obtain the payee's VPL account 335 information (eg: BIN; account number . . . ) in a variety of different ways. In one of these approaches, the consumer obtains this information electronically from a service website (eg, via eBay ^(TM )) with which it contacts the individual. Alternatively, the consumer may obtain the desired destination account information via offline methods (eg, traditional newspaper classifieds) or via email "pushed" to the consumer by the potential payee. Potential payees use these methods for protection because the VPL account 335 is a receive-only account and no one can access and fraudulently withdraw funds from the account. The user can further obtain payee-related information from the online directory 325, from a drop-down menu on an e-wallet 215, or by manually typing in the information.

Figure 4 illustrates a preferred embodiment of the invention which incorporates a physical card combined with a VPL or IPA account. In this embodiment, the physical card is linked to an IPA or VPL account that includes an initially established preset cash amount. This card is issued to IPA or VPL account users for users to access the IPA or VPL account in the physical world. Additionally, the card can be purchased from vending machines placed in e-commerce locations or other distribution outlets such as in shopping malls, convenience stores or banks. In a preferred embodiment, when a user builds a traditional e-wallet 215, the user is provided with the option to choose to build an IPA/VPL account, receive a PPP-enhanced e-wallet 215 and receive a combined IPA/VPL account physical card. After selecting this option, the card will be mailed to IPA/VPL users immediately.

In a vending machine embodiment, the card is purchased from a vending machine in which an increment of cash is pre-provided. These increments are combined with specific account number ranges and linked to IPA/VPL accounts. In a preferred embodiment, the physical card is pre-activated (ie, ready to use). Alternatively, the card can be activated automatically when it is paid out of the machine or by the customer calling a toll-free customer service line, or when the user uses the card for the first time. The act of purchasing a card at a vending machine establishes an IPA/VPL account for the purchaser. As an alternative to the default combination of card and account and amount, the association of card and account and the funds of the account can be automatically completed when the user purchases the card.

Once purchased, the cards are accepted by ATMs and dealers equipped with card readers. Because cards are protected with a PIN, they are safer than cash. The card has an IPA/VPL account number and an identification number PIN. This PIN is printed on a sticker that is attached to the back of the card when the card is issued. The account number is stored on the magnetic strip on the back of the card, and the VPL portion of the account associated with the card can receive EFT credit as described above, and can collect funds from other accounts mentioned above. The card can be used to withdraw cash at ATMs and can be purchased at any dealer that accepts charge cards.

For cards purchased by persons who did not previously have an IPA account, the card owner will be required to set up an IPA account with the card sponsor for subsequent rollouts using EFT credit as previously described. For example: if the sponsor is a bank, the user logs into the bank's website, and the new card owner enters the card number and personal identification code to synchronize the VPL with the user's latest IPA account. This sync will add the IPA account to the card link. The user can then indicate to which part of the account, IPA or VPL, a charge can be made when using the card. Users will also be asked to indicate whether any funds received by VPL will be cleared to a newly created IPA or to an existing DDA account.

A specific embodiment of purchasing and using a physical card is illustrated in FIG. 4 . In step 4A, the buyer selects a card from any vending machine 400 or ATM with vending function (not shown) or from other distribution channels. In a preferred embodiment, cards can be purchased in amounts as small as a dollar, or in larger increments like an ATM. After making a selection, the buyer is prompted to pay for the card. Several purchasing options are available, including cash, debit and credit cards.

In step 4B, the card is dispensed from the machine 400 with a pre-assigned PIN and instructions for using the card. The card can be pre-activated or alternatively, the vending machine 400 sends an activation message to the card issuer when the card is purchased, or the card is activated when it is used for the first time, or the user dials a phone call to the relevant unit for activation. the card. Distribution outlets (eg, vending machines) also provide purchasers with printed receipts that can be used in the event the user loses their physical card.

With the card in hand, the user can withdraw money from the account associated with the card or use the card to make purchases in stores. In step 4C, the card owner inserts the card into an automatic teller machine ATM 430 or a dealer's card reader at a dealer's point of sale. The user then enters his or her PIN to identify herself or herself as the true owner of the card. In step 4D, the dealer's card reader, which may be connected to the EFT network 270 , transmits the debit message via the EFT exchange 270 to the issuing bank 410 .

Similar to what was stated in FIG. 2 , debit messages are considered to be received directly by the user's VPL account 420 , but in practice it is realized that all EFT messages to and from the banking system 410 are made. The message is sent to the bank 410 as an online PIN debit transaction to the user's VPL account 420 . Upon verification that sufficient funds are available in the VPL account 420 associated with the requested card, the transaction is authorized by the VPL sponsor 410 and funds are debited from the balance of the VPL account. In step 4E, the authorization message is sent back to the ATM or point of sale POS 430 via the same EFT network 270, and the funds are released to the card owner (in the case of ATM withdrawals), or in step 4F Attributed to dealer (store purchase).

Figure 5 illustrates a preferred embodiment of the present invention in which a user can instantly send funds to anyone, especially anyone with a card and VPL account as described above. The payee (recipient of the funds) can use the physical card to withdraw money through the automatic teller machine, and the card can be known from the above, and the payee can purchase it at the vending machine or receive it by mail when the account is established. As with all embodiments of the invention, this pay-to-anyone feature ensures that the transaction takes place in a secure environment.

As previously described in conjunction with the embodiment of Fig. 2 and Fig. 3, in the method of paying anyone in Fig. 5, in steps 5A-5C, the user logs on to the Internet and opens his browser (not shown in Fig. 5 shown in ) and start its PPP 227. It is readily appreciated from FIG. 5 that a traditional electronic wallet 215 is not required to implement the important features of the present invention, as these features are enabled by the PPP 227. In Figure 5, the PPP 227 operates as an independent component. The PPP 227 requires the user to key in their user identification number ID and password, whereby the user is authenticated and accesses their PPP 227. The user is then presented with information about his account balance and can choose from several options, including shopping on the Internet, paying anyone, paying bills, electronic funds wallet and checking account activity. In the present embodiment shown in Figure 5, the user selects the Pay Anyone option from the menu at step 5D and is prompted for the VPL account number associated with the card. Then, follow the process described above in connection with the payment to anyone method of FIG. 3 .

In step 5E, the user PPP 2227 generates a payment authorization, which has the following information: payer BIN, payer VPL number (card number), transaction identification code ID and amount. After reviewing the information, the user then selects "OK to pay" on the screen of the workstation 200 (eg, personal computer, personal digital assistant, etc.). In step 5F, the user PPP 227 verifies the balance in the IPA account 230, and if there are sufficient funds in the account 230 to cover the transaction, authorizes the payment to the IPA 230. As an optional step, the payee information is verified (eg: the VPL account associated with the card is valid and is owned by the intended payee). In step 5G, the EFT credit message is sent from user bank 220 (IPA account 230) to payee bank 575 (VPL account 535) via ATM exchange 270.

The payee can use the above-mentioned physical card to withdraw funds through an automatic teller machine 500 . When a withdrawal request is made, a debit payment message is sent from the payee's VPL account 535 to the ATM 500 providing bank (not shown) in step 5H. Funds are now immediately available to the payer, and withdrawn in step 5I. Alternatively, the payee can use the card at the point of sale, POS, using the PIN debit procedure described above. As in the foregoing embodiments, funds are settled once a day between the payer's bank 220, the VPL user's bank 575 and the bank providing the automatic teller machine 500.

This embodiment is applicable in many different situations. For example: if a parent has a son or daughter who is studying at a foreign university, the father or mother provides the child's card and the relevant VPL account 535, and can use the present invention to transfer funds to the child's account 535 in a simple, fast and effective manner. Those skilled in the art will recognize that the above-described embodiments can be used by a customer of a bank to transfer funds to anyone, for example a gardener who transfers funds to his customer or a child at university as described above.

Figures 6, 7 and 8 illustrate three different embodiments of paying accounts according to the present invention. Figure 6 is an example of direct bill payment, Figure 7 is an account payment process involving a service provider integration, and Figure 8 illustrates a bill payment method for a customer to complete integration. In the direct method of FIG. 6 , the biller establishes electronic billing functionality on his own website 255 . Once registered in the service, the customer receives an email notification that there is a bill due at the biller's website 255 . Alternatively, the customer may receive a traditional paper bill. The customer activates their e-wallet 215, browser 210 and PPP 227, and then visits the biller's website 255. The final payment is sent from the PPP 227 to the biller's virtual private lockbox 235. As with all embodiments of the present invention, the transaction is secure, protects the privacy of the customer and provides functionality for the biller to protect the transfer of funds, reconciliation and storage of records.

As illustrated in FIG. 6, the biller/reseller first establishes an electronic billing relationship with its customer. One method that a dealer can take is to advertise its electronic billing service by e-mail, mail, or on the Internet. In step 6A, it is assumed that the user has registered for the electronic billing service at the biller's website 255 and receives monthly email notifications when bills are available. As previously stated, in step 6B, the user logs onto the Internet, activates his browser 210, e-wallet 215, and PPP 227, and is presented with various menu options. In step 6C, the user selects the "Pay Bill" option and is given various options in the Pay Bill menu screen, including "Pay Bill" and "Edit Billing Information." Select the "Pay Bill" option option, the user comes to the biller's website 255. It must be noted that the user's account information has been included in the electronic wallet 215 .

Since the website's electronic wallet 215 is in an available state, the biller's website 255 identifies the user as a customer of an electronic wallet 215 . In addition, the account issuer website verifies that the customer has an established electronic account relationship in step 6D. In step 6E, the account issuer website 255 generates and transmits a bill payment message to the user, which includes the following information: account issuer's BIN, account issuer's account number, transaction identification code ID and account payables. In step 6F, the account payment message is received by the wallet 215 window and displayed for review by the user. The user has a number of options including at least the option to edit the bill (for example: amount due) or to pay the presented bill.

If the user selects the "Pay Bill" option, the PPP 227 verifies the user's balance in his IPA account 230 and sends a payment verification 255 to the IPA account 230, while simultaneously sending a payment confirmation 244 to the biller/dealer The network station 255 or the VPL reporting program 240 (step 6G). As an alternative shown, the PPP 227 may send a payment confirmation 244 to the biller/dealer's website 255 or VPL reporting program 240. In response to receipt of payment authorization 255, an EFT credit message is sent from user IPA account 230 via ATM switch 270 to biller's VPL account 235 (step 6H). A bill payment record 245 is then generated and stored by the biller's account reporting program 240 in response to receipt of the credit message from the EFT network 270 .

In step 6J, the balance payment record 245 is checked against the biller's accounts receivable file 600 upon creation of the payment record 245 indicating receipt of funds to settle the bill. As previously described, in the case of the VPL account 235 and the account reporting program 240, the accounting dealer can perform secure transaction fulfillment, check all of its accounts, and store all records securely for easy retrieval at a later time . As described above in conjunction with other embodiments, funds can be settled once a day between the user bank 220 and the account issuer bank 275 (step 6K). Funds may be cleared to the account holder's DDA or cash concentration account 280 (step 6L).

FIG. 7 illustrates the account payment method involving the integration program of the service provider. The bill payment method is similar to the method described in FIG. 6 , however in this method a central service provider consolidates electronic bills from many different billers 700 . The service provider's website 755 enables customers to review and pay bills with some of their bill issuers (eg, electronic bills, phone bills, loans, etc.). Service providers are seamlessly equipped with archiving capabilities that allow customers to review their bill payment history. While VPL provides service providers (and their customers, billers/resellers) with guaranteed collections, balance checks, and record keeping, PPP 227 and IPA 230 once again provide consumers with privacy, Safe and convenient service.

In step 7A, the user registers for the electronic billing service on the website 775 of the customer service provider (CSP). The electronic billing relationship between the CSP and the user is established by directly responding to the advertisement made by the CSP or advertising the service of the CSP to the user (customer of the biller) via the biller 700 (customer of the CSP) . Upon registration (or later), the user selects which bills he wishes to receive and pay electronically via the CSP's services. The CSP may provide archiving services to the biller 700 to store transaction history, as well as a customer service unit to resolve transaction inquiries.

After registration, the user then begins to receive monthly email notifications when bills are generated from the user's selected biller 700 . The electronic bill can be sent from the CSP to the user or directly from the electronic bill issuer 700 . In this second method, the e-biller can provide the CSP with receivables files reflecting the e-bills it issues in order for the CSP to perform the procedure described below for the biller 700 balance checking procedure. If the CSP is the party that sends the electronic bill to the user, the electronic bill issuer 700 must provide the CSP with accounting information. Many types of record keeping methods are supported. Biller 700 can push billing information directly into the CSP's website, or alternatively, electronic bills can be directed to the CSP via Spectrum or other electronic Internet bill payment aggregation program.

Steps 7B and 7C are substantially the same as previously described for the direct bill payment embodiment of FIG. 6 . The only difference is that instead of navigating directly to the biller web site after selecting the "Pay Bill" option, the user navigates to the CSP's website 755 . In step 7E, the user can select the bills to be paid, and enter the amount to be paid on each bill (or select the default value, ie pay the full amount of all bills presented to the user). In step 7F, the CSP website 755 generates and transmits one or more bill payment messages to the user. In an embodiment, the CSP generates a single payment message that includes appropriate payment messages for all bills paid during the session. In an alternative embodiment, a separate payment message is generated for each bill paid by the user. In either preferred embodiment, the message will include: CSP's BIN, CSP's VPL account number, transaction identification code ID (or ID), biller's name and amount.

Steps 7F to 7L are the same as those described above for steps 6F-6L in FIG. 6 , and the same components will not be repeated here. Although only a single VPL account 735 is illustrated in FIG. 7, it should be appreciated that a CSP (or biller directly) may maintain one VPL account 735 for each biller. Whether they have a single VPL 735 or several, billers 700 themselves can view the contents of their receipts at the VPL 735 via the CSP's account reporting program 740. In step 7J, the CSP performs a balance check procedure for each of its customers (eg, biller 700). In step 7L, each biller's receipts may be cleared to their respective DDA or cash concentration account 780 .

Figure 8 illustrates a third bill payment embodiment involving customer consolidation. In this third bill payment method, the electronic bill 800 is sent directly to the customer in the form of email or other delivery means. Each electronic bill 800 includes a hot link that directs the customer to the biller's website 855 (or to the CSP's website, if the CSP handles payment for the biller). When a customer activates their e-wallet 215, the website 855 identifies the e-wallet 215 customer and initiates a payment message as previously described. The customer can then initiate payment to the biller in the same manner as in the Web site shopping embodiment of Figure 2, the Payment to Anyone embodiment of Figure 3, and the two Other bill payment embodiments introduce payment methods. As with all previous embodiments, the ticket issuer again receives the benefits of the present invention of guaranteed payment of funds, balance checking, and record keeping.

What Fig. 9 stated is the system and method for setting up an account combined with PPP 227 or PPP enhanced electronic wallet 215 and providing funds. As previously mentioned, the user's IPA account 230 can be accessed via PPP 227 or PPP enhanced electronic wallet 215, ATM 905, telephone 910, kiosk 915, personal computer 902, interactive television 904, or even a personal digital assistant (DPA) 920 etc., while PPP 227 or PPP enhanced electronic wallet 215 can be accessed via Internet 900 . The primary method of funding an account linked to a PPP 227 or PPP Enhanced Wallet 215 (eg, an IPA account 230) is through one of the user's other accounts (eg, a DDA, credit or charge card account) . In one embodiment, the PPP 227 or PPP Enhanced Wallet may receive funds from the user's other accounts using well-known online banking functions. Alternative funding support options may be made via an externally sponsored credit card in the form of a check or money order or through the AutoPay network.

Steps 9A to 9C illustrate how the user can create the electronic wallet 215 . As before, the preferred embodiment includes an online banking system 962 . The following example uses a virtual system operator, identified as XYZ Bank 265, which can act as a PPP-enhanced e-wallet provider. In step 9A, the user logs onto the Internet and uses their browser 210 to navigate to the XYZ Bank website XYZBank.Com 906. In step 9B, the user selects the "Electronic Wallet" option from the main menu on the XYZBank.Com website. On the "Electronic Wallet" screen, users will see two options: "Are you an online banking user?" and "Are you not a customer of XYZBank?" If the user selects "Online Banking Customer", The user is then presented with a list of accounts maintained by the user at XYZBank that are supported by online banking. The user then identifies the account to which the PPP Enhanced Wallet 215 will be linked. A new IPA account 230 can be set up for the new PPP enhanced e-wallet 215 if the user wishes. If the user selects "non-XYZBank customer", their PPP Enhanced Wallet 215 is linked to a newly created IPA account 230 at XYZBank 965 for that customer.

Next, the user creates a PPP enhanced wallet 215 for use by selecting "Create Website Wallet" from the menu at step 9C. Users are instructed that their PPP enhanced e-wallet will now be implemented as a button on the browser 210 toolbar. Once the PPP enhanced electronic wallet 215 software is installed on the user's system (for example: the user's personal computer or web server), the user is prompted to provide some background information that will help the user to make online purchases and payments . Examples of some background information required include the user's shipping name, address. At this point, the PPP-enhanced electronic wallet 215 is installed, and the user can execute any of the methods described in conjunction with FIG. 1 to FIG. 8 . As previously mentioned, using thin electronic wallet technology, the main software and data related to the PPP enhanced electronic wallet 215 resides on servers maintained by XYZBank 965.

Steps 9D through 9K illustrate two methods of funding the PPP Enhanced Wallet. For customers of XYZBank 965, the primary method of initial and subsequent funding of the PPP Enhanced Wallet 215 is via the link between the PPP Enhanced Wallet 215 and the Online Banking System 962 as described above. The link between PPP-enhanced e-wallet 215 and online banking 962 can be transparent, and users can individually log in to their PPP-enhanced e-wallet 215 , and can be seamlessly equipped with online banking 962 functions. To initially fund the PPP Enhanced Wallet 215, the user selects the "Move Funds To/From Wallet" option from the on-line banking menu. The user can then provide the following information: source of funds - check, credit card, deposit, etc., amount transferred, date the funds were provided and whether it was a single transfer or a recurring transfer. The account associated with the PPP Enhanced Wallet 215 is immediately funded after the above is completed. Subsequent funding of accounts integrated with the PPP enhanced e-wallet 215 can be done via the PPP enhanced e-wallet 215 itself or via the online banking system 962 . In addition to providing funds via online banking, instructions to provide funds may also be given via telephone 910 , automated teller machine 905 , kiosk 915 , personal digital assistant 920 , or interactive television 922 .

Steps 9E to 9J illustrate the method of funding the PPP Enhanced Wallet 215 from external credit (such as a cash advance from a credit card) or charge card, or an external DDA account (outside of XYZBank). For non-XYZBank customers or XYZBank customers who wish to fund the PPP Enhanced Wallet 215 externally, the user selects "Fund with non-XYZBank account" at step 9E. The user then selects the financial dealer for the account (eg, American Express ^(TM) , VISA ^(TM) , etc.) and enters the account number, card expiration date (if any) and the funds transfer amount. This request for funding is routed to the Dealer Acquisition Program 970 in conjunction with XYZBank 962 or a portion thereof. This account information is stored for future funding needs.

In step 9F, a merchant acquisition program 970 (eg, Chase Merchant Service ^™ ) authorizes the funding transaction and transmits the request via EFT exchange 270 . In step 9G, the financial dealer 980 (eg VISA ^™ ) receives the request to fund via the EFT exchange 270 and verifies the card number, expiration date and credit limit. Provided that the funding provision is authorized by the financial dealer (step 9H), the funds may be received by the PPP enhanced e-wallet 215, and more specifically, by the IPA/VPL account 230 linked to the PPP enhanced e-wallet 215 (step 9I) . Fund settlement between the credit card bank and the user's bank usually occurs once a day. A similar process occurs when funding is provided from a user's DDA account 980 at another financial institution. In the description above in connection with FIG. 9, it should be appreciated that the process of setting up and funding the PPP Enhanced Wallet 215 is equally applicable to setting up and funding the PPP Enhanced Wallet 215 as a stand-alone product.

While the invention has been described in conjunction with specific embodiments of the invention, many other modifications and other uses will be apparent to others skilled in the art. Therefore, the present invention should not be limited by the specific disclosure herein, but only by the spirit and scope of the disclosure.

Claims (55)

1. A method for receiving electronic payments, comprising the steps of: establishing a receive-only account, denoted as a Virtual Private Lockbox (VPL), said VPL having a first address; provide the payer with said VPL first address; and An electronic payment is received from the payer into the VPL via the first address. 2. The method of claim 1, wherein the step of receiving an electronic payment further comprises receiving the electronic payment in credit over an electronic funds transfer network. 3. The method of claim 2, wherein the electronic payment represents a unique credit rather than a reversal of a charge. 4. The method of claim 1, further comprising the step of disabling debiting from said account using the first address, whereby the first address may be published to facilitate receipt of credit into the account. 5. The method of claim 4, further comprising the step of establishing a second address through which funds can be transferred out of the account. 6. The method of claim 5, wherein the first address and the second address are different. 7. The method of claim 1, wherein the account is a bank account maintained with a bank. 8. The method of claim 1, wherein the account is maintained at an institution. 9. The method of claim 8, wherein the first address comprises an address of the institution. 10. The method of claim 1, further comprising the step of publishing the first address. 11. The method of claim 10, wherein the step of publishing further comprises placing the first address at a directory of an Internet site. 12. The method of claim 11, wherein the directory contains multiple addresses for multiple VPLs. 13. The method of claim 12, wherein the plurality of VPLs are associated with a plurality of commercial services. 14. The method of claim 1, wherein the VPL is associated with a user, the method further comprising reporting receipt of the electronic payment by the VPL to the user. 15. The method of claim 14, wherein the user maintains an Internet site, said reporting step further comprising reporting receipt of the electronic payment to said Internet site. 16. The method of claim 1, further comprising storing payment information for each electronic payment received by the VPL. 17. The method of claim 16, further comprising the step of viewing payment information. 18. The method of claim 16, wherein the payment information includes the source, date and amount of the electronic payment. 19. The method of claim 16, further comprising the step of classifying said payment information. 20. The method of claim 16, further comprising the step of editing payment information. 21. The method of claim 16, further comprising the step of retrieving payment information. 22. The method of claim 16, wherein the step of exporting payment information to an application software. 23. The method of claim 1, wherein the VPL is associated with the user, the method further comprising generating a desired payment record when the user desires to receive electronic payment by the VPL. 24. The method of claim 23, further comprising the step of: Report receipt of electronic payments as payment records. 25. The method of claim 1, wherein at least one of said received electronic payments originates from a payer, said method further comprising receiving payment from said payer confirming transmission of said at least one electronic payment confirm. 26. The method of claim 1, wherein payment confirmation is received via the Internet. 27. The method of claim 25, wherein payment confirmation is received by email. 28. The method of claim 25, further comprising generating a desired payment record when electronic payment is desired to be received by the VPL. 29. The method of claim 28, further comprising reconciling the desired payment record with the payment confirmation. 30. A method for dealers to receive electronic payments, comprising the steps of: Establish a receive-only account, denoted as a Virtual Private Lockbox (VPL), with the VPL having a first address for receiving electronic payments; Offer to sell goods or services on the Reseller's Internet site; sending payment information identifying the first address and the purchase price to the consumer who has selected the goods or services to be purchased; and The VPL receives electronic payment from the customer in the amount of the purchase price. 31. The method of claim 30, wherein the step of receiving an electronic payment further comprises receiving the electronic payment via an electronic funds transfer network. 32. The method of claim 30, further comprising generating an account receivable record after sending the payment information, the account receivable record identifying the customer and the purchase price. 33. The method of claim 32, further comprising the step of receiving a payment confirmation from the customer, the payment confirmation confirming sending of the electronic payment. 34. The method of claim 33, further comprising reconciling the payment receivable record with the payment confirmation. 35. The method of claim 33, further comprising the step of releasing said selected goods to a customer after receiving confirmation of payment. 36. The method of claim 35, wherein said selected goods are digital in nature, said step of assigning goods further comprising the step of sending said selected goods to a customer via the Internet. 37. The method of claim 35, wherein said selected goods are physically physical, said step of transferring goods further comprising the step of: Inform the warehouse about the assignment of the goods; Contact shippers to arrange shipment of selected shipments. 38. A Virtual Private Lockbox (VPL) account system comprising: access to the first address of the VPL account, the first address being a receive-only address for receiving electronic payments into the VPL account; and A second address to withdraw funds from the VPL account, where the second address is only accessible by the administrator of the VPL account. 39. The account system of claim 1, wherein the first address is accessible via an electronic funds transfer network over which the electronic payment is received in credit by the first address. 40. The account system of claim 39, wherein the electronic payment represents a unique credit rather than a reversal of a charge. 41. The account system of claim 38, wherein said supervisor is a bank. 42. The account system of claim 38, further comprising a third address to access the VPL account, wherein a user of the VPL account has access to the third address to transfer funds from the VPL account. 43. The account system of claim 42, wherein the first address, second and third addresses are different. 44. The account system of claim 38, wherein said VPL account is a bank account maintained with a bank. 45. The account system of claim 38, wherein said account is maintained at an institution. 46. The account system of claim 45, wherein the first address includes an address of the institution. 47. The account system of claim 38, further comprising an account reporting module associated with the VPL account, said account reporting module reporting receipt of electronic payments by the VPL account. 48. The account system of claim 38, further comprising: transactional databases; and An Account Reporting Module coupled to the VPL Account and a transaction database, the Account Reporting Module storing payment information in the transaction database for each electronic payment received by the VPL Account. 49. The account system of claim 48, wherein the account reporting module allows viewing of payment information stored in the transaction database. 50. The account system of claim 48, wherein the payment information includes the source, date and amount of the electronic payment. 51. The account system of claim 48, wherein the account reporting module is capable of sorting payment information stored in the transaction database. 52. The account system of claim 48, wherein the account reporting module is capable of compiling payment information. 53. The account system of claim 48, wherein the account reporting module is capable of retrieving payment information stored in the transaction database. 54. The account system of claim 48, wherein the transaction database stores records of expected payments when electronic payments are expected to be received by the VPL. 55. The account system of claim 54, wherein the account reporting module reconciles expected payment records to payment confirmations.

Images