[go: up one dir, main page]

WO2001069914A2 - PROCEDES DE GESTION DE TRANSACTIONS SUR L'INTERNET AVEC ADRESSES D'EXPEDITION ANONYMES - Google Patents

PROCEDES DE GESTION DE TRANSACTIONS SUR L'INTERNET AVEC ADRESSES D'EXPEDITION ANONYMES Download PDF

Info

Publication number
WO2001069914A2
WO2001069914A2 PCT/US2001/008547 US0108547W WO0169914A2 WO 2001069914 A2 WO2001069914 A2 WO 2001069914A2 US 0108547 W US0108547 W US 0108547W WO 0169914 A2 WO0169914 A2 WO 0169914A2
Authority
WO
WIPO (PCT)
Prior art keywords
consumer
merchant
address
encoded
transaction
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/US2001/008547
Other languages
English (en)
Inventor
Inc. Ecatalystone.Com
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to AU81474/01A priority Critical patent/AU8147401A/en
Publication of WO2001069914A2 publication Critical patent/WO2001069914A2/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION 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/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

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 and associated methodology for managing economic exchange between merchants and consumers anonymously and without a consumer providing an actual shipping address to a merchant.
  • 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 processmg it is desirable for the payment processmg 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 winch 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 on-line 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.
  • the present invention provides methods for managing transactions over the Internet in which a consumer does not need to provide an actual shipping address to a merchant.
  • the consumer maintains a level of anonymity not possible by using, for example, a post office box.
  • the consumer when a consumer initiates a purchase with an e-merchant, if anonymity is desired, the consumer may cause a management system to generate an encoded address.
  • the encoded address may be a unique address code stored in a database in the management system and is associated with the actual shipping address of the consumer.
  • the encoded address may be based on consumer input and/or encrypted information.
  • the encoded address includes the ZIP code of the actual shipping address of the consumer so that the merchant may calculate actual shipping charges.
  • the encoded address is provided to the e-merchant. Accordingly, the e- merchant does not receive or know the consumer's actual shipping address.
  • the e-merchant may then prepare the goods for shipping and deliver the packaged goods to a shipper with the encoded address.
  • the shipper may be, for example, the U.S. Postal Service, United Parcel Service, FedEx, and so on.
  • the shipper determines whether the address on the packaged goods is an encoded address or an actual shipping address. If the address is encoded, then the shipper may look up the actual shipping address associated with the encoded address. This may be accomplished by the shipper querying the management system which, in turn, may retrieve the actual shipping address in a database and then transmit the same to the shipper. Alternatively, the management system may provide the shipper with the encoded address and the actual shipping address after the encoded address is first generated.
  • the shipper may store the encoded address and associated actual shipping address in a database and maintain the database of a plurality of encoded addresses and associated actual shipping addresses for future use. In either case, once the actual shipping address is obtained, the goods may be shipped.
  • 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. 5 A 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.
  • FIG. 11 is a flow chart illustrating exemplary methodology for managing transactions over the Internet by single-use credit-card numbers, or surrogate numbers, in accordance with a preferred embodiment of the present invention, particularly managing such transactions by proxy;
  • FIG. 12 is a flow chart illustrating exemplary methodology for managing transactions with surrogate numbers in accordance with an alternative embodiment of the invention
  • FIG. 13 is a flow chart illustrating exemplary methodology for managing transactions without a consumer providing an actual shipping address to an e-merchant
  • FIG. 14 is a block diagram illustrating exemplary encoded address of the 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.
  • 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 mcludes 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, ..., 54£ 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, ..., 56w.
  • 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. Referencing FIG. 5 A, 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).
  • 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.
  • 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 SNC 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 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 processmg a signal from a distributor 60 received via the network 58.
  • the signal from the distributor 60 mcludes 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.
  • 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
  • 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.
  • 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 acceptable modes of payment for the merchant 56 include only single-use financial instruments, then the consumer 54 may be burdened to initiate and complete a transaction not according to his or her favored mode of payment.
  • a merchant web site 118 indicates that a single-use financial instrument (e.g., a check or a money order) is the accepted mode of payment, then the consumer 54 may initiate an application on the computer 80 to generate and transfer to the merchant a single-use financial instrument.
  • the consumer 54 may initiate an application from the computer to cause the management system 52 or 252 to capture payment information from the merchant web page 118 and then to generate a single-use financial instrument for the transaction. Once generated, the instrument is transferred to the merchant as though being transferred by the customer 54. Accordingly, as described above, the transaction is seamless to the merchant 54 and allows both parties to partake in transactions on the Internet according to their preferred mode of payment.
  • the customer 54 does not need to access the proxy server 254 to carry out a transaction with a single-use financial instrument. However, if preferred, the customer 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.
  • the merchant web page 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.
  • a single-use credit-card number may be generated from a prepaid account for payment of a transaction on the Internet between a consumer and a merchant.
  • the single-use credit-card number will be called a surrogate number and, according to a preferred embodiment, may have a fixed amount and a fixed expiration date.
  • the surrogate number may be generated from a credit card of the management system. The amount that is assigned or allocated to the surrogate number may be deducted from the consumer's prepaid account.
  • the proxy management system 252 shown in FIG. 7 may generate a single-use surrogate number to be used by a consumer 54 for completing a transaction over the Internet 81 with a merchant 56.
  • the proxy server 254 captures and receives the merchant payment information (see steps 277 and 278 of FIG. 8), and then generates a surrogate number (step 320) based on the payment information.
  • the surrogate number may be generated in an amount equal to the purchase price provided by the merchant in the payment information.
  • the surrogate number may include an additional service fee charged to the consumer.
  • a surrogate number may be generated with a fixed expiration date, for example, within a predetermined amount of time (such as 24 hours) of generating the surrogate number.
  • Payment information is then provided to the consumer 54 (step 322), who is prompted to authorize the transaction.
  • the proxy management system secures funds (step 326) from the consumer 54, for example, by debiting a prepaid active account as discussed above.
  • the proxy server 254 transmits the surrogate number to the merchant server 258 (step 328) which, upon receipt (step 330), may proceed in accordance with the methodology following step 297 of FIG. 8.
  • the generation and the use of surrogate numbers give the proxy management system 252 the security of a conventional credit-card transaction while being valid only for a single transaction with a fixed amount and a short-term expiration date.
  • the consumer 54 utilizing the management system 250 may request a surrogate number to be generated in a particular amount.
  • the prepaid account associated with the requesting consumer 54 may then be debited for the amount.
  • the consumer 54 now has a valid credit-card number that he or she can use for a single online transaction with a merchant 56.
  • This feature of the invention gives a consumer 54 using the management system 250 the ability to make transactions at merchant web sites accepting credit cards, without the consumer 54 needing to use his or her own personal credit card.
  • credit-card transactions can be made at web sites not necessarily directly supported by the aforementioned management system, or even if the consumer 54 does not have his or her own personal credit card.
  • the consumer 54 uses the funds in the prepaid account.
  • the prepaid management system 52 as shown in FIG. 4 may also generate a surrogate number to be used as a refund or a cash-out method for the consumer 54 and his or her prepaid account.
  • the consumer 54 can request a refund for the balance remaining in a prepaid account (i.e., a cash out), rather than requesting the management system 52 to generate and send a check for the balance of funds in the account.
  • the generation of a surrogate number is immediate and without delay.
  • the consumer 54 may then use the surrogate number for any transaction that accepts conventional credit cards.
  • the request for a surrogate number may be made remotely through, for example, a wireless application protocol (WAP) interface of the management system 52.
  • WAP wireless application protocol
  • a surrogate number can be generated and used at a remote retail location, rather than at a dedicated merchant website.
  • a consumer 54 may use a wireless device such as a cellular telephone to request a surrogate number (step 340) for the total of a dinner tab at a restaurant.
  • the management system 52 may generate the surrogate number (step 342), debit the consumer's active prepaid account (step 344), and transmit the surrogate number to the consumer (step 346).
  • the consumer 54 receives the surrogate number wirelessly (step 348) and provides the number to the merchant (step 350) to complete the transaction.
  • the merchant can then use the surrogate number analogously to a conventional credit-card transaction to complete the transaction (step 352). Accordingly, a consumer 54 is able to complete transactions with a single-use credit-card number, with the funds being deducted from a prepaid account.
  • a consumer 54 may desire to remain anonymous to the e-merchant 56.
  • Anonymity is difficult with regard to the shipping address of the consumer 54.
  • a post office address i.e., a P.O. Box
  • the name of the post office box holder is public information and may be accessed.
  • many e-merchants do not accept shipping addresses consisting of post office boxes.
  • the anonymity of a consumer 54 making a transaction on the network 58 with a merchant 56 may be maintained.
  • an encoded address may be a unique address code stored in a database in the management system 52, for example, in the active accounts database 138 (see FIG. 4), and is associated with the actual shipping address of the consumer 54.
  • the encoded address may be based on consumer input and/or secure point in time information.
  • an encoded address 361 may includes actual information 362 and encoded information 363.
  • the actual information 362 may be the ZIP code of the actual shipping address of the consumer 54 so that the merchant 56 may calculate actual shipping charges.
  • the encoded information 363 may be any type of information that is indecipherable to the merchant, for example, encrypt alphanumeric text.
  • the management system 52 may generate an encoded address associated with a consumer 54 with an actual shipping address at the time the consumer 54 established a prepaid account.
  • the encoded address is provided to the e- merchant 56 (step 364).
  • the encoded address may be provided to the e-merchant 56 either directly by the management system 52.
  • the management system 52 may provide the encoded address to the consumer 54 who, in turn, may provide the encoded address to the e- merchant 56.
  • the consumer 54 may provide his or her actual uncoded shipping address to the e-merchant 56 (step 365).
  • the e-merchant 56 receives the address provided (step 366), be it either encoded or uncoded.
  • the e-merchant 56 may then prepare the goods for shipping (after payment is secured as described above) and deliver the packaged goods to a shipper with the address received from either the consumer 54 or the management system 52 (step 368).
  • the shipper may be either a governmental postal service (e.g., the U.S. Postal Service) or a private carrier (e.g., United Parcel Service, FedEx, etc.)
  • the shipper determines whether or not the address on the packaged goods is encoded (step 370). This may be done visually or with, for example, an optical scanner. If the address is uncoded, then the goods may be shipped to the consumer 54 (step 372) as usual. If the address is encoded, then the shipper may look up the actual shipping address associated with the encoded address (step 374). The shipper may carry this out by querying the management system 52 which, in turn, may look up or retrieve the actual shipping address from a database and then transmit the same to the shipper. Alternatively, the management system 52 may provide the shipper with the encoded address and the actual shipping address after the encoded address is generated (at step 360). The shipper may store the encoded address and associated actual shipping address in a database and maintain the database of a plurality of encoded addresses and associated actual shipping addresses. In either case, once the actual shipping address is obtained, the goods may be shipped (step 372).

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé destiné à gérer une transaction sur l'Internet entre un consommateur et un cybercommerçant, l'adresse d'expédition réelle du consommateur n'étant pas fournie au cybercommerçant. Un consommateur entreprenant un achat après d'un cybercommerçant et souhaitant garder l'anonymat amène un système de gestion à produire une adresse codée. Cette adresse codée peut être un code d'adresse unique stocké dans une base de données dans le système de gestion; elle est associée à l'adresse d'expédition réelle du consommateur. Ladite adresse codée est fournie au cybercommerçant. Celui-ci peut alors préparer les produits à envoyer et distribuer les produits emballés à un expéditeur muni de cette adresse codée. L'expéditeur détermine alors si l'adresse figurant sur les produits emballés est une adresse codée ou une adresse d'expédition réelle. Si l'adresse est codée, alors l'expéditeur peut récupérer l'adresse d'expédition réelle associée à cette adresse codée à partir d'une base de données. Une fois que l'adresse d'expédition réelle est obtenue, les produits en question peuvent être envoyés au consommateur.
PCT/US2001/008547 2000-03-14 2001-03-14 PROCEDES DE GESTION DE TRANSACTIONS SUR L'INTERNET AVEC ADRESSES D'EXPEDITION ANONYMES Ceased WO2001069914A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU81474/01A AU8147401A (en) 2000-03-14 2001-03-14 Methods for managing transactions on the internet with anonymous shipping addresses

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US18928700P 2000-03-14 2000-03-14
US60/189,287 2000-03-14
US64410900A 2000-08-21 2000-08-21
US09/644,109 2000-08-21
US75327400A 2000-12-30 2000-12-30
US75312900A 2000-12-30 2000-12-30
US09/753,274 2000-12-30
US09/753,129 2000-12-30
US77216901A 2001-01-29 2001-01-29
US09/772,16920010129 2001-01-29

Publications (1)

Publication Number Publication Date
WO2001069914A2 true WO2001069914A2 (fr) 2001-09-20

Family

ID=27539212

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/008547 Ceased WO2001069914A2 (fr) 2000-03-14 2001-03-14 PROCEDES DE GESTION DE TRANSACTIONS SUR L'INTERNET AVEC ADRESSES D'EXPEDITION ANONYMES

Country Status (2)

Country Link
AU (1) AU8147401A (fr)
WO (1) WO2001069914A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7225170B1 (en) * 2000-07-27 2007-05-29 Pitney Bowes Inc. Postage metering system for use with business reply mail
US7240035B1 (en) * 2001-05-31 2007-07-03 Hall Aluminum Llc Method and apparatus for masking private mailing address information by manipulating delivery transactions
US7254549B1 (en) * 2001-07-23 2007-08-07 At&T Corp. Real-time addresses for direct mail using online directories
WO2010088727A1 (fr) * 2009-02-03 2010-08-12 Steven Alexander Morris Agencement pour transfert de fonds financiers électronique sécurisé

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7225170B1 (en) * 2000-07-27 2007-05-29 Pitney Bowes Inc. Postage metering system for use with business reply mail
US7240035B1 (en) * 2001-05-31 2007-07-03 Hall Aluminum Llc Method and apparatus for masking private mailing address information by manipulating delivery transactions
US7254549B1 (en) * 2001-07-23 2007-08-07 At&T Corp. Real-time addresses for direct mail using online directories
WO2010088727A1 (fr) * 2009-02-03 2010-08-12 Steven Alexander Morris Agencement pour transfert de fonds financiers électronique sécurisé
US20120022971A1 (en) * 2009-02-03 2012-01-26 Steven Alexander Morris secure electronic financial funds transfer arrangement

Also Published As

Publication number Publication date
AU8147401A (en) 2001-09-24

Similar Documents

Publication Publication Date Title
AU754886C (en) A virtual private lock box
AU2001268692B2 (en) Method and system for processing internet payments
US8433652B2 (en) Method and system for processing internet payments using the electronic funds transfer network
US7827101B2 (en) Payment system clearing for transactions
US20130191278A1 (en) Method and System for Processing Internet Payments Using the Electronic Funds Transfer Network
AU2001268692A1 (en) Method and system for processing internet payments
WO2001050391A1 (fr) Procede de gestion de transactions sur l'internet au moyen de proxy et avec des instruments financiers uniservice
WO2000067216A9 (fr) Carte bancaire associee a un compte d'especes
WO2001069914A2 (fr) PROCEDES DE GESTION DE TRANSACTIONS SUR L'INTERNET AVEC ADRESSES D'EXPEDITION ANONYMES
WO2000067218A1 (fr) Systeme et procede permettant d'effectuer des paiements electroniques
AU2004201231B2 (en) Method and system for processing internet payments using the electronic funds transfer network
WO2001015045A1 (fr) Procede et appareil pour gerer des transactions prepayees sur un reseau

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

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

WA Withdrawal of international application
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

NENP Non-entry into the national phase in:

Ref country code: JP