WO2001050391A1 - Methods for managing transactions over the internet by proxy and with single-use financial instruments - Google Patents

Methods for managing transactions over the internet by proxy and with single-use financial instruments Download PDF

Info

Publication number
WO2001050391A1
WO2001050391A1 PCT/US2000/035680 US0035680W WO0150391A1 WO 2001050391 A1 WO2001050391 A1 WO 2001050391A1 US 0035680 W US0035680 W US 0035680W WO 0150391 A1 WO0150391 A1 WO 0150391A1
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
consumer
payment
web site
transaction
Prior art date
Application number
PCT/US2000/035680
Other languages
French (fr)
Inventor
Dennis W. Andrews
Brian L. Hoshiko
Thomas E. Fedro
Arthur Blank
Original Assignee
Ecatalystone.Com, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ecatalystone.Com, Inc. filed Critical Ecatalystone.Com, Inc.
Priority to AU29150/01A priority Critical patent/AU2915001A/en
Publication of WO2001050391A1 publication Critical patent/WO2001050391A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits

Definitions

  • the present invention relates to the electronic commerce over a communication network such as the Internet and, more specifically, to systems for securely exchanging monetary value for goods and services purchased over the Internet.
  • the present invention relates to systems for managing economic exchange between merchants and consumers through the use of a proxy server so that merchant servers do not need to be directly accessed by consumers.
  • the present invention is particularly beneficial for consumers with limited credit resources and merchants with restrictive acceptable modes of payment.
  • EFT electronic funds transfer
  • Electronic funds transfer is essentially a process of value exchange achieved through a banking system's centralized computer transactions.
  • EFT services are a transfer of payments utilizing electronic checks, which are used primarily by large commercial organizations.
  • EFT systems utilized by retail and commercial organizations include an automated clearing house (ACH) where a user can enter a pre-authorized code and download information with billing occurring later, and a point-of-sale (POS) system where a transaction is processed by connecting with a central computer for authorization for the transaction granted or denied immediately.
  • ACH automated clearing house
  • POS point-of-sale
  • the payments made through these types of EFT systems are limited in that they cannot be performed without the banking system.
  • Current EFT systems, credit cards, or debit cards which are used in conjunction with an on-line system to transfer money between accounts, such as between the account of a merchant and that of a customer, cannot satisfy the need for an automated transaction system providing an ergonomic interface.
  • a computer operated under the control of a merchant it is desirable for a computer operated under the control of a merchant to obtain information offered by a customer and transmitted by a computer operating under the control of the customer over a publicly accessible packet-switched network (e.g., the Internet) to the computer operating under the control of the merchant, without risking the exposure of the information to interception by third parties that have access to the network, and to assure that the information is from an authentic source.
  • a publicly accessible packet-switched network e.g., the Internet
  • the payment processing it is further desirable for the payment processing to be flexible and able to negotiate with the client customer to select a mutually acceptable payment protocol and other payment options.
  • SET Secure Electronic Transaction
  • Other such secure payment technologies include Secure Transaction Technology (STT), Secure Electronic Payments Protocol (SEPP), Internet Keyed Payments (iKP), Net Trust, and Cybercash Credit Payment Protocol.
  • STT Secure Transaction Technology
  • SEPP Secure Electronic Payments Protocol
  • iKP Internet Keyed Payments
  • Net Trust Net Trust
  • Cybercash Credit Payment Protocol a secure payment technology known as the Secure Electronic Transaction (SET)
  • STT Secure Transaction Technology
  • SEPP Secure Electronic Payments Protocol
  • iKP Internet Keyed Payments
  • Net Trust Net Trust
  • Cybercash Credit Payment Protocol Such secure payment technologies require the customer to operate software that is compliant with the secure payment technology, interacting with third-party certification authorities, thereby allowing the customer to transmit encoded information to a merchant, some of which may be decoded by the merchant, and some which can be decoded only by a payment gateway specified by the customer.
  • SSL Secure Sockets Layer
  • Netscape, Inc. provides a means for secure transmission between two computers.
  • SSL has the advantage that it does not require special-purpose software to be installed on the customer's computer because it is already incorporated into widely available software that many people utilize as their standard Internet access medium, and does not require that the customer interact with any third-party certification authority. Instead, the support for SSL may be incorporated into software already in use by the customer, e.g., the Netscape Navigator browser.
  • a computer on an SSL connection may initiate a second SSL connection to another computer, a drawback to the SSL approach is each SSL connection supports only a two-computer connection.
  • SSL does not provide a mechanism for transmitting encoded information to a merchant for retransmission to a payment gateway such that a subset of the information is readable to the payment gateway but not to the merchant.
  • SSL allows for robustly secure two-party data transmission, it does not meet the ultimate need of the electronic commerce market for robustly secure three-party data transmission.
  • Other examples of general-purpose secure communication protocols include Private Communications Technology (PCT) from Microsoft, Inc., Secure HyperText Transport Protocol (SHTTP) from Theresa Systems.
  • Internet-based payment solutions require security measures that are not found in conventional point-of-sale (POS) terminals. This additional requirement is necessitated because Internet communication is done over publicly accessible, unsecured communication lines, which is in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional merchant and an acquiring bank. Thus, it is critical that any solution utilizing the Internet for a communication backbone employ some form of cryptography.
  • Prepaid instruments in use today are a variant of one of (or combination of several of) the following devices: prepaid phone and access cards, debit cards, and money orders and gift certificates.
  • Most Debit Cards are predicated on a credit system or linked to an existing bank account.
  • Internet purchase schemes are predominantly credit systems.
  • a number of online purchase schemes utilize an electronic wallet that is filled (i.e., funded) and refilled from a credit source. This is synonymous to certain toll-road systems that debit a credit account periodically to pay in advance for toll road use that is often electronically sensed.
  • Internet purchasing schemes to date are all credit or bank account based due to the inability to collect cash over the wire.
  • a method manages transactions on the Internet between a consumer and a merchant by proxy.
  • the consumer has a computer with a browser for displaying a portal web site
  • the merchant has a merchant web site hosted by a merchant server.
  • the portal web site has a link associated with the merchant web site.
  • the method includes providing to the consumer access to the merchant web page via a proxy server. Access is provided to the merchant web page via the portal web page an the proxy server without the consumer directly accessing the merchant server.
  • access is provided to a payment page on the proxy server for the consumer, and funds are secured for the purchase from the consumer. Funds are then transferred to the merchant for the transaction.
  • the proxy management system and methodology of the present invention has a number of advantages.
  • the consumer is not restricted to making a payment according to the merchant's modes of payment. If, for example, a merchant only accepts checks or money orders, a consumer may carry out the transaction with a credit card or a prepaid account with the proxy server, with the proxy server, in turn, generating a check or money order for the merchant.
  • the proxy server may be configured to automatically determine the preferred mode(s) of payment accepted by the merchant.
  • the proxy management system may generate revenue either by deducting a service fee when transferring funds from the consumer to the merchant or by receiving a service from, e.g., an affiliate fee, from the merchant for each transaction.
  • Another advantage of the present invention is that the consumer is able to carry out transactions without directly accessing merchant servers.
  • the consumer is able to access and browse a merchant web site within the portal web site via the proxy server as if the consumer were actually connected directly to the merchant server. This is accomplished by configuring the proxy server to map in real time the merchant web page in response to browsing by the consumer. Accordingly, the billing and payment information of both the consumer and the merchant remain anonymous to the other party
  • a method for managing transactions on the Internet between a consumer and a merchant first enables the consumer to access a merchant web page on a proxy server such that a merchant server is inaccessible to the consumer. A transaction is then managed between the merchant and the consumer on the proxy server such that the merchant server is inaccessible to the consumer. Funds received from the consumer are then transferred to the merchant based upon a value of the transaction.
  • a method for making purchases from a merchant over the Internet includes accessing a portal web page and then accessing a merchant web page on the portal web page via a proxy server, such that a merchant server is not directly accessed by the consumer. A transaction is then initiated with the merchant via the portal web page such that the merchant server is not directly accessed. Funds are then caused to be transferred to the merchant based upon a value of the transaction.
  • a method manages transactions on the Internet with between a consumer and a merchant accepting a single-use financial instrument as payment for a transaction.
  • financial instruments include checks, money orders, and one-time credit card numbers.
  • the merchant has a merchant web site with payment information associated with the transaction.
  • the method includes first capturing the payment information from the merchant web site.
  • the capturing of the payment information is preferably carried out on a proxy server as part of a transaction management system.
  • the consumer may access the proxy server by, for example, activating a link on the merchant web page. Funds are then secured for the transaction from the consumer, thereby causing a single-use financial instrument to be generated and transmitted to the merchant.
  • the transaction management system and methodology of the present invention has a number of advantages.
  • the consumer is not restricted to making a payment according to the acceptable modes of payment of the merchant, that is, with a check or a money order.
  • a merchant may carry out the transaction with a credit card or a prepaid account with the proxy server of the management system, with the proxy server, in turn, generating money order for the merchant.
  • the proxy server may be configured to automatically determine the preferred mode or modes of payment accepted by the merchant. If the consumer has a prepaid account with the management system, then this account may be automatically debited when the transaction takes place. Accordingly, the merchant is guaranteed of a fast and reliable payment in accordance with its acceptable mode of payment.
  • a method carries out a transaction on the Internet with a merchant that accepts a single-use financial instrument as payment.
  • a consumer first accesses a proxy server of a management system, for example, by activating a link on a merchant web page or by directly typing a URL address in the browser.
  • the consumer then causes the proxy server to capture payment information from the merchant web site, which information may include mode of payment, price, tax, shipping, etc.
  • the consumer then causes funds for the transaction to be transferred to the management system, thereby triggering the generation of a single-use financial instrument and the transferring of the single-use financial instrument to the merchant.
  • a consumer is not required to make payment on a transaction according to a merchant's acceptable modes of payment if those modes of payment are single-use financial instruments. Rather, a consumer may carry out the transaction according to his or her preferred payment methods.
  • FIG. 1 is a block diagram of an exemplary e-commerce system according to the present invention in which prepaid monetary instruments are utilized by a system for managing transactions between consumers and e-merchants;
  • FIG. 2 is a schematic representation of a prepaid monetary instrument configured according to a preferred embodiment of the invention
  • FIG. 3 is a flow chart illustrating exemplary methodology for managing anonymous transactions over a network with prepaid monetary instruments in accordance with the present invention
  • FIG. 4 is a block diagram of an management system configured in accordance with an exemplary embodiment of the present invention.
  • FIGS. 5A and 5B are a schematic representations of Internet activation browser windows exemplifying principles of the present invention.
  • FIG. 6 is a schematic representation of an e-merchant verification browser window exemplifying principles of the present invention
  • FIG. 7 is a block diagram of an exemplary e-commerce system according to the present invention in which transactions between consumers and merchants are carried out by proxy;
  • FIG. 8 is a flow chart illustrating exemplary methodology for managing transactions over the Internet by proxy in accordance with the present invention
  • FIG. 9 is a schematic representation of a proxy payment browser window exemplifying principles of the present invention.
  • FIG. 10 is a flow chart illustrating exemplary methodology for managing check and money order transactions over the Internet in accordance with the present invention.
  • the present invention provides in general apparatus and associated methodology for managing transactions between consumers and merchants over the Internet. These apparatus and methods include plural preferred embodiments, a number of which are described below. Those skilled in the art will appreciate that the following description provides foundation for many other embodiments that fall within the broad principles of the present invention as set forth in the appended claims.
  • FIG. 1 an exemplary embodiment of an e-commerce system according to the present invention is shown in FIG. 1 and is indicated generally by reference numeral 50.
  • exemplary e-commerce system 50 includes a management system 52 that is configured to allow anonymous transactions to take place between consumers 54 and merchants 56 over a network 58 such as the Internet. More specifically, through the use of prepaid monetary instruments purchased at one or more distributors 60, exemplary management system 52 enable consumers 54 to purchase goods and services from the merchants 56 with complete anonymity. In addition, exemplary management system 52 guarantees that the merchants 56 receive funds for goods and services provided without the drawbacks of conventional financial-transaction instruments such as credit cards. In a preferred embodiment, the management system 52 of the present invention provides cash-like and real-time transactions for purchases made on the Internet.
  • Exemplary instrument 62 includes information specific thereto, for example, a denomination or monetary value 64 and a security code 66 such as a serial number.
  • exemplary instrument 62 may include one or more enablement means, such as a barcode 72 and/or a magnetic strip 74, which will be discussed in more detail below.
  • the instrument 62 of the present invention also includes an area 76 for graphics and text.
  • exemplary instrument 62 is preferably configured on a card-like body 78 for easy transport and familiarity.
  • Exemplary instrument 62 may be preprinted or, alternatively, may have the monetary value 64 and the security code 66 printed at the time and place of the sale.
  • exemplary e-commerce system 50 generally includes a plurality of consumers 54a, 54b, 54c, ..., 54k each with access to a computer 80a, 80b, 80c, ..., 80/ connected to the network 58.
  • Each consumer 54 has direct access to a plurality of distributors 60a, 60b, 60c, ..., 60m of the instruments 62 and network access via a respective computer 80 to the management system 52 and a plurality of participating web merchants 56a, 56b, 56c, ..., 56M.
  • the network 58 may include the Internet 81 and an instrument services network 82, which is discussed in more detail below.
  • each consumer 54 purchases an instrument 62 from any one of the distributors 60 (step 83).
  • the plurality of distributors 60 may include retail establishments, convenience stores, department stores, post offices, dedicated kiosks, and so on.
  • the plurality of distributors 60 may include unattended devices, such as vending machines.
  • the distributor 60 making the sale of the instrument 62 receives funds (step 84) from the consumer 54 in the amount of a desired monetary value 64. An additional service charge may be added in the sale of the instrument 62.
  • the distributor 60 then enables the instrument 62 (step 86), which may be accomplished in any number of ways.
  • the barcode 72 may be optically scanned, or the magnetic strip 74 may be swiped through a reader such as a standard Verafone ® interface.
  • the information specific thereto i.e., the monetary value 64 and the security code 66, is transmitted via the network 58 to the management system 52 (step 88).
  • the enablement of the instrument 62 preferably takes place across the instrument services network 82 of the system network 58.
  • the information transmitted by the distributor 60 is received by the management system 52 (step 90) at an instrument services gateway 92 which, in turn, sends the information to an enablement processor 94 which triggers an electronic transfer of funds (step 96).
  • the distributor 60 electronically transfers funds (step 98) to the management system 52, and an enabled account is established (step 100) for the instrument 62 via an enablement application program interface (API) 102.
  • Enablement of an instrument 62 changes an account specific to the instrument from a pending status to an enabled status.
  • Data associated with instruments 62 with accounts having an enabled status may be stored on an instruments data structure 104, and data associated with the transfer of funds from the distributors 60 may be stored on a distributor data structure 106.
  • the distributor 60 may provide the monetary value 64 of the instrument 62, and the management system 52 may confirm the enablement of the instrument 62 with the distributor 60 and verify the monetary value 64.
  • a consumer 54 with an enabled instrument 62 then needs to activate the instrument 62 (step 108). To do so, the consumer 54 accesses an activation website (step 110) with a computer 80.
  • the activation website may be part of a general customer website 112 maintained by the management system 52. Alternatively, the activation website may be a frame within a website of a distributor.
  • a first activation window 114 is displayed on the consumer's computer 80 which prompts the consumer 54 for the security code 66 of the instrument 62 (step 116).
  • the first activation window 114 may include fields for this information, as indicated by reference numeral 118.
  • the consumer 54 may then activate a SUBMIT icon 120 to provide the security code 66 to the management system 52 (step 122).
  • the management system 52 Upon receipt of the security code 66, the management system 52 causes a second activation window 124 as shown in FIG. 5B to be displayed on the consumer's computer 80 which prompts the consumer 54 for a user ID and a password (step 125).
  • the second activation window 124 may include fields for this information, as indicated by reference numerals 126 and 127, respectively.
  • the second activation window 124 also includes fields for prompting the consumer for a challenge phrase and a challenge response, as indicated by reference numerals 128 and 129, respectively, which will be discussed in more detail below.
  • the consumer 54 may then activate a SUBMIT icon 130 to provide the user ID and the password to the management system 52 (step 131).
  • the management system 52 receives the user ID and the password by an account activator 132, as shown in FIG. 4.
  • an account activator 132 As shown in FIG. 4.
  • an activation API 134 the enabled account associated with the instrument 62 is activated (step 136); that is, the enabled status of the account is changed to an active status.
  • Data associated with the activated account of the instrument 62 may be stored on an active accounts data structure 138.
  • a consumer 54 With the account associated with an instrument 62 activated, a consumer 54 is free to shop on-line at any merchant with a website connected to the network 58 and set up to accept payment with the instrument 62 of the present invention. To do so, the consumer 54 accesses a merchant website (step 140) to shop for goods and services. When the consumer 54 has decided upon a desired selection of goods and/or services, a purchase is initiated (step 142) from the merchant's website. When a purchase is initiated, the merchant 56 preferably redirects the consumer 54 to the management system 52 (step 143). A secure handshake between the customer 54 and the management system 52 may be established.
  • a verification window 144 may be displayed on the consumer's computer 80 which prompts the consumer 54 for the user ID and the password (step 146).
  • the verification window 144 may include fields for this information, as indicated by reference numerals 148 and 149, respectively.
  • the verification window 144 may also include a field for prompting the consumer for the challenge phrase and the challenge response, similar to that shown in FIG. 5B. This is particularly useful as added security if a prepaid instrument 62 is lost or stolen, or if the consumer is utilizing a computer 80 other than that used to activate the account associated with the prepaid instrument.
  • the consumer 54 may then activate a SUBMIT icon 152 to provide the user ID and the password to the management system 52 (step 154).
  • the management system 52 Upon receiving the user ID and the password, the management system 52 generates and transmits a query to a transaction engine 160.
  • the transaction engine 160 validates the user ID and the password and correlates this information with active account information in the active account data structure 138 through a prepaid transaction API 164. The funds in the account are then verified (step 166).
  • a funds signal is generated and transmit (step 168) to the merchant 56.
  • the funds signal contains information indicative of whether or not sufficient funds are in the account to cover the purchase.
  • the merchant 56 Upon receipt of the funds signal (step 170), the merchant 56 proceeds with the transaction if sufficient funds are available (step 172). If sufficient funds are not available, the management system 52 may query the customer 54 for alternative or addition payment options, such as a credit card to cover the deficit. The merchant 56 then transmits a verification (step 174) to the customer 54 that the transaction has taken place. Upon receipt of the verification (step 176), the customer 54 may continue shopping with the instrument 62 if funds remain in the account (step 178). Upon completing the transaction, the merchant 56 may send a purchase signal (step 180) to the management system 52 which, upon receipt (step 182), debits the account (step 184) of the instrument 62 associated with the transaction.
  • a purchase signal step 180
  • the management system 52 may then transfer funds (step 186) to the merchant which, upon their receipt (step 188), completes the anonymous transaction between the customer 54 and the merchant 56.
  • the amount of funds transferred to the merchant 56 is based upon the purchase price and may be reduced by a service charge of the management system.
  • the management system 52 may debit the account of the prepaid instrument 62 prior to transmitting the funds signal in step 168.
  • One of the advantages of the management system 52 of the present invention is that purchases made by a customer may be batched or pre-authorized.
  • a merchant 56 batches multiple purchases made during a single on-line session with a consumer 54. To do so, an advance is established by completing a secure handshake between the merchant 56 and the management system 52 and between the merchant 56 and the consumer 54. When the shopping session is complete, the total amount is communicated to the management system 52 and the consumer 54 to finalize the transaction.
  • This embodiment is particularly useful for merchants who specialize as content or information providers. Such merchants require micropayments for various informational units. Micropayments are small payments that are not suitable for credit-based purchase schemes, examples of which include $0.25 for a download of a piece of intellectual property and $1.50 for two viewing/use rights for an on-line service such as financial information from a financial website.
  • exemplary management system 52 is configured to allow the combining of the accounts of multiple instruments into a single account. For example, if a single consumer 54 has purchased several instruments and has used these instruments such that a small balance remains in the account of each, then the consumer 54 may combine these multiple accounts into a single account that can be used analogously to a new account. In other words, Account 1 through Account x may be combined into Account x+1. Accounts 1 through x would then be empty and marked idle.
  • This account combination feature of the management system 52 may be carried out by a customer query handler 190 and an account services API 192.
  • a data structure 194 dedicated to quiet and closed accounts may be provided to house data associated with the accounts comprising the combined account.
  • customer query handler 190 may be configured to enable a consumer to move or transfer funds from one account to another.
  • the management system 52 of the present invention may be configured to allow the parsing or splitting of one account into several accounts. Parsing provides an effective way to disperse of a remaining balance in an account, and may be carried out by the customer query handler 190.
  • the management system 52 of the present invention may also include a data structure 196 for housing data relevant to each of the merchants 56 of the network 50.
  • the management system 52 may organize the merchant 56 into categories according to, for example, the type of goods or services being sold, the target consumer (e.g., teens, adult only, etc.), and the type of offerings (e.g., information, soft services, or hard goods).
  • the target consumer e.g., teens, adult only, etc.
  • the type of offerings e.g., information, soft services, or hard goods.
  • a "card for minors” may be enabled that is restricted to merchants 56 that have been so categorized. As new merchants 56 come on-line and meet the qualifications, they may be added to this category of merchants and available to the "cards for minors," as well as to all newly issued cards.
  • This categorization of merchants 56 is preferably monitored and maintained current. If an existing participating merchant changes its offerings goods and/or services in such a way that it would change its categorization, then such a change may be detected and updated for existing accounts, as well as new accounts. This monitoring and updating may be accomplished by the combination of the object class library classification and an automated "web crawling" of each merchant 56. This form of electronic inspection may be performed periodically (e.g., daily) against all participating merchants 56. The activated instruments 62 may then be enabled or disabled according to the current classes of merchants 56.
  • exemplary management system 52 may also provide a website 198 for access by the merchant 56 of the system 50.
  • a merchant query handler 200 and a merchant SVC 202 in communication with the merchant data structure 196 may be configured to handle queries from merchants 56 as to status of there respective accounts with the system.
  • the accounts of the management system 52 may be classified according to status. For example, accounts may be allocated by the security codes or a block of security codes to a particular distributor 60. The allocation of accounts within the management system 52 allows a distributor 60 to design and manufacture unique instruments 62.
  • a pending account indicates an account that is on-line in the system 52 and awaiting enablement.
  • An enabled account indicates that the account has been purchased and enabled and is awaiting activation.
  • An activated account also as discussed above, indicates that the account has been activated by the consumer 54 on the customer website 112.
  • An account may acquire a quiet status if the account balance goes to zero (or effective zero) and/or has seen not activity for a predetermined amount of time, for example, three months.
  • an account may acquire a complete status if the account has been quiet for an extended predetermined amount of time, for example, at least 24 months with a balance or six months with no effective balance.
  • the active accounts data structure 138 and the quiet/closed accounts data structure 194 may include data related to each of these accounts.
  • the enablement processor 94 processing a signal from a distributor 60 received via the network 58.
  • the signal from the distributor 60 includes the information, i.e., the monetary value 64 and the security code 66, of the prepaid instrument 62.
  • the enablement processor 94 then causes an account associated with the prepaid instrument to be enabled based upon the information.
  • the account activator 132 then receives a signal from a customer 54 via the network 58.
  • the signal from the customer 54 includes at least the security code, the user ID, and the password.
  • the account activator 132 then causes the enabled account associated with the security code to be activated in association with the user ID and the password.
  • the transaction engine 160 then processes a signal from including information regarding a purchase and a password.
  • the transaction engine 160 causes a verification of funds in the active account associated with the received user ID and password and causes a signal to be generated and transmitted to the merchant 56 as to whether the account associated with the password has sufficient funds to cover the purchase.
  • the transaction engine 160 then receives and processes a second signal from the merchant 56, with the second signal including information indicative of whether the purchase took place.
  • the transaction engine 160 causes funds to be transferred to the merchant 56 based upon a value of the purchase.
  • the foregoing methodology may be implemented in software modules including a plurality of code segments.
  • the software may include code segments for processing the signal from the distributor and for enabling the account associated with the prepaid instrument 62 in the enablement processor 94.
  • code segments may be configured to activate the account and associate the account with a user ID and a password received by the account activator 132. Additional code segments may be configured for processing the signal from the merchant 56 to the transaction engine 160, including code segments for prompting the consumer for the user ID and the password associated with the instrument, for verifying sufficient funds, for generating the signal, and for causing the signal to be transmitted to the merchant as to the same.
  • the software may also include other code segments for processing the second signal from the merchant 56 and for causing funds to be transferred to the merchant based upon a value of the purchase.
  • Exemplary e-commerce system 250 includes a proxy management system 252 for managing transactions between a consumer 54 and a merchant 56 by proxy.
  • Exemplary proxy system 252 includes a proxy server 254 and a portal web site 256.
  • the proxy server 254 is configured to be accessible to the consumer 54 by a computer 80 with a web browser 257 and to one or more merchant servers 258 via the Internet 81.
  • Each merchant server 258 is configured to host one or more merchant web sites 118.
  • the portal web site 256 may be hosted by the proxy server 254 if desired or, alternatively, by another server, such as a portal server 259 or a server of a distributor as discussed above.
  • FIG. 7 For clarity, only a single consumer and merchant are shown in FIG. 7, although a plurality of each are contemplated analogous to that shown in FIG. 1.
  • the consumer 54 is able to carry out transactions with the merchant 56 without needing to access the merchant server 258 directly.
  • a proxy system has a number of advantages.
  • the consumer 54 may establish a prepaid account with the proxy management system 252 and then use funds in the prepaid account to carry out transactions with merchants 56.
  • the consumer 54 need not be concerned with the payment modes (i.e., credit card, check, money order, etc.) of each merchant 56, because the proxy server 254 acts as a middleman between the consumer 54 and the merchant 56. In other words, regardless of the modes of payment accepted by the merchant 56, the consumer 54 may use any type of desired mode of payment, and vice verse.
  • the payment modes i.e., credit card, check, money order, etc.
  • a consumer 54 first accesses the portal web site 256 with a computer 80 (step 260), which site is hosted by a server other than that of the merchant server 258, e.g., the portal server 259.
  • the consumer 54 may then access any merchant web site 118 (step 264) via the portal web site 256, e.g., by clicking on a link on the browser 257.
  • This causes the server hosting the portal web site 256 to communicate with the proxy server 254 to request the desired merchant web site.
  • the proxy server 254 then connects with the merchant server 258 (step 266) hosting the desired merchant web site 118 (step 268), and retrieves the merchant web site 118 (step 270).
  • the merchant web site 118 is now presented to the browser 257 of the consumer 54. This may be accomplished by the proxy server 254 first parsing the merchant web site 118 and then sending web pages of the site 118 to the browser 257. The consumer 54 may now view the merchant web site 118 (step 271).
  • the proxy server 254 is configured so that the consumer 54 is able to view, navigate, and browse the merchant web site 118 (step 272) within the portal web site 256 via the proxy server 254 as though the consumer computer 80 were connected directly to the merchant server 258.
  • the proxy server 254 is configured to modify and update the merchant web site 118 (step 274) in real time in response to browsing by the consumer 54 which, for the purposes of this description, is called "mapping." For example, as the consumer 54 activates links within a web page of the merchant web site 118, the proxy server 254 presents the new links as provided by merchant server 258 (step 275) by parsing the merchant web site 118 in real time. The web pages associated with the activated links are then mapped to the browser 257 on the consumer's computer 80.
  • the proxy server 254 captures payment information (step 277) provided by the merchant 56 (step (278), which information may include price, tax, shipping and handling costs, and so on.
  • the proxy server 254 then provides a proxy payment page or window (step 280) to the browser 257, an example of which is shown in FIG. 9 and indicated by reference numeral 282.
  • Exemplary proxy payment page 282 may include a number of payment fields, for example, a mode of payment field 284 and a shipping field 286, and a submit icon 288.
  • the consumer 54 completes the necessary payment fields and submits the information to the proxy server 254 (step 290).
  • the proxy server 254 then secures funds (step 292) in accordance with the mode of payment 284 selected by the consumer 54. For example, if the selected mode of payment was a credit card, then the proxy server 254 may present the consumer 54 with a web page that secures funds by credit card as known in the art. Alternatively, if the selected mode of payment was a prepaid account as described above, then the proxy server 254 may present the consumer 54 with a verification window 144 as shown in FIG. 6, with the funds for the transaction being thereafter debited from the prepaid account.
  • the proxy server 254 may then verify the mode of payment accepted by the merchant 56 (step 294). For example, if the merchant 56 has an existing relationship with the proxy management system 252, then funds can be transferred to the merchant (step 295) in accordance with a predetermined agreement or analogous to that described above. Alternatively, if the merchant 56 only accepts credit card payments, then the proxy server 254 may initiate a credit card transfer as known in the art. Additionally, funds may be transferred with conventional bank transfers. Moreover, the proxy server 254 may be configured to transfer funds to the merchant 56 in the form of a check or a money order, as described in more detail below. Upon receipt of the funds and any other payment information, e.g., shipping address (step 294) (step 294) is a predetermined agreement or analogous to that described above. Alternatively, if the merchant 56 only accepts credit card payments, then the proxy server 254 may initiate a credit card transfer as known in the art. Additionally, funds may be transferred with conventional bank transfers. Moreover, the proxy server 254 may be configured to transfer funds
  • the merchant 56 may then transmit a verification signal (step 297) to the proxy server 254.
  • the proxy server 254 may transmit a payment confirmation web page or e-mail (step 298) which is received by the consumer's computer 80 (step 299).
  • fulfillment of the transaction is carried out, including the merchant 56 providing the goods or services of the transaction (step 301) to the consumer (step 302).
  • the merchant 56 may also provide a service fee to the proxy management system 252 (step 303) for acting a middleman in the transaction, such as an affiliate fee.
  • the consumer 54 may also continue to access merchant web sites (step 304) as desired.
  • the proxy management system 252 acts as a payment middleman in handling a transaction between the consumer 54 and the merchant 56.
  • the proxy server 254 may be configured to accept many different types of payment methods, as well as payment methods yet to be developed, without requiring the merchant web site 118 to be constantly updated to accept new and different payment methods.
  • the billing and payment information of the consumer 54 remains anonymous to the merchant 56 because the proxy server 254 acts as a broker in the transaction, thereby shielding each party from the other party's mode of payment. Therefore, while acting as a broker in the transaction, the proxy server 254 creates a seamless transaction for both the consumer 54 and the merchant 56.
  • shipping address information may be automatically taken from account information previously supplied by the consumer 54.
  • Other fields in the payment window 282 may be left enabled for the consumer 54 to complete.
  • the proxy management system 252 may determine the preferred payment method of a merchant 56 and then transfer funds to the merchant according to that preference. If the preferred payment mode of the merchant 56 is a check, then, according to conventional systems, the consumer 54 would need to write out a check, send the check to the merchant by mail, and then wait for the check to clear before the goods or services are delivered. If the preferred payment mode of the merchant 56 is a money order, then, according to conventional systems, the consumer 54 would need to purchase a money order from a financial institution, pay a service charge for doing so, and send the money order to the merchant by mail. While checks and money orders are often preferred by many merchants because of the absence of finance charges at their end, clearly both of these conventional approaches have disadvantages to the consumer.
  • the proxy server 254 may be configured to determine the merchant payment mode (step 294). If such determination yield check or money order (step 308), then the proxy server 254 may capture a merchant payment form from the merchant web site 118 (step 310). In addition, the proxy server 254 secures funds from the consumer 54 as described above (step 292), which funds do not need to be in the form of a check or money order.
  • the proxy server 254 then causes the management system 252 to generate a check or a money order (step 312), depending upon the merchant's preference, and then to transmit the check or money order to the merchant 56 (step 314). Accordingly, the proxy management system 252 acts as a payment middleman to provide a seamless transaction regardless of the method of payment at either end of the transaction. In other words, both the consumer 54 and the merchant 56 are able to participate in the transaction utilizing their preferred financial instruments.
  • the consumer 54 will access a merchant web site 118 directly, without first accessing a portal web site 256 and then browsing the merchant web site 118 via the proxy server 254 as described above.
  • the merchant web site 118 may include a link to the proxy server 254 which, when activated, enables the consumer to complete the transaction utilizing a mode of payment different than that accepted by the merchant.
  • the consumer 54 may access the proxy server 254 and complete the transaction with the consumer's preferred mode of payment, such as using a credit card or a prepaid account as discussed above.
  • the proxy server 254 may then generate a check or a money order for the transaction and transmit the check or money order to the merchant. Accordingly, the consumer pays funds as desired, and the merchant receives funds as desired.

Abstract

A method for managing transactions on the Internet (81) between a consumer and a merchant by proxy is disclosed (see Fig. 1). The merchant has a merchant web site hosted by a merchant server. The method includes providing to the customer access to a portal web page and access to the merchant page via a proxy server. Access is provided to the merchant web page via the portal web page without the consumer directly accessing the merchant server. When the consumer initiates a purchase, access is provided to a payment page on the proxy page for the consumer, and funds are secured from the purchase for the consumer. Funds are then transferred to the merchant for the transaction. If a merchant only accepts single-use financial instruments, such as checks or money orders, then a consumer may carry out a transaction with another method of payment, such as a credit card or a prepaid account, with the proxy server generating a single-use financial instrument and transmitting it to the merchant.

Description

METHODS FOR MANAGING TRANSACTIONS OVER THE INTERNET BY PROXY AND WITH SINGLE-USE FINANCIAL INSTRUMENTS
CROSS-REFERENCE TO RELATED APPLICATIONS
The present application claims priority on U.S. Provisional Application for Patent Nos. 60/174,078 and 60/174,081, each of which was filed December 30, 1999, the entire disclosure of each of which is incorporated herein by reference.
FIELD OF THE INVENTION
The present invention relates to the electronic commerce over a communication network such as the Internet and, more specifically, to systems for securely exchanging monetary value for goods and services purchased over the Internet. The present invention relates to systems for managing economic exchange between merchants and consumers through the use of a proxy server so that merchant servers do not need to be directly accessed by consumers. The present invention is particularly beneficial for consumers with limited credit resources and merchants with restrictive acceptable modes of payment.
BACKGROUND OF THE INVENTION
With the advent and looming dominance of the Internet in today's consumer market, conventional currency transactions between consumers and merchants have been redefined. Gone are the days of exclusive cash, check, or credit card transactions. Financial institutions and web merchants have had to develop new transaction techniques to ensure the integrity of the transaction and to maintain the privacy of the consumer.
Automation has achieved some of these qualities for large transactions through computerized electronic funds transfer (EFT) systems. Electronic funds transfer is essentially a process of value exchange achieved through a banking system's centralized computer transactions. EFT services are a transfer of payments utilizing electronic checks, which are used primarily by large commercial organizations.
Examples of EFT systems utilized by retail and commercial organizations include an automated clearing house (ACH) where a user can enter a pre-authorized code and download information with billing occurring later, and a point-of-sale (POS) system where a transaction is processed by connecting with a central computer for authorization for the transaction granted or denied immediately. However, the payments made through these types of EFT systems are limited in that they cannot be performed without the banking system. Current EFT systems, credit cards, or debit cards, which are used in conjunction with an on-line system to transfer money between accounts, such as between the account of a merchant and that of a customer, cannot satisfy the need for an automated transaction system providing an ergonomic interface. To implement an automated, convenient transaction that can dispense some form of economic value, there has been a trend towards off-line payments. For example, numerous ideas have been proposed for some form of electronic money that can be used in cashless payment transactions as alternatives to the traditional currency and check types of payment systems. See, for example, U.S. Patent No. 4,977,595, entitled "Method and Apparatus for Implementing Electronic Cash," and U.S. Patent No. 4,305,059, entitled "Modular Funds Transfer System." Other techniques for automated transactions include magnetic stripe cards purchased for a given amount and from which a prepaid value can be deducted for specific purposes. Other examples include memory cards or so called smart cards which are capable of repetitively storing information representing value that is likewise deducted for specific purposes. In an electronic environment, it is desirable for a computer operated under the control of a merchant to obtain information offered by a customer and transmitted by a computer operating under the control of the customer over a publicly accessible packet-switched network (e.g., the Internet) to the computer operating under the control of the merchant, without risking the exposure of the information to interception by third parties that have access to the network, and to assure that the information is from an authentic source. It is further desirable for the payment processing to be flexible and able to negotiate with the client customer to select a mutually acceptable payment protocol and other payment options.
One such attempt to provide a secure transmission channel is a secure payment technology known as the Secure Electronic Transaction (SET), jointly developed by the Visa and MasterCard card associations. Other such secure payment technologies include Secure Transaction Technology (STT), Secure Electronic Payments Protocol (SEPP), Internet Keyed Payments (iKP), Net Trust, and Cybercash Credit Payment Protocol. Such secure payment technologies require the customer to operate software that is compliant with the secure payment technology, interacting with third-party certification authorities, thereby allowing the customer to transmit encoded information to a merchant, some of which may be decoded by the merchant, and some which can be decoded only by a payment gateway specified by the customer.
Another attempt to provide a secure transmission channel is a general-purpose secure communication protocol known as Secure Sockets Layer (SSL) developed by Netscape, Inc. SSL provides a means for secure transmission between two computers. SSL has the advantage that it does not require special-purpose software to be installed on the customer's computer because it is already incorporated into widely available software that many people utilize as their standard Internet access medium, and does not require that the customer interact with any third-party certification authority. Instead, the support for SSL may be incorporated into software already in use by the customer, e.g., the Netscape Navigator browser. However, although a computer on an SSL connection may initiate a second SSL connection to another computer, a drawback to the SSL approach is each SSL connection supports only a two-computer connection. Therefore, SSL does not provide a mechanism for transmitting encoded information to a merchant for retransmission to a payment gateway such that a subset of the information is readable to the payment gateway but not to the merchant. Although SSL allows for robustly secure two-party data transmission, it does not meet the ultimate need of the electronic commerce market for robustly secure three-party data transmission. Other examples of general-purpose secure communication protocols include Private Communications Technology (PCT) from Microsoft, Inc., Secure HyperText Transport Protocol (SHTTP) from Theresa Systems.
Internet-based payment solutions require security measures that are not found in conventional point-of-sale (POS) terminals. This additional requirement is necessitated because Internet communication is done over publicly accessible, unsecured communication lines, which is in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional merchant and an acquiring bank. Thus, it is critical that any solution utilizing the Internet for a communication backbone employ some form of cryptography.
Prepaid instruments in use today are a variant of one of (or combination of several of) the following devices: prepaid phone and access cards, debit cards, and money orders and gift certificates. Most Debit Cards are predicated on a credit system or linked to an existing bank account. Internet purchase schemes are predominantly credit systems. In addition, a number of online purchase schemes utilize an electronic wallet that is filled (i.e., funded) and refilled from a credit source. This is synonymous to certain toll-road systems that debit a credit account periodically to pay in advance for toll road use that is often electronically sensed. Internet purchasing schemes to date are all credit or bank account based due to the inability to collect cash over the wire.
In view of the foregoing, there remains a need in the art for systems for managing financial transactions over the Internet in an efficient and versatile manner.
BRIEF SUMMARY OF THE INVENTION
According to a preferred embodiment, a method manages transactions on the Internet between a consumer and a merchant by proxy. The consumer has a computer with a browser for displaying a portal web site, and the merchant has a merchant web site hosted by a merchant server. The portal web site has a link associated with the merchant web site. The method includes providing to the consumer access to the merchant web page via a proxy server. Access is provided to the merchant web page via the portal web page an the proxy server without the consumer directly accessing the merchant server. When the consumer initiates a purchase, access is provided to a payment page on the proxy server for the consumer, and funds are secured for the purchase from the consumer. Funds are then transferred to the merchant for the transaction.
The proxy management system and methodology of the present invention has a number of advantages. For example, the consumer is not restricted to making a payment according to the merchant's modes of payment. If, for example, a merchant only accepts checks or money orders, a consumer may carry out the transaction with a credit card or a prepaid account with the proxy server, with the proxy server, in turn, generating a check or money order for the merchant. Advantageously, the proxy server may be configured to automatically determine the preferred mode(s) of payment accepted by the merchant.
If the consumer has a prepaid account with the proxy management system, then this account may be automatically debited when the transaction takes place. Accordingly, the merchant is guaranteed of a fast and reliable payment. In addition, rather than constantly updating their web site to accept new modes of payment, a merchant can rely upon the proxy server for such changes while continuing to accept their preferred method of payment. The proxy management system may generate revenue either by deducting a service fee when transferring funds from the consumer to the merchant or by receiving a service from, e.g., an affiliate fee, from the merchant for each transaction.
Another advantage of the present invention is that the consumer is able to carry out transactions without directly accessing merchant servers. The consumer is able to access and browse a merchant web site within the portal web site via the proxy server as if the consumer were actually connected directly to the merchant server. This is accomplished by configuring the proxy server to map in real time the merchant web page in response to browsing by the consumer. Accordingly, the billing and payment information of both the consumer and the merchant remain anonymous to the other party
According to another preferred embodiment of the invention, a method for managing transactions on the Internet between a consumer and a merchant first enables the consumer to access a merchant web page on a proxy server such that a merchant server is inaccessible to the consumer. A transaction is then managed between the merchant and the consumer on the proxy server such that the merchant server is inaccessible to the consumer. Funds received from the consumer are then transferred to the merchant based upon a value of the transaction.
In accordance with still another preferred embodiment of the invention, a method for making purchases from a merchant over the Internet includes accessing a portal web page and then accessing a merchant web page on the portal web page via a proxy server, such that a merchant server is not directly accessed by the consumer. A transaction is then initiated with the merchant via the portal web page such that the merchant server is not directly accessed. Funds are then caused to be transferred to the merchant based upon a value of the transaction.
According to a preferred embodiment, a method manages transactions on the Internet with between a consumer and a merchant accepting a single-use financial instrument as payment for a transaction. Examples of such financial instruments include checks, money orders, and one-time credit card numbers. The merchant has a merchant web site with payment information associated with the transaction. The method includes first capturing the payment information from the merchant web site. The capturing of the payment information is preferably carried out on a proxy server as part of a transaction management system. The consumer may access the proxy server by, for example, activating a link on the merchant web page. Funds are then secured for the transaction from the consumer, thereby causing a single-use financial instrument to be generated and transmitted to the merchant.
The transaction management system and methodology of the present invention has a number of advantages. For example, the consumer is not restricted to making a payment according to the acceptable modes of payment of the merchant, that is, with a check or a money order. If, for example, a merchant only accepts money orders, a consumer may carry out the transaction with a credit card or a prepaid account with the proxy server of the management system, with the proxy server, in turn, generating money order for the merchant. Advantageously, the proxy server may be configured to automatically determine the preferred mode or modes of payment accepted by the merchant. If the consumer has a prepaid account with the management system, then this account may be automatically debited when the transaction takes place. Accordingly, the merchant is guaranteed of a fast and reliable payment in accordance with its acceptable mode of payment. According to another preferred embodiment, a method carries out a transaction on the Internet with a merchant that accepts a single-use financial instrument as payment. According to this method, a consumer first accesses a proxy server of a management system, for example, by activating a link on a merchant web page or by directly typing a URL address in the browser. The consumer then causes the proxy server to capture payment information from the merchant web site, which information may include mode of payment, price, tax, shipping, etc. The consumer then causes funds for the transaction to be transferred to the management system, thereby triggering the generation of a single-use financial instrument and the transferring of the single-use financial instrument to the merchant.
According to the present invention, a consumer is not required to make payment on a transaction according to a merchant's acceptable modes of payment if those modes of payment are single-use financial instruments. Rather, a consumer may carry out the transaction according to his or her preferred payment methods. Other aspects, features, and advantages of the present invention will become apparent to those skilled in the art from a consideration of the following detailed description taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
FIG. 1 is a block diagram of an exemplary e-commerce system according to the present invention in which prepaid monetary instruments are utilized by a system for managing transactions between consumers and e-merchants;
FIG. 2 is a schematic representation of a prepaid monetary instrument configured according to a preferred embodiment of the invention;
FIG. 3 is a flow chart illustrating exemplary methodology for managing anonymous transactions over a network with prepaid monetary instruments in accordance with the present invention;
FIG. 4 is a block diagram of an management system configured in accordance with an exemplary embodiment of the present invention;
FIGS. 5A and 5B are a schematic representations of Internet activation browser windows exemplifying principles of the present invention;
FIG. 6 is a schematic representation of an e-merchant verification browser window exemplifying principles of the present invention; FIG. 7 is a block diagram of an exemplary e-commerce system according to the present invention in which transactions between consumers and merchants are carried out by proxy;
FIG. 8 is a flow chart illustrating exemplary methodology for managing transactions over the Internet by proxy in accordance with the present invention; FIG. 9 is a schematic representation of a proxy payment browser window exemplifying principles of the present invention; and
FIG. 10 is a flow chart illustrating exemplary methodology for managing check and money order transactions over the Internet in accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION The present invention provides in general apparatus and associated methodology for managing transactions between consumers and merchants over the Internet. These apparatus and methods include plural preferred embodiments, a number of which are described below. Those skilled in the art will appreciate that the following description provides foundation for many other embodiments that fall within the broad principles of the present invention as set forth in the appended claims.
Anonymous Transactions
Referring more particularly to the drawings, an exemplary embodiment of an e-commerce system according to the present invention is shown in FIG. 1 and is indicated generally by reference numeral 50. Exemplary e-commerce system 50 includes a management system 52 that is configured to allow anonymous transactions to take place between consumers 54 and merchants 56 over a network 58 such as the Internet. More specifically, through the use of prepaid monetary instruments purchased at one or more distributors 60, exemplary management system 52 enable consumers 54 to purchase goods and services from the merchants 56 with complete anonymity. In addition, exemplary management system 52 guarantees that the merchants 56 receive funds for goods and services provided without the drawbacks of conventional financial-transaction instruments such as credit cards. In a preferred embodiment, the management system 52 of the present invention provides cash-like and real-time transactions for purchases made on the Internet.
An example of a prepaid monetary instrument configured in accordance with the present invention is illustrated in FIG. 2 and is indicated by reference numeral 62. Exemplary instrument 62 includes information specific thereto, for example, a denomination or monetary value 64 and a security code 66 such as a serial number. In a preferred embodiment, exemplary instrument 62 may include one or more enablement means, such as a barcode 72 and/or a magnetic strip 74, which will be discussed in more detail below. Preferably, the instrument 62 of the present invention also includes an area 76 for graphics and text. Although any tangible form may be used, exemplary instrument 62 is preferably configured on a card-like body 78 for easy transport and familiarity. Exemplary instrument 62 may be preprinted or, alternatively, may have the monetary value 64 and the security code 66 printed at the time and place of the sale.
With further reference to FIG. 1, to place the principles of the invention in context, exemplary e-commerce system 50 generally includes a plurality of consumers 54a, 54b, 54c, ..., 54k each with access to a computer 80a, 80b, 80c, ..., 80/ connected to the network 58. Each consumer 54 has direct access to a plurality of distributors 60a, 60b, 60c, ..., 60m of the instruments 62 and network access via a respective computer 80 to the management system 52 and a plurality of participating web merchants 56a, 56b, 56c, ..., 56M. The network 58 may include the Internet 81 and an instrument services network 82, which is discussed in more detail below.
With additional reference to FIG. 3, each consumer 54 purchases an instrument 62 from any one of the distributors 60 (step 83). The plurality of distributors 60 may include retail establishments, convenience stores, department stores, post offices, dedicated kiosks, and so on. In addition, the plurality of distributors 60 may include unattended devices, such as vending machines. The distributor 60 making the sale of the instrument 62 receives funds (step 84) from the consumer 54 in the amount of a desired monetary value 64. An additional service charge may be added in the sale of the instrument 62.
The distributor 60 then enables the instrument 62 (step 86), which may be accomplished in any number of ways. For example, the barcode 72 may be optically scanned, or the magnetic strip 74 may be swiped through a reader such as a standard Verafone® interface. By enabling the instrument 62, the information specific thereto, i.e., the monetary value 64 and the security code 66, is transmitted via the network 58 to the management system 52 (step 88). The enablement of the instrument 62 preferably takes place across the instrument services network 82 of the system network 58.
Referencing FIG. 4, the information transmitted by the distributor 60 is received by the management system 52 (step 90) at an instrument services gateway 92 which, in turn, sends the information to an enablement processor 94 which triggers an electronic transfer of funds (step 96). The distributor 60 electronically transfers funds (step 98) to the management system 52, and an enabled account is established (step 100) for the instrument 62 via an enablement application program interface (API) 102. Enablement of an instrument 62 changes an account specific to the instrument from a pending status to an enabled status. Data associated with instruments 62 with accounts having an enabled status (i.e., enabled accounts) may be stored on an instruments data structure 104, and data associated with the transfer of funds from the distributors 60 may be stored on a distributor data structure 106. In alternative embodiments, the distributor 60 may provide the monetary value 64 of the instrument 62, and the management system 52 may confirm the enablement of the instrument 62 with the distributor 60 and verify the monetary value 64.
A consumer 54 with an enabled instrument 62 then needs to activate the instrument 62 (step 108). To do so, the consumer 54 accesses an activation website (step 110) with a computer 80. The activation website may be part of a general customer website 112 maintained by the management system 52. Alternatively, the activation website may be a frame within a website of a distributor. Referencing FIG. 5A, a first activation window 114 is displayed on the consumer's computer 80 which prompts the consumer 54 for the security code 66 of the instrument 62 (step 116). The first activation window 114 may include fields for this information, as indicated by reference numeral 118. The consumer 54 may then activate a SUBMIT icon 120 to provide the security code 66 to the management system 52 (step 122).
Upon receipt of the security code 66, the management system 52 causes a second activation window 124 as shown in FIG. 5B to be displayed on the consumer's computer 80 which prompts the consumer 54 for a user ID and a password (step 125). The second activation window 124 may include fields for this information, as indicated by reference numerals 126 and 127, respectively. In a preferred embodiment, the second activation window 124 also includes fields for prompting the consumer for a challenge phrase and a challenge response, as indicated by reference numerals 128 and 129, respectively, which will be discussed in more detail below. Upon entering the requested information, the consumer 54 may then activate a SUBMIT icon 130 to provide the user ID and the password to the management system 52 (step 131).
The management system 52 receives the user ID and the password by an account activator 132, as shown in FIG. 4. Through an activation API 134, the enabled account associated with the instrument 62 is activated (step 136); that is, the enabled status of the account is changed to an active status. Data associated with the activated account of the instrument 62 may be stored on an active accounts data structure 138.
With the account associated with an instrument 62 activated, a consumer 54 is free to shop on-line at any merchant with a website connected to the network 58 and set up to accept payment with the instrument 62 of the present invention. To do so, the consumer 54 accesses a merchant website (step 140) to shop for goods and services. When the consumer 54 has decided upon a desired selection of goods and/or services, a purchase is initiated (step 142) from the merchant's website. When a purchase is initiated, the merchant 56 preferably redirects the consumer 54 to the management system 52 (step 143). A secure handshake between the customer 54 and the management system 52 may be established.
Referencing FIG. 6, when the purchase is initiated, a verification window 144 may be displayed on the consumer's computer 80 which prompts the consumer 54 for the user ID and the password (step 146). The verification window 144 may include fields for this information, as indicated by reference numerals 148 and 149, respectively. In alternative embodiments, for example, if a secure handshake is not established, the verification window 144 may also include a field for prompting the consumer for the challenge phrase and the challenge response, similar to that shown in FIG. 5B. This is particularly useful as added security if a prepaid instrument 62 is lost or stolen, or if the consumer is utilizing a computer 80 other than that used to activate the account associated with the prepaid instrument. The consumer 54 may then activate a SUBMIT icon 152 to provide the user ID and the password to the management system 52 (step 154).
Upon receiving the user ID and the password, the management system 52 generates and transmits a query to a transaction engine 160. Upon receipt of the query , the transaction engine 160 validates the user ID and the password and correlates this information with active account information in the active account data structure 138 through a prepaid transaction API 164. The funds in the account are then verified (step 166). A funds signal is generated and transmit (step 168) to the merchant 56. The funds signal contains information indicative of whether or not sufficient funds are in the account to cover the purchase.
Upon receipt of the funds signal (step 170), the merchant 56 proceeds with the transaction if sufficient funds are available (step 172). If sufficient funds are not available, the management system 52 may query the customer 54 for alternative or addition payment options, such as a credit card to cover the deficit. The merchant 56 then transmits a verification (step 174) to the customer 54 that the transaction has taken place. Upon receipt of the verification (step 176), the customer 54 may continue shopping with the instrument 62 if funds remain in the account (step 178). Upon completing the transaction, the merchant 56 may send a purchase signal (step 180) to the management system 52 which, upon receipt (step 182), debits the account (step 184) of the instrument 62 associated with the transaction. The management system 52 may then transfer funds (step 186) to the merchant which, upon their receipt (step 188), completes the anonymous transaction between the customer 54 and the merchant 56. The amount of funds transferred to the merchant 56 is based upon the purchase price and may be reduced by a service charge of the management system. Alternatively, the management system 52 may debit the account of the prepaid instrument 62 prior to transmitting the funds signal in step 168.
One of the advantages of the management system 52 of the present invention is that purchases made by a customer may be batched or pre-authorized. According to this feature of the invention, a merchant 56 batches multiple purchases made during a single on-line session with a consumer 54. To do so, an advance is established by completing a secure handshake between the merchant 56 and the management system 52 and between the merchant 56 and the consumer 54. When the shopping session is complete, the total amount is communicated to the management system 52 and the consumer 54 to finalize the transaction. This embodiment is particularly useful for merchants who specialize as content or information providers. Such merchants require micropayments for various informational units. Micropayments are small payments that are not suitable for credit-based purchase schemes, examples of which include $0.25 for a download of a piece of intellectual property and $1.50 for two viewing/use rights for an on-line service such as financial information from a financial website.
In a preferred embodiment, exemplary management system 52 is configured to allow the combining of the accounts of multiple instruments into a single account. For example, if a single consumer 54 has purchased several instruments and has used these instruments such that a small balance remains in the account of each, then the consumer 54 may combine these multiple accounts into a single account that can be used analogously to a new account. In other words, Account 1 through Account x may be combined into Account x+1. Accounts 1 through x would then be empty and marked idle. This account combination feature of the management system 52 may be carried out by a customer query handler 190 and an account services API 192. A data structure 194 dedicated to quiet and closed accounts may be provided to house data associated with the accounts comprising the combined account. In addition to combining accounts, customer query handler 190 may be configured to enable a consumer to move or transfer funds from one account to another. Conversely to the combination of accounts, the management system 52 of the present invention may be configured to allow the parsing or splitting of one account into several accounts. Parsing provides an effective way to disperse of a remaining balance in an account, and may be carried out by the customer query handler 190.
The management system 52 of the present invention may also include a data structure 196 for housing data relevant to each of the merchants 56 of the network 50. In doing so, the management system 52 may organize the merchant 56 into categories according to, for example, the type of goods or services being sold, the target consumer (e.g., teens, adult only, etc.), and the type of offerings (e.g., information, soft services, or hard goods). By classifying the merchants 56 in an object class library structure, the process of adding and grouping new merchants 56 is greatly simplified. This classification enables the creation of prepaid monetary instruments 62 that are valid only at certain specifiable classes of merchants 56. For example, one of the most useful such class of merchants 56 would be suitable for preteens and teens. Accordingly, a "card for minors" may be enabled that is restricted to merchants 56 that have been so categorized. As new merchants 56 come on-line and meet the qualifications, they may be added to this category of merchants and available to the "cards for minors," as well as to all newly issued cards. This categorization of merchants 56 is preferably monitored and maintained current. If an existing participating merchant changes its offerings goods and/or services in such a way that it would change its categorization, then such a change may be detected and updated for existing accounts, as well as new accounts. This monitoring and updating may be accomplished by the combination of the object class library classification and an automated "web crawling" of each merchant 56. This form of electronic inspection may be performed periodically (e.g., daily) against all participating merchants 56. The activated instruments 62 may then be enabled or disabled according to the current classes of merchants 56.
With further reference to FIG. 4, exemplary management system 52 may also provide a website 198 for access by the merchant 56 of the system 50. A merchant query handler 200 and a merchant SVC 202 in communication with the merchant data structure 196 may be configured to handle queries from merchants 56 as to status of there respective accounts with the system.
The accounts of the management system 52 may be classified according to status. For example, accounts may be allocated by the security codes or a block of security codes to a particular distributor 60. The allocation of accounts within the management system 52 allows a distributor 60 to design and manufacture unique instruments 62. A pending account indicates an account that is on-line in the system 52 and awaiting enablement. An enabled account, as discussed above, indicates that the account has been purchased and enabled and is awaiting activation. An activated account, also as discussed above, indicates that the account has been activated by the consumer 54 on the customer website 112.
An account may acquire a quiet status if the account balance goes to zero (or effective zero) and/or has seen not activity for a predetermined amount of time, for example, three months. In addition, an account may acquire a complete status if the account has been quiet for an extended predetermined amount of time, for example, at least 24 months with a balance or six months with no effective balance. The active accounts data structure 138 and the quiet/closed accounts data structure 194 may include data related to each of these accounts.
According to transaction-management methodology of the present invention, the enablement processor 94 processing a signal from a distributor 60 received via the network 58. The signal from the distributor 60 includes the information, i.e., the monetary value 64 and the security code 66, of the prepaid instrument 62. The enablement processor 94 then causes an account associated with the prepaid instrument to be enabled based upon the information. The account activator 132 then receives a signal from a customer 54 via the network 58. The signal from the customer 54 includes at least the security code, the user ID, and the password. The account activator 132 then causes the enabled account associated with the security code to be activated in association with the user ID and the password. The transaction engine 160 then processes a signal from including information regarding a purchase and a password. The transaction engine 160 causes a verification of funds in the active account associated with the received user ID and password and causes a signal to be generated and transmitted to the merchant 56 as to whether the account associated with the password has sufficient funds to cover the purchase. The transaction engine 160 then receives and processes a second signal from the merchant 56, with the second signal including information indicative of whether the purchase took place. The transaction engine 160 causes funds to be transferred to the merchant 56 based upon a value of the purchase. The foregoing methodology may be implemented in software modules including a plurality of code segments. For example, the software may include code segments for processing the signal from the distributor and for enabling the account associated with the prepaid instrument 62 in the enablement processor 94. Other code segments may be configured to activate the account and associate the account with a user ID and a password received by the account activator 132. Additional code segments may be configured for processing the signal from the merchant 56 to the transaction engine 160, including code segments for prompting the consumer for the user ID and the password associated with the instrument, for verifying sufficient funds, for generating the signal, and for causing the signal to be transmitted to the merchant as to the same. The software may also include other code segments for processing the second signal from the merchant 56 and for causing funds to be transferred to the merchant based upon a value of the purchase.
Proxy Transactions A preferred embodiment of an e-commerce system of the present invention is illustrated in
FIG. 7 and indicated generally with reference numeral 250. Exemplary e-commerce system 250 includes a proxy management system 252 for managing transactions between a consumer 54 and a merchant 56 by proxy. Exemplary proxy system 252 includes a proxy server 254 and a portal web site 256. The proxy server 254 is configured to be accessible to the consumer 54 by a computer 80 with a web browser 257 and to one or more merchant servers 258 via the Internet 81. Each merchant server 258 is configured to host one or more merchant web sites 118. The portal web site 256 may be hosted by the proxy server 254 if desired or, alternatively, by another server, such as a portal server 259 or a server of a distributor as discussed above. For clarity, only a single consumer and merchant are shown in FIG. 7, although a plurality of each are contemplated analogous to that shown in FIG. 1.
According to the present invention, the consumer 54 is able to carry out transactions with the merchant 56 without needing to access the merchant server 258 directly. Such a proxy system has a number of advantages. For example, analogous to that described above, the consumer 54 may establish a prepaid account with the proxy management system 252 and then use funds in the prepaid account to carry out transactions with merchants 56. In addition, with prepaid accounts, the consumer 54 need not be concerned with the payment modes (i.e., credit card, check, money order, etc.) of each merchant 56, because the proxy server 254 acts as a middleman between the consumer 54 and the merchant 56. In other words, regardless of the modes of payment accepted by the merchant 56, the consumer 54 may use any type of desired mode of payment, and vice verse. With additional reference to FIG. 8, to carry out a transaction by proxy, a consumer 54 first accesses the portal web site 256 with a computer 80 (step 260), which site is hosted by a server other than that of the merchant server 258, e.g., the portal server 259. The consumer 54 may then access any merchant web site 118 (step 264) via the portal web site 256, e.g., by clicking on a link on the browser 257. This causes the server hosting the portal web site 256 to communicate with the proxy server 254 to request the desired merchant web site. The proxy server 254 then connects with the merchant server 258 (step 266) hosting the desired merchant web site 118 (step 268), and retrieves the merchant web site 118 (step 270). The merchant web site 118 is now presented to the browser 257 of the consumer 54. This may be accomplished by the proxy server 254 first parsing the merchant web site 118 and then sending web pages of the site 118 to the browser 257. The consumer 54 may now view the merchant web site 118 (step 271).
The proxy server 254 is configured so that the consumer 54 is able to view, navigate, and browse the merchant web site 118 (step 272) within the portal web site 256 via the proxy server 254 as though the consumer computer 80 were connected directly to the merchant server 258. In addition, the proxy server 254 is configured to modify and update the merchant web site 118 (step 274) in real time in response to browsing by the consumer 54 which, for the purposes of this description, is called "mapping." For example, as the consumer 54 activates links within a web page of the merchant web site 118, the proxy server 254 presents the new links as provided by merchant server 258 (step 275) by parsing the merchant web site 118 in real time. The web pages associated with the activated links are then mapped to the browser 257 on the consumer's computer 80.
When the consumer 54 initiates a transaction (step 276), the proxy server 254 captures payment information (step 277) provided by the merchant 56 (step (278), which information may include price, tax, shipping and handling costs, and so on. The proxy server 254 then provides a proxy payment page or window (step 280) to the browser 257, an example of which is shown in FIG. 9 and indicated by reference numeral 282. Exemplary proxy payment page 282 may include a number of payment fields, for example, a mode of payment field 284 and a shipping field 286, and a submit icon 288. To carry out the transaction, the consumer 54 completes the necessary payment fields and submits the information to the proxy server 254 (step 290).
The proxy server 254 then secures funds (step 292) in accordance with the mode of payment 284 selected by the consumer 54. For example, if the selected mode of payment was a credit card, then the proxy server 254 may present the consumer 54 with a web page that secures funds by credit card as known in the art. Alternatively, if the selected mode of payment was a prepaid account as described above, then the proxy server 254 may present the consumer 54 with a verification window 144 as shown in FIG. 6, with the funds for the transaction being thereafter debited from the prepaid account.
Upon securing funds for the transaction, the proxy server 254 may then verify the mode of payment accepted by the merchant 56 (step 294). For example, if the merchant 56 has an existing relationship with the proxy management system 252, then funds can be transferred to the merchant (step 295) in accordance with a predetermined agreement or analogous to that described above. Alternatively, if the merchant 56 only accepts credit card payments, then the proxy server 254 may initiate a credit card transfer as known in the art. Additionally, funds may be transferred with conventional bank transfers. Moreover, the proxy server 254 may be configured to transfer funds to the merchant 56 in the form of a check or a money order, as described in more detail below. Upon receipt of the funds and any other payment information, e.g., shipping address (step
296), the merchant 56 may then transmit a verification signal (step 297) to the proxy server 254. In turn, the proxy server 254 may transmit a payment confirmation web page or e-mail (step 298) which is received by the consumer's computer 80 (step 299).
As valid payment has been made, fulfillment of the transaction is carried out, including the merchant 56 providing the goods or services of the transaction (step 301) to the consumer (step 302). The merchant 56 may also provide a service fee to the proxy management system 252 (step 303) for acting a middleman in the transaction, such as an affiliate fee. The consumer 54 may also continue to access merchant web sites (step 304) as desired.
In addition to the advantages described above, the proxy management system 252 acts as a payment middleman in handling a transaction between the consumer 54 and the merchant 56. The proxy server 254 may be configured to accept many different types of payment methods, as well as payment methods yet to be developed, without requiring the merchant web site 118 to be constantly updated to accept new and different payment methods. In addition, the billing and payment information of the consumer 54 remains anonymous to the merchant 56 because the proxy server 254 acts as a broker in the transaction, thereby shielding each party from the other party's mode of payment. Therefore, while acting as a broker in the transaction, the proxy server 254 creates a seamless transaction for both the consumer 54 and the merchant 56.
In an embodiment of the invention in which the consumer 54 utilizes a prepaid account, shipping address information may be automatically taken from account information previously supplied by the consumer 54. Other fields in the payment window 282 may be left enabled for the consumer 54 to complete.
Single-Use Financial Instrument Transactions
As mentioned above, the proxy management system 252 may determine the preferred payment method of a merchant 56 and then transfer funds to the merchant according to that preference. If the preferred payment mode of the merchant 56 is a check, then, according to conventional systems, the consumer 54 would need to write out a check, send the check to the merchant by mail, and then wait for the check to clear before the goods or services are delivered. If the preferred payment mode of the merchant 56 is a money order, then, according to conventional systems, the consumer 54 would need to purchase a money order from a financial institution, pay a service charge for doing so, and send the money order to the merchant by mail. While checks and money orders are often preferred by many merchants because of the absence of finance charges at their end, clearly both of these conventional approaches have disadvantages to the consumer. For the purposes of this description, check, money orders, and one-time user credit card numbers will be referred to generically as "single-use financial instruments." According to the present invention, the disadvantages to the consumer associated with such instruments, particularly checks and money orders, are substantially eliminated. Referencing FIG. 10, as mentioned above, the proxy server 254 may be configured to determine the merchant payment mode (step 294). If such determination yield check or money order (step 308), then the proxy server 254 may capture a merchant payment form from the merchant web site 118 (step 310). In addition, the proxy server 254 secures funds from the consumer 54 as described above (step 292), which funds do not need to be in the form of a check or money order. The proxy server 254 then causes the management system 252 to generate a check or a money order (step 312), depending upon the merchant's preference, and then to transmit the check or money order to the merchant 56 (step 314). Accordingly, the proxy management system 252 acts as a payment middleman to provide a seamless transaction regardless of the method of payment at either end of the transaction. In other words, both the consumer 54 and the merchant 56 are able to participate in the transaction utilizing their preferred financial instruments.
More generally, in many embodiments, the consumer 54 will access a merchant web site 118 directly, without first accessing a portal web site 256 and then browsing the merchant web site 118 via the proxy server 254 as described above. In such an embodiment, if the acceptable modes of payment for the merchant 56 include only single-use financial instruments, then the consumer 54 is burdened to initiate and complete a transaction. However, according to the present invention, the merchant web site 118 may include a link to the proxy server 254 which, when activated, enables the consumer to complete the transaction utilizing a mode of payment different than that accepted by the merchant.
For example, if the merchant 56 only accepts checks or money orders, the consumer 54 may access the proxy server 254 and complete the transaction with the consumer's preferred mode of payment, such as using a credit card or a prepaid account as discussed above. The proxy server 254 may then generate a check or a money order for the transaction and transmit the check or money order to the merchant. Accordingly, the consumer pays funds as desired, and the merchant receives funds as desired.
Those skilled in the art will understand that the present invention is not limited to the embodiments specifically illustrated in the drawings and described above. Rather, those skilled in the art will realize that the specific elements of the present invention may be modified and are capable of numerous alternatives without departing from the scope and spirit of the present invention. Accordingly, the scope of the present invention is determined by the terms of the appended claims and their legal equivalents and not by the specific exemplary embodiments shown and described herein.

Claims

What is claimed is:
A method for managing transactions on the Internet between a consumer and a merchant, the consumer having a computer with a browser for displaying a portal web site, the merchant having a merchant web site hosted by a merchant server, the portal web site having a link associated with the merchant web site, the method comprising: a) retrieving the merchant web site to a proxy server when the link is activated; b) providing access to the consumer to the merchant web site on the portal web site via a proxy server without the consumer accessing the merchant server; c) providing access to a payment page on the proxy server for the consumer when the consumer initiates a transaction; d) securing funds for the transaction from the consumer; and e) transferring funds to the merchant.
2. The method as claimed in claim 1 further comprising: establishing an active account with the consumer.
3. The method as claimed in claim 2 wherein step (d) comprises: securing funds for the transaction from the active account.
4. The method as claimed in claim 1 further comprising: mapping the merchant web site in response to the consumer browsing the merchant web site via the proxy server.
5. The method as claimed in claim 1 further comprising: receiving a service fee from the merchant.
6. The method as claimed in claim 1 further comprising: determining a mode of payment of the merchant.
7. The method as claimed in claim 6 wherein step (e) comprises: transferring funds to the merchant according to the mode of payment.
8. The method as claimed in claim 6 wherein the mode of payment is a money order, step (e) comprising: generating a money order; and transferring the money order to the merchant.
9. The method as claimed in claim 6 wherein the mode of payment is a check, step (e) comprising: generating a check; and transferring the check to the merchant.
10. A method for managing transactions on the Internet between a consumer and a merchant, the consumer having a computer with a browser for displaying a portal web site, the merchant having a merchant web site hosted by a merchant server, the portal web site having a link associated with the merchant web site, the method comprising: a) enabling the consumer to access the merchant web site on the portal web site via a proxy server such that the merchant server is inaccessible to the consumer; b) managing a transaction between the merchant and the consumer via the proxy server such that the merchant server is inaccessible to the consumer; and c) transferring funds received from the consumer to the merchant based upon a value of the transaction.
11. The method as claimed in claim 10 further comprising: establishing an account associated with the consumer, the account including funds provided by the consumer.
12. The method as claimed in claim 11 wherein step (c) comprises: transferring funds from the account to the merchant based upon a value of the transaction.
13. The method as claimed in claim 10 wherein step (b) comprises: providing access to a payment page for the consumer on the proxy server; and receiving payment information from the consumer.
14. The method as claimed in claim 10 further comprising: determining a mode of payment of the merchant.
15. The method as claimed in claim 14 wherein step (c) comprises: transferring funds to the merchant according to the mode of payment.
16. The method as claimed in claim 14 wherein the mode of payment is a money order, step (c) comprising: generating a money order; and transferring the money order to the merchant.
17. The method as claimed in claim 14 wherein the mode of payment is a check, step (c) comprising: generating a check; and transferring the check to the merchant.
18. A method for carrying out transactions with a merchant over the Internet via a portal web site, the merchant having a merchant web site hosted by a merchant server, the portal web site having a link to the merchant web site via a proxy server, the method comprising: a) accessing a portal web site; b) causing the proxy server to retrieve the merchant web site such that the merchant server is not directly accessed; c) initiating a transaction with the merchant via the portal web site on the proxy server such that the merchant server is not directly accessed; and d) causing funds to be transferred to the merchant based upon a value of the transaction.
19. The method as claimed in claim 18 further comprising: establishing an account having funds with the proxy server.
20. The method as claimed in claim 19 wherein step (d) comprises: causing funds to be transferred from the account to the merchant based upon a value of the transaction.
21. A method for managing transactions on the Internet with between a consumer and a merchant accepting a single-use financial instrument as payment for a transaction, the merchant having a merchant web site with payment information associated with the transaction, the method comprising: f) capturing the payment information from the merchant web site; g) securing funds for the transaction from the consumer; h) generating a single-use financial instrument; and i) transferring the single-use financial instrument to the merchant.
22. The method as claimed in claim 21 further comprising: establishing an active account with the consumer.
23. The method as claimed in claim 22 wherein step (d) comprises: securing funds for the transaction from the active account.
24. The method as claimed in claim 21 further comprising: receiving a service fee from the merchant.
25. The method as claimed in claim 21 further comprising: determining a mode of payment of the merchant.
26. The method as claimed in claim 25 wherein step (c) comprises: generating a single-use financial instrument according to the mode of payment.
27. The method as claimed in claim 25 wherein the mode of payment is a money order, step (c) comprising: generating a money order.
28. The method as claimed in claim 25 wherein the mode of payment is a check, step (c) comprising: generating a check.
29. A method for making a transaction on the Internet with a merchant that accepts a single-use financial instrument as payment, the merchant having a merchant web site with payment information associated with the transaction, the method comprising: a) accessing a management system with a proxy server; b) causing the proxy server to capture the payment information from the merchant web site; c) causing funds for the transaction to be transferred to the management system, thereby causing: a single-use financial instrument to be generated by the management system; and the single-use financial instrument to be transferred to the merchant.
30. The method as claimed in claim 29 further comprising: establishing an account having funds with the management system.
31. The method as claimed in claim 30 wherein step (c) comprises: causing funds to be transferred from the account to the management system.
32. The method as claimed in claim 29 further comprising: causing the proxy server to determine a mode of payment of the merchant.
33. The method as claimed in claim 32 wherein a single-use financial instrument according to the mode of payment is generated in step (c).
34. The method as claimed in claim 32 wherein the mode of payment is a money order and a money order is generated in step (c).
35. The method as claimed in claim 32 wherein the mode of payment is a check and a check is generated in step (c).
PCT/US2000/035680 1999-12-30 2000-12-30 Methods for managing transactions over the internet by proxy and with single-use financial instruments WO2001050391A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU29150/01A AU2915001A (en) 1999-12-30 2000-12-30 Methods for managing transactions over the internet by proxy and with single-usefinancial instruments

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US17407899P 1999-12-30 1999-12-30
US17408199P 1999-12-30 1999-12-30
US60/174,081 1999-12-30
US60/174,078 1999-12-30

Publications (1)

Publication Number Publication Date
WO2001050391A1 true WO2001050391A1 (en) 2001-07-12

Family

ID=26869847

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/035680 WO2001050391A1 (en) 1999-12-30 2000-12-30 Methods for managing transactions over the internet by proxy and with single-use financial instruments

Country Status (2)

Country Link
AU (1) AU2915001A (en)
WO (1) WO2001050391A1 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2368147A (en) * 2000-06-09 2002-04-24 Ali Guryel Access control system for network of servers via port
WO2002080069A1 (en) * 2000-01-18 2002-10-10 Saint Media Co. Ltd. System for payment using a mobile phone in electronic commerce service
WO2004006143A1 (en) * 2002-07-03 2004-01-15 Common Component Pty Ltd E commerce system and method
EP1821249A1 (en) * 2006-02-14 2007-08-22 Lufthansa AirPlus Servicekarten GmbH Technique for interconnecting card payment networks
EP1879141A3 (en) * 2002-04-30 2008-03-26 Waterleaf Limited System for playing a game
GB2483633A (en) * 2010-09-06 2012-03-21 Mobank Ltd Transaction processing using a proxy
US8621575B2 (en) 2008-04-28 2013-12-31 Ice Organisation Ltd Secure web based transactions
US8956220B2 (en) 2012-06-29 2015-02-17 Pridefield Limited System for playing multiplayer games
US9852586B2 (en) 2011-05-13 2017-12-26 Cork Group Trading Ltd. System for playing multiplayer games
CN113657890A (en) * 2021-08-04 2021-11-16 支付宝(杭州)信息技术有限公司 Page rebound method and device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870716A (en) * 1994-10-06 1999-02-09 Hitachi, Ltd. Home terminal and shopping system
US5897622A (en) * 1996-10-16 1999-04-27 Microsoft Corporation Electronic shopping and merchandising system
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5870716A (en) * 1994-10-06 1999-02-09 Hitachi, Ltd. Home terminal and shopping system
US5897622A (en) * 1996-10-16 1999-04-27 Microsoft Corporation Electronic shopping and merchandising system

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002080069A1 (en) * 2000-01-18 2002-10-10 Saint Media Co. Ltd. System for payment using a mobile phone in electronic commerce service
GB2368147B (en) * 2000-06-09 2004-10-20 Ali Guryel Access control system for network of servers via portal
GB2368147A (en) * 2000-06-09 2002-04-24 Ali Guryel Access control system for network of servers via port
US8047913B2 (en) 2002-04-30 2011-11-01 Waterleaf Limited System for playing a game
EP1879141A3 (en) * 2002-04-30 2008-03-26 Waterleaf Limited System for playing a game
EP3182353A1 (en) * 2002-04-30 2017-06-21 Waterleaf Limited System for playing a game
WO2004006143A1 (en) * 2002-07-03 2004-01-15 Common Component Pty Ltd E commerce system and method
EP1821249A1 (en) * 2006-02-14 2007-08-22 Lufthansa AirPlus Servicekarten GmbH Technique for interconnecting card payment networks
US8621575B2 (en) 2008-04-28 2013-12-31 Ice Organisation Ltd Secure web based transactions
GB2483633A (en) * 2010-09-06 2012-03-21 Mobank Ltd Transaction processing using a proxy
US9852586B2 (en) 2011-05-13 2017-12-26 Cork Group Trading Ltd. System for playing multiplayer games
US8956220B2 (en) 2012-06-29 2015-02-17 Pridefield Limited System for playing multiplayer games
CN113657890A (en) * 2021-08-04 2021-11-16 支付宝(杭州)信息技术有限公司 Page rebound method and device

Also Published As

Publication number Publication date
AU2915001A (en) 2001-07-16

Similar Documents

Publication Publication Date Title
US10657588B2 (en) Method and system for funding a financial account
AU2009208734B2 (en) Method, device, and system for completing on-line financial transactions
AU754886B2 (en) A virtual private lock box
AU2001268692B2 (en) Method and system for processing internet payments
US8204812B2 (en) Method and system for funding a financial account
AU775916B2 (en) Method and system for processing internet payments using the electronic funds transfer network
US8412627B2 (en) Online funds transfer method
US8315929B2 (en) Online incremental payment method
US20130191278A1 (en) Method and System for Processing Internet Payments Using the Electronic Funds Transfer Network
AU2001268692A1 (en) Method and system for processing internet payments
JP5036131B2 (en) Method and system for transferring funds
WO2001050391A1 (en) Methods for managing transactions over the internet by proxy and with single-use financial instruments
WO2000067216A9 (en) A banking card associated with a cash account
WO2001069914A2 (en) Methods for managing transactions on the internet with anonymous shipping addresses
WO2000067218A1 (en) System and method for effectuating electronic payments
AU2004201231B2 (en) Method and system for processing internet payments using the electronic funds transfer network
WO2001015045A1 (en) Methods and apparatus for managing prepaid transactions over a network

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP