WO2000070514A1 - A pre-payment mechanism for use in on-line shopping - Google Patents

A pre-payment mechanism for use in on-line shopping Download PDF

Info

Publication number
WO2000070514A1
WO2000070514A1 PCT/US1999/028131 US9928131W WO0070514A1 WO 2000070514 A1 WO2000070514 A1 WO 2000070514A1 US 9928131 W US9928131 W US 9928131W WO 0070514 A1 WO0070514 A1 WO 0070514A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
repository
merchant
service
Prior art date
Application number
PCT/US1999/028131
Other languages
French (fr)
Inventor
Eric S. Freeman
Luisa Ruiz-Hernandez
Gregory A. Cohen
Original Assignee
Cybermoola, 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 Cybermoola, Inc. filed Critical Cybermoola, Inc.
Priority to AU18332/00A priority Critical patent/AU1833200A/en
Publication of WO2000070514A1 publication Critical patent/WO2000070514A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/02Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/28Pre-payment schemes, e.g. "pay before"
    • 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/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/343Cards including a counter
    • G06Q20/3437Cards including a counter the counter having non-monetary units, e.g. trips
    • 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403Solvency checks
    • G06Q20/4037Remote solvency checks
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means

Definitions

  • the present invention is directed toward the field of electronic commerce, and more particularly toward a pre-payment mechanism to allow users to purchase goods and services over the Internet.
  • E-commerce consists of a buyer who purchases
  • One type of electronic transaction is where a merchant, entitled herein as a web merchant, offers a product and/or service for sale on the Internet.
  • the web merchant displays the goods and/or services offered on a "web site", accessible by a well- established standard protocol, such as the protocol underlying the World Wide
  • commerce transactions must involve a way to transfer legal tender from the buyer to the seller.
  • a consumer purchases a product or service over
  • a credit card is used. However, use of a credit card to conduct e-
  • the age of 18 do not have credit cards.
  • the youth segment of the population constitutes a significant market. Typically, the youth segment shops
  • a pre-payment mechanism permits conducting electronic-commerce
  • the mechanism may consist of a physical card or purely electronic.
  • the user associates a unique serial number, obtained from the pre-payment mechanism, with a user
  • the user selects the prepayment mechanism as a payment option, and submits information, including an
  • the web merchant queries the repository to obtain authorization to purchase the goods or
  • the transaction is conducted between the user and the merchant utilizing
  • the pre-payment mechanism if the merchant obtains authorization from the repository.
  • Figure 1 is a diagram illustrating one embodiment for using the
  • Figure 2 illustrates a general flow for the distribution of pre- payment mechanisms from the repository to the user.
  • Figure 3 is a flow diagram illustrating one embodiment for
  • Figure 4 is a flow diagram illustrating one embodiment for conducting e-commerce using the CybermoolaTM System.
  • Figure 5 illustrates one embodiment for implementing user account services in the CybermoolaTM System.
  • Figure 6 is a flow diagram illustrating one embodiment for a
  • Figure 7a is a block diagram illustrating one embodiment for
  • Figure 7b illustrates the flow for the transaction-approved process.
  • Figure 7c illustrates one embodiment for a transaction reconciliation where the transaction is denied.
  • Figure 8 illustrates a high level block diagram of a general purpose
  • Figure 1 is a diagram illustrating one embodiment for using the
  • pre-payment mechanism for Internet commerce.
  • system that provides a pre-payment mechamsm for users to purchase good and services on ⁇
  • CybermoolaTM System The CybermoolaTM
  • System 100 shown in Figure 1 involves the interaction among a user, such as user 115, a repository 130 (e.g. , CybermoolaTM-repository), and at least one Web
  • the CybermoolaTM System 100 optionally includes a point of sale 120, such as a retail store, and a merchandise warehouse 165 associated with the Web merchant 150. In general, the CybermoolaTM System 100 permits the user 115 to purchase goods/ services offered at a Web merchant
  • the user 115 first acquires a pre-payment mechanism.
  • the prepayment mechanism may comprise a physical card 125 or an electronic prepayment mechamsm.
  • the pre-paid mechamsm is a physical card.
  • the repository 130 generates unique serial numbers
  • the point of sale 120 may consist of a retailer (e.g. , convenience store, grocery store, etc.), vending machines, automated teller machines (ATMs), etc.
  • a retailer e.g. , convenience store, grocery store, etc.
  • vending machines e.g., vending machines, automated teller machines (ATMs), etc.
  • ATMs automated teller machines
  • the physical card contains a means to store information associated
  • the physical card includes
  • the information may also be
  • the information includes the unique serial number embedded on the card as human readable alpha-numeric characters.
  • pre-payment mechamsm contains at least the unique serial number (USN).
  • the pre-payment mechanism may be entirely electronic. For this
  • the user acquires the electronic pre-payment mechanism via the
  • the electronic pre-payment mechamsm also includes information necessary to utilize the CybermoolaTM System of the present invention. A complete description of distributing physical and electronic
  • the pre-payment mechanism is a physical card
  • the physical card is activated prior to use. In general, the activation of the pre-payment
  • the point of sale i.e., retail store
  • the point of sale i.e., retail store
  • pre-payment physical card 125 may be activated at the point of sale 120 by the
  • the user associates the pre-payment mechanism with a user account through use of the unique serial number of the
  • the user account may correspond with more than one
  • the account database 140 (part
  • the repository 130 (e.g. , CybermoolaTM repository) builds
  • a Web merchant is defined as any
  • offering for sale goods and/or services over the Internet, such as offering
  • participating Web merchant includes, as a payment option for purchases of goods
  • the e-commerce 155 portion of Web merchant 150 depicted as the e-commerce 155 portion of Web merchant 150.
  • the e-commerce 155 portion of Web merchant 150 depicted as the e-commerce 155 portion of Web merchant 150.
  • the repository 130 contains the transaction server 145 to interface the repository 145
  • the payment cartridge 160 of the Web Merchant 150 communicates to
  • the transaction server 145 of the repository 130 to authorize transactions.
  • the user 115 makes a purchase at the Web merchant 150. For example, the user may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment mechanism.
  • the user 115 may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment mechanism.
  • the user 115 may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment mechanism.
  • the user 115 may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment mechanism.
  • the user 115 may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment mechanism.
  • the user 115 may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment
  • the Web merchant 150 In response to selecting the pre-payment option, the Web merchant 150.
  • the repository 130 receives the query, ascertains the status of the pre-payment mechanism, and sends a notification indicating whether
  • the repository 130 sends a response to the Web merchant to either "approve” or "reject” the use of the pre-payment
  • repository 130 reconciles the
  • the repository 130 stores transaction) for the purchase of the goods and/or services.
  • the Web merchant thus receives payment for the purchase of the
  • Figure 2 illustrates a general flow for the distribution of pre ⁇
  • the repository 130 provides payment mechanisms from the repository to the user.
  • the repository 130 generates unique serial numbers, human readable, on either
  • the user may purchase the physical card at a retailer (240), vending
  • vending machine e.g. , cash, debit card or credit card
  • the vending machine dispenses a pre-activated card.
  • the user selects the pre-payment mechanism option, the ATM dispenses a pre-activated physical card, and thereafter the ATM repository
  • the user may receive the physical card through a promotion (block
  • An event may include any promotional item (block 255).
  • the card is pre-activated.
  • Electronic pre-payment mechamsm may also be purchased
  • Electronic pre-payment mechanisms may be purchased by the user on-line at a
  • the user visits the merchant web site, selects the pre ⁇
  • the user visits the repository web site over the Internet; pays to the
  • pre-payment mechamsm receives from the repository an e-mail confirmation of the purchase.
  • the recipient of the pre-payment mechanism also receives a confirmation e-mail from the repository.
  • the user may receive the electronic pre-payment mechamsm via
  • the user chooses, at the repository web site, a specific promotion associated with an electronic pre ⁇
  • the user may receive the pre-payment mechanism at the merchant
  • the user receives the pre-payment
  • Figure 3 is a flow diagram illustrating one embodiment for
  • the payment process involves the repository or web merchant site to display a screen that includes: instructions to purchase the electronic pre ⁇
  • the payment process also provides the means for the user to
  • payment feedback involves the repository or web merchant site displaying a purchase confirmation, the amount
  • the site displays a gift form (blocks 315 and 320).
  • the gift form (blocks 315 and 320).
  • a screen includes: fields to specify a recipient to send the gift via e-mail or regular mail; and fields to enter recipient information, such as
  • the account process displays a confirmation of the gift setup (block 325) .
  • the pre-payment mechanism is a physical card purchased by the pre-payment mechanism.
  • the user also initiates the account setup process at the USN entry form (blocks 348 and 330).
  • the unique serial In one embodiment, the unique serial
  • number entry form includes one more screen display that include: an explanation
  • the repository or web merchant site displays card feedback (block 335). In one
  • the repository site displays a screen to indicate whether the physical card is valid. For example, if the physical card was obtained without proper
  • the account setup paid process involves the repository web site
  • the screen may include instructions for
  • the screen also permits the user regarding the CybermoolaTM System.
  • the screen also permits the user
  • the user may wish to remain anonymous, or the user
  • the user enters a PIN setup form (block 342).
  • the PIN setup form includes: information regarding user accounts; PIN setup
  • a PIN setup form feedback page (block 344).
  • the pin setup In one embodiment, the pin setup
  • form feedback page includes; an account number, PIN question/answer
  • Figure 3 also illustrates a flow for electronic pre-payment
  • the promotional page of the account setup process is initiated (block 352).
  • the repository displays a screen that includes: a promotional specific page that
  • the repository displays a screen that
  • the repository web site After submission of the account setup promos information, the repository web site displays a PIN setup
  • the screen includes: information about user accounts; PIN setup input fields; forgotten password question/ answers setup; and
  • the repository web site displays a feedback page (block 358).
  • the feedback page displays: an account number and PIN confirmation; and instructions to proceed to the promotional web page.
  • the user is then directed to proceed to the repository promotional page (block 360).
  • Figure 4 is a flow diagram illustrating one embodiment for
  • e-commerce electronic commerce
  • the user selects, as a payment option, the pre-payment mechanism
  • the web merchant displays a summary of the transaction (blocks 450 and 460).
  • the web merchant ships the goods to the user or provides the service
  • the web merchant informs the user that the transaction is denied (block 475).
  • the CybermoolaTM system includes several components
  • Figure 5 illustrates one embodiment for
  • the user starts at the account services menu (block 500) .
  • the account services menu (block 500) .
  • the account services menu may be selected from the home page of
  • account services include the ability to recharge a user account (block 510), generate a transaction report
  • account service permits a user to add money to an existing account.
  • the repository displays a screen with
  • the user then has the ability to select a payment option, such as entering a credit card, as well as the
  • the repository Web site provides feedback
  • the feedback comprises a screen that displays a
  • a transaction report service (block 540) permits a user to query
  • account information includes the balance on the account
  • Account services also permit a user to transfer funds from his/her
  • a transfer process is initiated by displaying at the
  • a user may either transfer an amount to another account (i.e. , to consolidate accounts) or request a check (block 585).
  • the repository Web site provides a screen to elicit information to send the check (block 590).
  • This screen includes fields for the user to enter an
  • Figure 6 is a flow diagram illustrating one embodiment for a
  • a transaction is conducted between a user and a web merchant with the
  • pre-payment mechamsm used to purchase the goods and/or services (block 600). After completion of the e-commerce transaction, the web merchant ships the
  • the user receives the goods and/or services from the web merchant
  • the web merchant notifies the repository that the goods have been shipped (block 630) .
  • the repository removes the pending status from the e-commerce transaction, and flags the web merchant for payment of the
  • web merchant bank receives the electronic funds transferred from the repository
  • FIGS. 7a-7c illustrate one embodiment for transaction
  • the web merchant operates in conjunction with a payment cartridge
  • Figure 7a is a block diagram
  • FIG. 7a web merchant 700, which incorporates the web merchant Web site,
  • the web merchant 700 is coupled to the payment cartridge 705.
  • the web merchant 700 is coupled to the payment cartridge 705.
  • the web merchant 700 In general, the web merchant 700,
  • a repository 720 incorporates a transaction server 710.
  • the payment cartridge 705 and transaction server 710 are identical to the payment cartridge 705 and transaction server 710
  • the transaction server 710 and payment cartridge are both transaction server 710 and payment cartridge
  • This SSL-enabled protocol provides a secure
  • connection between a web browser and a web server and privacy for purchases
  • the payment cartridge 705 (Fig. 7a) enables a web merchant to connect and communicate transaction data with the transaction server 710.
  • the payment cartridge 705 securely transfers related
  • the payment cartridge 705 is constructed so as to connect with the web merchant server's
  • APIs application program interfaces
  • the transaction server 710 is implemented with Oracle ® 8i.
  • the use of certificate authority and digital certificates is implemented with Oracle ® 8i.
  • Figure 7b illustrates the flow for the transaction-approved process.
  • the repository database 760 is queried to process the transaction.
  • the repository database 760 is queried to process the transaction.
  • systems 700 receives the confirmation message, as well as a reference number
  • the web merchant systems 700 are to uniquely identify the electronic transaction.
  • the web merchant systems 700 are to uniquely identify the electronic transaction.
  • the repository database 760 is accessed to reduce the account balance for the user in the amount of the purchase. At this stage, the amount of available
  • Figure 7c illustrates one embodiment for a transaction reconciliation where the transaction is denied. If the query to the repository
  • a denied transaction may be due to
  • the repository system 720 places the account
  • the repository system 720 transmits an e-mail message to the user as indicated by block 795 in Fig. 7c. Also, as shown in block 790, the user receives the transaction denied message through the e-commerce cartridge
  • the pre-paid CybermoolaTM system of the present invention differs from
  • payment mechanism may be used to target a market that is currently not able to
  • the pre-payment mechanism of the present invention enables the
  • the pre-payment mechamsm also permits those adults who do not have a credit card, perhaps due to a poor credit history, to shop on-line.
  • the pre-payment mechanism may also be used to target a market
  • on-line purchaser may remain anonymous. This anonymity may result in the user receiving fewer commercial solicitations from merchants. This is particularly true if the merchants sell the customer lists to other merchants or marketeers.
  • the pre-payment mechamsm may also be used to target a market
  • the pre-payment mechanism may also be used to target a market
  • pre-payment mechamsm may be used as a budgeting tool. This budgeting strategy may also be applied to target markets that require approved spending
  • pre-payment mechamsm that employee is prevented from purchasing an amount greater than the predetermined limit.
  • the pre-payment mechamsm has further application for use in paying bills on-line.
  • the pre-payment mechanism may also be used to target
  • present invention to conduct transactions over the Internet.
  • the pre-payment mechanism of the CybermoolaTM system has
  • payment mechamsm may be used by web merchants in order to drive Internet
  • a web merchant may launch
  • the pre-payment mechamsm may be used
  • predetermined Web sites For example, a web merchant selling blue jeans may provide to a consumer a predetermined amount on a pre-payment mechanism for
  • pre-payment mechamsm may be used to elicit
  • This marketing technique may also be
  • the pre-payment mechamsm may be used as a promotional tool in a variety of ways, including: to drive on-line shopping at specific sites;
  • Figure 8 illustrates a high level block diagram of a general purpose
  • a computer system 1000 is configured to:
  • the processor unit 1005 contains a processor unit 1005, main memory 1010, and an interconnect bus 1025.
  • the processor unit 1005 may contain a single microprocessor, or may
  • the main memory 1010 stores, in part, instructions
  • the main memory 1010 stores the executable code when in operation.
  • the main memory 1010 may
  • DRAM dynamic random access memory
  • the computer system 1000 further includes a mass storage device
  • peripheral device(s) 1030 peripheral device(s) 1030, portable storage medium drive(s) 1040, input
  • control device(s) 1070 controls the display(s) 1070, a graphics subsystem 1050, and an output display 1060.
  • processor unit 1005 and the main memory 1010 may be connected via a local microprocessor bus, and the mass storage device 1020, peripheral
  • the mass storage may be connected via one or more input/output (I/O) busses.
  • I/O input/output
  • the mass storage may be connected via one or more input/output (I/O) busses.
  • disk drive is a non-volatile storage device for storing data and instructions for
  • the device 1020 stores the CybermoolaTM system software for loading to the main memory 1010.
  • the portable storage medium drive 1040 operates in conjunction
  • a portable non-volatile storage medium such as a floppy disk or a compact
  • CD-ROM disc read only memory
  • the CybermoolaTM system software is stored on such a portable medium, and is input to the computer
  • the peripheral device(s) 1030 may include any type of computer support device, such as an
  • I/O input/output
  • the peripheral device(s) 1030 may include a network
  • interface card for interfacing the computer system 1000 to a network.
  • the input control device(s) 1070 provide a portion of the user
  • the input control device(s) 1070 may include an alphanumeric keypad for inputting alphanumeric and other
  • a cursor control device such as a mouse, a trackball, stylus, or
  • cursor direction keys In order to display textual and graphical information, the
  • computer system 1000 contains the graphics subsystem 1050 and the output
  • the output display 1060 may include a cathode ray tube (CRT)
  • the graphics subsystem 1050 receives
  • the CybermoolaTM system may be implemented in either hardware or software.
  • the CybermoolaTM system is
  • CybermoolaTM system software may reside as encoded information on a computer readable medium, such as a magnetic
  • CD - ROM compact disc read only memory
  • the CybermoolaTM system may comprise a

Abstract

A pre-payment mechanism, consisting of a physical card or purely electronic, permits conducting electronic-commerce transactions over the Internet. The user associates a unique serial number, obtained from the pre-payment mechanism, with a user account maintained by a repository. A merchant website offers products or services for sale to the user, and offers, as a payment option for purchase of the good or service, the pre-payment mechanism. The user selects the pre-payment mechanism as a payment option, and submits information, including an account and a PIN, to identify the pre-payment mechanism. In response, the web merchant queries the repository to obtain authorization to purchase the goods or services. The transaction is conducted between the user and the merchant utilizing the pre-payment mechanism if the merchant obtains authorization from the repository.

Description

A PRE-PAYMENT MECHANISM FOR USE IN ON-LINE SHOPPING
BACKGROUND OF THE INVENTION
Field of the Invention:
The present invention is directed toward the field of electronic commerce, and more particularly toward a pre-payment mechanism to allow users to purchase goods and services over the Internet.
Art Background:
The Internet provides tremendous opportunities to conduct
commerce on-line. In general, the ability to conduct an electronic transaction is
referred to as "e-commerce". E-commerce consists of a buyer who purchases
goods and/or services from a seller or a merchant. One type of electronic transaction is where a merchant, entitled herein as a web merchant, offers a product and/or service for sale on the Internet. Typically, the web merchant displays the goods and/or services offered on a "web site", accessible by a well- established standard protocol, such as the protocol underlying the World Wide
Web. Under this scenario, a user or consumer browses the web merchant's web
site to view products and/or services. The user then selects one or more products
and/or services for purchase.
One reason for the growth of consumer purchasing over the
Internet is that shopping on-line at home is extremely convenient. All e-
commerce transactions must involve a way to transfer legal tender from the buyer to the seller. Typically, when a consumer purchases a product or service over
a web site, a credit card is used. However, use of a credit card to conduct e-
commerce transactions may not be convenient, desirable or even possible in certain cases. For example, typically the youth population (i.e. , persons under
the age of 18) do not have credit cards. However, the youth segment of the population constitutes a significant market. Typically, the youth segment shops
in retail stores using cash. Certain segments of the adult population also find use
of a credit card a bar to on-line shopping. For example, poor credit may result
in the inability for certain adults to obtain credit cards. In addition to hurdles to
access a credit card, consumers are reluctant to use credit cards for on-line
shopping for fear of fraudulent misuse of their credit card, such as theft. Thus, requiring the user to use a credit card for on-line purchases provides a bar or
hurdle for general consumer acceptance of purchasing products on-line.
Accordingly, it is desirable to develop a system that maximizes the convenience
of on-line shopping without requiring the buyer to tender a credit card. It is also
desirable to develop an on-line payment purchase mechamsm that reduces risk to both the buyer and the seller. Furthermore, it is desirable to develop a
purchase mechanism that is an open standard, and does not involve proprietary
hardware, such as a smart card, for widespread use and general acceptance by
the public. SUMMARY OF THE INVENTION
A pre-payment mechanism permits conducting electronic-commerce
transactions over the Internet. A user either purchases the pre-payment mechanism
or receives the pre-payment mechanism in a promotion. The pre-payment
mechanism may consist of a physical card or purely electronic. The user associates a unique serial number, obtained from the pre-payment mechanism, with a user
account maintained by a repository. A merchant website, accessible for on-line
interactive communications between users and a merchant, offers products or services for sale to the user. The merchant website offers, as a payment option for
purchase of the good or service, the pre-payment mechanism. To use the pre¬
payment mechanism to purchase the goods or services, the user selects the prepayment mechanism as a payment option, and submits information, including an
account and a PIN, to identify the pre-payment mechanism. In response, the web merchant queries the repository to obtain authorization to purchase the goods or
services. The transaction is conducted between the user and the merchant utilizing
the pre-payment mechanism if the merchant obtains authorization from the repository.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a diagram illustrating one embodiment for using the
pre-payment mechanism for Internet commerce.
Figure 2 illustrates a general flow for the distribution of pre- payment mechanisms from the repository to the user.
Figure 3 is a flow diagram illustrating one embodiment for
account setup in the Cybermoola™ System.
Figure 4 is a flow diagram illustrating one embodiment for conducting e-commerce using the Cybermoola™ System.
Figure 5 illustrates one embodiment for implementing user account services in the Cybermoola™ System.
Figure 6 is a flow diagram illustrating one embodiment for a
settlement process between the repository and the web merchant.
Figure 7a is a block diagram illustrating one embodiment for
implementing secure communications between a web merchant and a repository
for the Cybermoola™ System.
Figure 7b illustrates the flow for the transaction-approved process.
Figure 7c illustrates one embodiment for a transaction reconciliation where the transaction is denied.
Figure 8 illustrates a high level block diagram of a general purpose
computer system depicting user computers, repository server/computers, and web
merchant server/computers.
DETAILED DESCRIPTION
Figure 1 is a diagram illustrating one embodiment for using the
pre-payment mechanism for Internet commerce. In general, the system that provides a pre-payment mechamsm for users to purchase good and services on¬
line is referred to herein as the "Cybermoola™ System." The Cybermoola™
System 100 shown in Figure 1 involves the interaction among a user, such as user 115, a repository 130 (e.g. , Cybermoola™-repository), and at least one Web
merchant 150. In addition, the Cybermoola™ System 100 optionally includes a point of sale 120, such as a retail store, and a merchandise warehouse 165 associated with the Web merchant 150. In general, the Cybermoola™ System 100 permits the user 115 to purchase goods/ services offered at a Web merchant
web site using the pre-paid mechanism of the present invention.
To permit the user to purchase goods/services at a Web merchant,
via the Internet, the user 115 first acquires a pre-payment mechanism. The prepayment mechanism may comprise a physical card 125 or an electronic prepayment mechamsm. In one embodiment, the pre-paid mechamsm is a physical card. For this embodiment, the repository 130 generates unique serial numbers
for the physical cards, for use as the pre-payment mechamsm. The function of generating unique serial numbers for pre-payment cards is illustrated as
physical/electronic card generation 135 as part of the repository 130 in Figure 1. The physical cards are distributed to various points of sale for purchase by the
general public. This is illustrated in Figure 1 through physical card 125 being
sold at a point of sale 120. For the example shown in Figure 1, the user 115
purchases the physical card 125 at the point of sale 120. The point of sale 120 may consist of a retailer (e.g. , convenience store, grocery store, etc.), vending machines, automated teller machines (ATMs), etc.
The physical card contains a means to store information associated
with the Cybermoola™ System. In one embodiment, the physical card includes
a magnetic stripe with the encoded information. The information may also be
encoded via a bar code. Furthermore, the information includes the unique serial number embedded on the card as human readable alpha-numeric characters. The
pre-payment mechamsm contains at least the unique serial number (USN).
The pre-payment mechanism may be entirely electronic. For this
embodiment, the user acquires the electronic pre-payment mechanism via the
repository web site, a web merchant's site, or any other means for electronic
transfer of the pre-payment mechanism . The electronic pre-payment mechamsm also includes information necessary to utilize the Cybermoola™ System of the present invention. A complete description of distributing physical and electronic
pre-payment mechanisms is described below in conjunction with a discussion of
Figure 2.
If the pre-payment mechanism is a physical card, the physical card is activated prior to use. In general, the activation of the pre-payment
mechanism helps prevent fraudulent use of a physical card that has been obtained
through illicit means. In the point of sale (i.e., retail store) embodiment, the
pre-payment physical card 125 may be activated at the point of sale 120 by the
retailer at the time the user purchases the physical card 125. A validation system
is utilized to validate some pre-payment telephone cards, and thus is well known and will not be described in detail.
Referring again to the example Cybermoola™ System illustrated
in Figure 1 , the user 115, after receipt of the pre-payment mechanism, optionally
registers with the Cybermoola™-repository 130. In a preferred embodiment,
user 115, via the computer 110 and Internet 117, registers on-line at the repository 130 Web site. In general, the process of registration involves setting
up an account for the user. Specifically, the user associates the pre-payment mechanism with a user account through use of the unique serial number of the
pre-payment mechanism. The user account may correspond with more than one
pre-payment mechanism. After user registration, the account database 140 (part
of the repository 130) contains, at a minimum, an account for the user and for
the pre-payment mechamsm as well as a PIN. One embodiment for user registration is illustrated in Figure 3 and described fully below.
The repository 130 (e.g. , Cybermoola™ repository) builds
partnerships with Web merchants. In general, a Web merchant is defined as any
entity that offers for sale goods and/or services over the Internet, such as offering
for sale goods and/or services via a Web site over the World Wide Web. A
participating Web merchant includes, as a payment option for purchases of goods
and/or services, the pre-payment mechanism of the present invention. The
general function of offering goods and/or services over the Internet is graphically
depicted as the e-commerce 155 portion of Web merchant 150. The e-commerce
portion 155 operates in conjunction with a payment cartridge 160. The repository 130 contains the transaction server 145 to interface the repository 145
to multiple Web merchants participating in the Cybermoola™ System. In
general, the payment cartridge 160 of the Web Merchant 150 communicates to
the transaction server 145 of the repository 130 to authorize transactions. To use the pre-payment mechamsm in e-commerce, the user 115 makes a purchase at the Web merchant 150. For example, the user may visit the Web merchant's Web site, select a product or service, and select, as a payment option, the pre-payment mechanism. In a preferred embodiment, the user 115
submits a PIN number as well as the user account number to the Web merchant
150. In response to selecting the pre-payment option, the Web merchant 150
queries the account database 140 at the repository 130. Preferably, this
transaction occurs real time over the Internet or other communications medium (e.g. , telephone lines). The repository 130 receives the query, ascertains the status of the pre-payment mechanism, and sends a notification indicating whether
the transaction is authorized. Specifically, the repository 130 sends a response to the Web merchant to either "approve" or "reject" the use of the pre-payment
mechanism for the specified transaction. If approved, the user receives a
purchase confirmation at the Web merchant site. Alternatively, if the transaction
is rejected by the repository 130, then the user 115 receives a purchase denied
notification.
Assuming the transaction was approved, merchandise, purchased in the transaction, is shipped to the user as graphically illustrated in Figure 1 with the truck 170 delivering the glasses 175 to the user 115. Also, a hold is placed
on the funds in the user account in accordance with the transaction amount.
Furthermore, a confirmation that the merchandise was sent to the user is
delivered to the repository 130. Thereafter, repository 130 reconciles the
transaction with the Web merchant 150 (i.e. , makes the payment for the
transaction) for the purchase of the goods and/or services. The repository 130
debits the account, in the account database 140, associated with the pre-payment
mechanism. The Web merchant thus receives payment for the purchase of the
goods and/or services from the repository 130 per the predetermined merchant-
repository agreement.
Figure 2 illustrates a general flow for the distribution of pre¬
payment mechanisms from the repository to the user. The repository 130
controls the creation of the pre-payment mechamsm (block 200). Specifically,
the repository 130 generates unique serial numbers, human readable, on either
physical cards or electronic pre-payment mechanisms. The creation of a physical
card, under the auspices of the repository 130, is represented in block 210. The
user may either purchase the physical card for a predetermined monetary amount
(block 220) or receive the physical card free of charge as a promotion (block
230). The user may purchase the physical card at a retailer (240), vending
machine (245) or an automated teller machine (ATM) (250). If the user
purchases the physical card at a retailer (240) , the user pays for the physical card
(e.g. , cash, credit card, debit card or check), and the retailer activates the card. To dispense the physical card through a vending machine (245), the user inserts
payment into the vending machine (e.g. , cash, debit card or credit card), and
thereafter the vending machine dispenses a pre-activated card. When using an
ATM machine (250), the user selects the pre-payment mechanism option, the ATM dispenses a pre-activated physical card, and thereafter the ATM repository
(e.g. , bank) debits the user's account in accordance with the value of the physical
card.
The user may receive the physical card through a promotion (block
230), such as an event (block 255). An event may include any promotional
activity for which the physical cards may be distributed. Marketing through use
of promotional events that distribute pre-payment mechamsm is described more fully below. Regardless of the promotion, in one embodiment, the user
physically receives the card in a promotional event sponsored by either the repository or a web merchant. Under this scenario, the card is pre-activated.
Electronic pre-payment mechamsm (260) may also be purchased
for a monetary value (265) or given away free of charge as a promotion (270).
Electronic pre-payment mechanisms may be purchased by the user on-line at a
web site for the repository (275) or purchased on-line at a merchant's web site
(280). For example, to purchase the electronic pre-payment mechamsm on-line
at a merchant's web site, the user visits the merchant web site, selects the pre¬
payment mechanism from the inventory of products at the merchant's web site;
and pays, with a traditional payment mechanism, for the electronic pre-payment mechanism . To purchase the electronic pre-payment mechamsm at the repository
web site, the user: visits the repository web site over the Internet; pays to the
repository, with traditional payment mechanisms, a value associated with the
electronic pre-payment mechamsm; and receives from the repository an e-mail confirmation of the purchase. In addition, if the pre-payment mechamsm is purchased by one party as a gift for a different party, then the recipient of the pre-payment mechanism also receives a confirmation e-mail from the repository.
If the user receives the pre-payment mechamsm through a
promotion, then the user may receive the electronic pre-payment mechamsm via
the repository web site (285). Under this scenario, the user chooses, at the repository web site, a specific promotion associated with an electronic pre¬
payment mechanism or associated with a web merchant. Also, through use of promotions, the user may receive the pre-payment mechanism at the merchant
web site (290). In one embodiment, the user receives the pre-payment
mechanism by "clicking-through" banner ads displayed at the merchant's web
site.
Figure 3 is a flow diagram illustrating one embodiment for
account setup in the Cybermoola™ System. If the pre-payment mechanism is
electronic and purchased on-line (e.g. , at a repository or web merchant site),
then the user enters a payment process (blocks 300 and 305). In one
embodiment, the payment process involves the repository or web merchant site to display a screen that includes: instructions to purchase the electronic pre¬
payment mechanism; means to select a payment option; and a means to exit the
payment process. The payment process also provides the means for the user to
enter the amount desired for the pre-payment mechamsm. After purchasing the
electronic pre-payment mechanism, the user, via the web site, receives payment feedback (block 310). In one embodiment, payment feedback involves the repository or web merchant site displaying a purchase confirmation, the amount
of the pre-payment mechanism, and the unique serial number associated with the
pre-payment mechamsm. At this point, the user may "click to continue" the
account setup process.
If the electronic card is a gift, then the repository or merchant web
site displays a gift form (blocks 315 and 320). In one embodiment, the gift form
includes display of a screen that includes: fields to specify a recipient to send the gift via e-mail or regular mail; and fields to enter recipient information, such as
e-mail address, physical address, name, etc. After completing the gift form screen, the account process displays a confirmation of the gift setup (block 325) .
If the electronic pre-payment mechanism is not a gift, then the account process
proceeds to an account setup page screen described more fully below (blocks 315
and 341). If the pre-payment mechanism is a physical card purchased by the
user, then the account setup process is initiated with the unique serial number
entry form (blocks 327 and 330). Similarly, if the user receives the physical card
through a promotion, then the user also initiates the account setup process at the USN entry form (blocks 348 and 330). In one embodiment, the unique serial
number entry form includes one more screen display that include: an explanation
of the Cybermoola™ System; a field to enter the USN contained on the physical
card; as well as other data pertinent to identify the physical card (e.g., details of the promotion, time period offer is valid, value conferred in the promotion,
and sponsor guidelines). After submission by the user of the USN entry form,
the repository or web merchant site displays card feedback (block 335). In one
embodiment, the repository site displays a screen to indicate whether the physical card is valid. For example, if the physical card was obtained without proper
activation of the card, then the user would receive an indication that the card is
not available for use in the Cybermoola™ System. If valid, the user is then prompted to "click to continue" to proceed to the next level of the account setup
process.
If the physical card procured by the user is not from a promotion,
then the user proceeds to account setup (blocks 340 and 341). In one
embodiment, the account setup paid process involves the repository web site
displaying an account setup paid screen. The screen may include instructions for
the user regarding the Cybermoola™ System. The screen also permits the user
to select options as to the type and amount of information submitted to the
repository. For example, the user may wish to remain anonymous, or the user
may submit more detailed demographic information. After the account setup
paid process, the user enters a PIN setup form (block 342). In one embodiment, the PIN setup form includes: information regarding user accounts; PIN setup
input forms to permit a user to submit a PIN; fields to enter passwords to query
account status; fields to determine forgotten passwords question/answer setup;
and a display of conditions and restrictions regarding the user account. After
submission of the PIN setup form by the user, the repository web site displays
a PIN setup form feedback page (block 344). In one embodiment, the pin setup
form feedback page includes; an account number, PIN question/answer
confirmation; and instructions for the user to use the pre-payment mechanism to purchase goods/ services through e-commerce.
Figure 3 also illustrates a flow for electronic pre-payment
mechanisms offered at a repository web site or a merchant web site as a
promotion (block 350). If the user receives either a physical card or an
electronic pre-payment mechanism through a promotion, then the promotional page of the account setup process is initiated (block 352). In one embodiment, the repository displays a screen that includes: a promotional specific page that
includes the promotional offer information; and special instructions, if any,
pertaining to the promotion. After submission of the promo page, the account
process proceeds to the account setup promos (block 354). In one embodiment,
for the account setup promos process, the repository displays a screen that
includes: additional information, if any, regarding the promotion; and an entry
form that queries the user to enter basic account information, as well as
information requested by the sponsor of the promotion. After submission of the account setup promos information, the repository web site displays a PIN setup
form (block 356). Similar to the PIN setup form discussed above in conjunction
with the account setup paid process, the screen includes: information about user accounts; PIN setup input fields; forgotten password question/ answers setup; and
conditions, restrictions and caveats on the promotion. After submission of the
PIN setup form, the repository web site displays a feedback page (block 358).
The feedback page displays: an account number and PIN confirmation; and instructions to proceed to the promotional web page. The user is then directed to proceed to the repository promotional page (block 360).
Figure 4 is a flow diagram illustrating one embodiment for
conducting e-commerce using the Cybermoola™ System. The process to conduct
electronic commerce (e-commerce) is initiated when the user, on a computer
system, visits a merchant's web site via the Internet (block 410). At the merchant's web site, the user selects a product and/or service (block 415). In
addition, the user selects, as a payment option, the pre-payment mechanism
(block 420). To use the pre-payment mechanism, the user enters the account
number, obtained from the account setup process, and the user PIN (block 430).
The user then waits for authorization that the pre-payment mechanism may be
used to conduct the transaction (block 440). If the transaction is approved, then
the web merchant displays a summary of the transaction (blocks 450 and 460).
Thereafter, the web merchant ships the goods to the user or provides the service
to the user (block 470). Alternatively, if the transaction is not approved, then the web merchant informs the user that the transaction is denied (block 475).
In one embodiment, the Cybermoola™ system includes several
services relating to the user account. Figure 5 illustrates one embodiment for
implementing user account services in the Cybermoola™ system. To initiate
account services, the user starts at the account services menu (block 500) . In one
embodiment, the account services menu may be selected from the home page of
the repository Web site. For this embodiment, account services include the ability to recharge a user account (block 510), generate a transaction report
(block 540), and transfer funds from the user account (block 570). The recharge
account service permits a user to add money to an existing account. When the
user imtiates the recharge account service, a payment process is initiated (block
520). To initiate the payment process, the repository displays a screen with
instructions to instruct the user regarding the process. The user then has the ability to select a payment option, such as entering a credit card, as well as the
ability to enter the monetary amount to recharge the account. After submission
of the payment process information, the repository Web site provides feedback
to the user (block 530). The feedback comprises a screen that displays a
confirmation that the account has been increased by the monetary amount input
by the user.
A transaction report service (block 540) permits a user to query
his/her account for information pertaining to the account. Specifically, the user
queries the repository database to learn account information (block 550). In one embodiment, account information includes the balance on the account,
transaction history. In response to the query, a report is generated and displayed
(block 560).
Account services also permit a user to transfer funds from his/her
account (block 570). A transfer process is initiated by displaying at the
repository Web site instructions and conditions (i. e. , fees for transfer) to transfer
funds from the user account. In addition, the user enters an amount to transfer
as part of the transfer process. A user may either transfer an amount to another account (i.e. , to consolidate accounts) or request a check (block 585). To
transfer funds to another account, the system generates another pre-payment
mechanism, with its own unique serial number (USN). In turn, the user
associates the new unique serial number (USN) with the recipient account. In addition, a confirmation message is provided regarding the amount transferred
and the USN of the recipient account (block 595). If the user selects to receive
a check, the repository Web site provides a screen to elicit information to send the check (block 590). This screen includes fields for the user to enter an
address. In addition, a confirmation is displayed that includes the check recipient
address and the amount transferred from the user account (block 597).
Figure 6 is a flow diagram illustrating one embodiment for a
settlement process between the repository and the web merchant. As discussed
above, a transaction is conducted between a user and a web merchant with the
pre-payment mechamsm used to purchase the goods and/or services (block 600). After completion of the e-commerce transaction, the web merchant ships the
goods to the user 620 or performs a service for the user 620 (blocks 610 and
620). The user receives the goods and/or services from the web merchant
purchased on line. Thereafter, the web merchant notifies the repository that the goods have been shipped (block 630) . The repository removes the pending status from the e-commerce transaction, and flags the web merchant for payment of the
transaction amount. This step is symbolized through the repository's operations
on the repository database (blocks 640 and 650). The repository, or its banking
agent, makes an electronic transfer to the web merchant bank (block 660). The
web merchant bank receives the electronic funds transferred from the repository
(or repository merchant bank) to satisfy the amount of the e-commerce
transaction (block 670). In turn, the web merchant affiliate bank debits the web merchant's account for the amount transferred (block 680). Accordingly, the web merchant receives payment for the e-commerce transaction. Figure 6
outlines a high level transfer of funds between the repository and the web merchant. However, the actual payment settlement process is dependent upon an agreement between the repository and the web merchant.
Figures 7a-7c illustrate one embodiment for transaction
reconciliation between the repository and the web merchant. In one embodiment,
the web merchant operates in conjunction with a payment cartridge, and the
repository incorporates a transaction server. Figure 7a is a block diagram
illustrating one embodiment for implementing secure communications between a web merchant and a repository for the Cybermoola™ system. As shown in
Figure 7a, web merchant 700, which incorporates the web merchant Web site,
is coupled to the payment cartridge 705. In general, the web merchant 700,
through the payment cartridge 705, sends secure notification with a digital certificate to the repository to verify payment for an e-commerce transaction. A repository 720 incorporates a transaction server 710. The transaction server 710
receives the secure notification with the digital certificate transmitted from the
payment cartridge, and processes the request in real time (i.e. , determines
whether the account associated with the pre-payment mechamsm is sufficient to
conduct the transaction).
In general, the payment cartridge 705 and transaction server 710
(i. e. , a server that runs a transaction engine) provide the functionality required
to facilitate secure non-credit based payment transactions on the Internet.
Industry standard specifications to conduct secure electronic transactions among
virtual networks are available. One standard includes the Secure Socket Layer
(SSL). In one embodiment, the transaction server 710 and payment cartridge
705 support end-to-end SSL. The SSL protocol insures the confidentiality of the
notification sent over the Internet. This SSL-enabled protocol provides a secure
connection between a web browser and a web server, and privacy for purchases
and monetary transactions conducted on-line. In addition, the SSL protocol is
combined with digital certificates.
The payment cartridge 705 (Fig. 7a) enables a web merchant to connect and communicate transaction data with the transaction server 710.
Through an SSL handshake, the payment cartridge 705 securely transfers related
transaction data from the web merchant for immediate processing. The payment cartridge 705 is constructed so as to connect with the web merchant server's
application program interfaces (APIs). In turn, the payment cartridge 705
communicates directly with the transaction server 710 using the SSL and Xcert
digital certificates. In one embodiment, the transaction server 710 is implemented with Oracle® 8i. The use of certificate authority and digital
certificates is well known in the art of implementing secured transactions on-line,
and will not be described further.
Figure 7b illustrates the flow for the transaction-approved process. After the repository 720 receives, via the transaction server 710 and payment
cartridge 705, the secure notification, the notification of the transaction is
processed. To process the transaction, the repository database 760 is queried to
determine whether the account balance for the identified user is sufficient to satisfy the amount of the transaction. If it is, then an approved confirmation
message is sent from the transaction server 710 of the repository systems 720 to
the payment cartridge 705 of the web merchant systems 700. The web merchant
systems 700 receives the confirmation message, as well as a reference number
to uniquely identify the electronic transaction. The web merchant systems 700
transmits a transaction complete message, as shown in block 770 of Fig. 7b. In
addition, the repository database 760 is accessed to reduce the account balance for the user in the amount of the purchase. At this stage, the amount of available
funds to the user is reduced, temporarily or permanently.
Figure 7c illustrates one embodiment for a transaction reconciliation where the transaction is denied. If the query to the repository
database 700 determined that the account associated with the pre-payment mechanism is insufficient for the e-commerce transaction, then the repository
systems 720 transmit a transaction denied message to the web merchant systems
700 as indicated by the arrow in Fig. 7c. A denied transaction may be due to
insufficient funds or an incorrect account number/PIN combination. In one
embodiment, after three attempts to conduct a transaction with an incorrect
account number/PIN combination, the repository system 720 places the account
on hold. In addition, the repository system 720 transmits an e-mail message to the user as indicated by block 795 in Fig. 7c. Also, as shown in block 790, the user receives the transaction denied message through the e-commerce cartridge
of the web merchant system 700 or through the repository system e-mail
message.
The pre-paid Cybermoola™ system of the present invention differs
significantly from traditional mechanisms. As described more fully below, these
differences permit using the pre-payment mechanism as a marketing tool for both
business-to-consumer and business-to-business Internet commerce. The pre¬
payment mechanism may be used to target a market that is currently not able to
shop on-line. For example, the youth segment of the population, which consists of a significant number of on-line users, typically do not have access to a credit
card. Thus, this youth segment of the market is not permitted to conduct e- commerce. The pre-payment mechanism of the present invention enables the
youth segment to purchase goods and/or services on-line This is particularly important due to the general acceptance of Internet usage with the youth segment.
The pre-payment mechamsm also permits those adults who do not have a credit card, perhaps due to a poor credit history, to shop on-line.
The pre-payment mechanism may also be used to target a market
that is concerned about privacy on the Internet and wishes to remain anonymous.
When using a credit card, the identify of the user is revealed to the web
merchant. With use of the pre-payment mechamsm of the present invention, the
on-line purchaser may remain anonymous. This anonymity may result in the user receiving fewer commercial solicitations from merchants. This is particularly true if the merchants sell the customer lists to other merchants or marketeers. The pre-payment mechamsm may also be used to target a market
that is concerned about what transactions appear on their current payment
mechanisms. For example, if an individual does not want a particular transaction
to appear on that individual's monthly credit card statement, use of the pre¬
payment mechanism of the present invention permits eliminating certain
transactions from appearing on that statement.
The pre-payment mechanism may also be used to target a market
that prefers controlled spending. For example, if a consumer desires to limit spending to a predetermined amount for a time period, that consumer may
purchase a pre-payment mechamsm for the predetermined amount. Thus, the
pre-payment mechamsm may be used as a budgeting tool. This budgeting strategy may also be applied to target markets that require approved spending
limits for business-to-business procurement. For example, an employee may be
given a limit to purchase products from another business. Through use of the
pre-payment mechamsm, that employee is prevented from purchasing an amount greater than the predetermined limit. The pre-payment mechamsm has further application for use in paying bills on-line.
The pre-payment mechanism may also be used to target
international markets that do not use credit cards without signatures. When using
a credit card for e-commerce over the Internet, the use of signatures is not
possible without an elaborate user input device. Thus, individuals in those countries (i.e. , Western Europe) may use the pre-payment mechanism of the
present invention to conduct transactions over the Internet.
The pre-payment mechanism of the Cybermoola™ system has
further applications as a marketing device for merchants. For example, the pre¬
payment mechamsm may be used by web merchants in order to drive Internet
traffic or usage to specific Web sites. Specifically, the pre-payment mechanism
may be used in promotions, such that the web merchant distributes a pre-payment
mechanism for use at their Web site. For example, a web merchant may launch
a promotion that awards a user with a pre-payment mechamsm if the user visits the merchant's Web site. Similarly, the pre-payment mechamsm may be used
by a web merchant as a marketing tool to drive consumer purchasing at
predetermined Web sites. For example, a web merchant selling blue jeans may provide to a consumer a predetermined amount on a pre-payment mechanism for
use toward purchase of blue jeans at the merchant's Web site. The use of prepayment mechanisms in the Cybermoola™ systems for promotional use is
described above. Furthermore, the pre-payment mechamsm may be used to elicit
demographic information from consumers. For example, a Web site, used for
marketing purposes, could invite consumers to fill out forms to elicit
predetermined demographic information in exchange for a predetermined amount
of value in a prepayment mechamsm. This marketing technique may also be
implemented at the repository site. As will be appreciated by one skilled in the
area of marketing, the pre-payment mechamsm may be used as a promotional tool in a variety of ways, including: to drive on-line shopping at specific sites;
to capture detailed demographic information; and to drive on-line shopping by
predetermined dates at specific sites.
Computer System:
Figure 8 illustrates a high level block diagram of a general purpose
computer system depicting the user computer system, repository
server/computer, and web merchant server/computers. A computer system 1000
contains a processor unit 1005, main memory 1010, and an interconnect bus 1025. The processor unit 1005 may contain a single microprocessor, or may
contain a plurality of microprocessors for configuring the computer system 1000
as a multi-processor system. The main memory 1010 stores, in part, instructions
and data for execution by the processor unit 1005. If the Cybermoola™ system of the present invention is partially implemented in software, the main memory
1010 stores the executable code when in operation. The main memory 1010 may
include banks of dynamic random access memory (DRAM) as well as high speed
cache memory.
The computer system 1000 further includes a mass storage device
1020, peripheral device(s) 1030, portable storage medium drive(s) 1040, input
control device(s) 1070, a graphics subsystem 1050, and an output display 1060.
For purposes of simplicity, all components in the computer system 1000 are shown in Figure 8 as being connected via the bus 1025. However, the computer system 1000 may be connected through one or more data transport means. For
example, the processor unit 1005 and the main memory 1010 may be connected via a local microprocessor bus, and the mass storage device 1020, peripheral
device(s) 1030, portable storage medium drive(s) 1040, graphics subsystem 1050
may be connected via one or more input/output (I/O) busses. The mass storage
device 1020, which may be implemented with a magnetic disk drive or an optical
disk drive, is a non-volatile storage device for storing data and instructions for
use by the processor unit 1005. In the software embodiment, the mass storage
device 1020 stores the Cybermoola™ system software for loading to the main memory 1010.
The portable storage medium drive 1040 operates in conjunction
with a portable non-volatile storage medium, such as a floppy disk or a compact
disc read only memory (CD-ROM), to input and output data and code to and from the computer system 1000. In one embodiment, the Cybermoola™ system software is stored on such a portable medium, and is input to the computer
system 1000 via the portable storage medium drive 1040. The peripheral device(s) 1030 may include any type of computer support device, such as an
input/output (I/O) interface, to add additional functionality to the computer
system 1000. For example, the peripheral device(s) 1030 may include a network
interface card for interfacing the computer system 1000 to a network.
The input control device(s) 1070 provide a portion of the user
interface for a user of the computer system 1000. The input control device(s) 1070 may include an alphanumeric keypad for inputting alphanumeric and other
key information, a cursor control device, such as a mouse, a trackball, stylus, or
cursor direction keys. In order to display textual and graphical information, the
computer system 1000 contains the graphics subsystem 1050 and the output
display 1060. The output display 1060 may include a cathode ray tube (CRT)
display or liquid crystal display (LCD). The graphics subsystem 1050 receives
textual and graphical information, and processes the information for output to the
output display 1060. The components contained in the computer system 1000 are
those typically found in general purpose computer systems, and in fact, these components are intended to represent a broad category of such computer
components that are well known in the art.
The Cybermoola™ system may be implemented in either hardware or software. For the software implementation, the Cybermoola™ system is
software that includes a plurality of computer executable instructions for implementation on a general purpose computer system. Prior to loading into a
general purpose computer system, the Cybermoola™ system software may reside as encoded information on a computer readable medium, such as a magnetic
floppy disk, magnetic tape, and compact disc read only memory (CD - ROM).
In one hardware implementation, the Cybermoola™ system may comprise a
dedicated processor including processor instructions for performing the functions described herein. Circuits may also be developed to perform the functions
described herein.
Although the present invention has been described in terms of
specific exemplary embodiments , it will be appreciated that various modifications
and alterations might be made by those skilled in the art without departing from the spirit and scope of the invention.

Claims

WHAT IS CLAIMED IS:
1. A method for conducting an electronic-commerce transaction, comprising: providing a website accessible to a user, via a computer network; offering a product or service to the user at the website, the product or service having an offer price; receiving pre-payment data as a form of payment from the user; querying a pre-payment repository via the computer network; receiving an approval from the pre-payment repository when the pre- payment repository determines that a pre-payment account associated with the pre- payment data includes an amount that is at least equal to the offer price; accepting the form of payment in response to the approval, thereby effectuating the electronic-commerce transaction of the product or service.
2. The method of claim 1 wherein the pre-payment data is contained in a physical card.
3. The method of claim 1 wherein the pre-payment data is alphanumeric information contained on a physical card in a visually readable format.
4. The method of claim 2 further comprising a step of activating the physical card prior to use by the user.
5. The method of claim 1 wherein querying a pre-payment repository comprises: transferring transaction data for the electronic-commerce transaction from the website to the pre-payment repository, the transaction data including a monetary value in response to the offer price and the pre-payment data; determining whether said the pre-payment account associated with the pre- payment data includes an amount that is at least equal to the monetary value; and transferring the approval of the pre-payment data to the website.
6. The method of claim 5 further comprising: establishing a pre-payment account with the pre-payment repository; debiting the pre-payment account by the monetary value corresponding to the offer price; and crediting an account associated with the website by the monetary value.
7. A method for conducting an electronic-commerce transaction, comprising: providing a merchant website accessible to at least one user, via a computer system, for on-line interactive communications between the user and a merchant; offering, at the merchant website, at least one product or service for sale to the user; providing on the merchant website, as a payment option for purchase of the good or service, a pre-payment mechanism; receiving from the user selection of the pre-payment mechanism as the payment option; receiving an identification from the user for the pre-payment mechanism, wherein the pre-payment mechanism comprises a monetary value; and conducting a transaction between the user and the merchant utilizing the pre-payment mechanism to purchase the good or service.
8. A method for conducting an electronic-commerce transaction, comprising: offering a pre-payment mechanism to at least one user, the pre-payment mechanism comprising a monetary value; associating a pre-payment repository with a merchant, the merchant providing a merchant website accessible to the user, via a computer system, for on-line interactive communications between the user and the merchant, so as to offer, at the merchant website, at least one product or service for sale to the user; receiving, at the pre-payment repository, a request from the merchant to obtain authorization to purchase a good or service by the user utilizing the pre-payment mechanism; and generating a response to the request by either accepting or denying authorization to use the pre-payment mechanism to purchase the good or service.
9. A method for conducting an electronic-commerce transaction, comprising: purchasing at a point-of-sale location a pre-payment card having pre- payment data and a monetary amount associated with the pre-payment data; viewing a website offering a product or service for sale at a transaction price via a computer network; submitting the pre-payment data to the website as a form of payment; receiving acceptance of the form of payment from the website in response to the pre-payment data when the monetary amount is not less than the transaction price.
10. A computer system for conducting an electronic-commerce transaction, comprising: a processor; and a computer-readable memory coupled to the processor, the computer- readable memory including: code that directs the processor to provide a website accessible to a user, via a computer network; code that directs the processor to offer a product or service to the user at the website, the product or service having an offer price; code that directs the processor to receive pre-payment data as a form of payment from the user; code that directs the processor to query a pre-payment repository via the computer network; code that directs the processor to receive an approval from the pre- payment repository when the pre-payment repository determines that a pre-payment account associated with the pre-payment data includes an amount that is at least equal to the offer price; and code that directs the processor to accept the form of payment in response to the approval, thereby effectuating the electronic-commerce transaction for the product or service.
11. A computer program product for a computer system including a processor, comprising: a computer-readable memory including: code that directs the processor to provide a website accessible to a user, via a computer network; code that directs the processor to offer a product or service to the user at the website, the product or service having a offer price; code that directs the processor to receive pre-payment data as a form of payment from the user; code that directs the processor to query a pre-payment repository via the computer network; code that directs the processor to receive an approval from the pre- payment repository when the pre-payment repository determines that a pre-payment account associated with the pre-payment data includes an amount that is at least equal to the offer price; and code that directs the processor to accept the form of payment in response to the approval, thereby effectuating an electronic-commerce transaction for the product or service.
PCT/US1999/028131 1999-05-17 1999-11-23 A pre-payment mechanism for use in on-line shopping WO2000070514A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU18332/00A AU1833200A (en) 1999-05-17 1999-11-23 A pre-payment mechanism for use in on-line shopping

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US31308999A 1999-05-17 1999-05-17
US09/313,089 1999-05-17

Publications (1)

Publication Number Publication Date
WO2000070514A1 true WO2000070514A1 (en) 2000-11-23

Family

ID=23214341

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/028131 WO2000070514A1 (en) 1999-05-17 1999-11-23 A pre-payment mechanism for use in on-line shopping

Country Status (2)

Country Link
AU (1) AU1833200A (en)
WO (1) WO2000070514A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001088770A1 (en) * 2000-05-15 2001-11-22 David Gordon Attwells An improved method of purchasing or hiring products on the internet
WO2001095203A1 (en) * 2000-06-08 2001-12-13 Kim Hong Il A check/card for internet based commerce and a method for dealing the check/card
FR2823882A1 (en) * 2001-04-23 2002-10-25 New Access Sa Commercial transaction using prepayment card over the Internet, uses personal computer or mobile phone, certification center validates data contained on prepayment card
US20200160408A1 (en) * 2018-11-15 2020-05-21 Capital One Services, Llc Systems and methods for secure distributed crowdfunding

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577109A (en) * 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
JPH10261021A (en) * 1997-03-19 1998-09-29 U Card:Kk Personal register service system and reading system for charged information
EP0921487A2 (en) * 1997-12-08 1999-06-09 Nippon Telegraph and Telephone Corporation Method and system for billing on the internet

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577109A (en) * 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
JPH10261021A (en) * 1997-03-19 1998-09-29 U Card:Kk Personal register service system and reading system for charged information
EP0921487A2 (en) * 1997-12-08 1999-06-09 Nippon Telegraph and Telephone Corporation Method and system for billing on the internet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 1998, no. 14 31 December 1998 (1998-12-31) *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001088770A1 (en) * 2000-05-15 2001-11-22 David Gordon Attwells An improved method of purchasing or hiring products on the internet
WO2001095203A1 (en) * 2000-06-08 2001-12-13 Kim Hong Il A check/card for internet based commerce and a method for dealing the check/card
FR2823882A1 (en) * 2001-04-23 2002-10-25 New Access Sa Commercial transaction using prepayment card over the Internet, uses personal computer or mobile phone, certification center validates data contained on prepayment card
US20200160408A1 (en) * 2018-11-15 2020-05-21 Capital One Services, Llc Systems and methods for secure distributed crowdfunding

Also Published As

Publication number Publication date
AU1833200A (en) 2000-12-05

Similar Documents

Publication Publication Date Title
US10825016B2 (en) Electronic bearer bond online transaction and card system and method thereof
US6456984B1 (en) Method and system for providing temporary credit authorizations
US7734527B2 (en) Method and apparatus for making secure electronic payments
US6332134B1 (en) Financial transaction system
US7249099B2 (en) Method and apparatus for conducting electronic commerce transactions using electronic tokens
US8630896B2 (en) Systems and methods wherein a security deposit facilitates a transaction in which a benefit is applied in exchange for performance of a task
US20030004828A1 (en) Prepaid card authorization and security system
US20070179865A1 (en) Method for anonymous purchase of goods by providing a pluarlity of non-activated account numbers
US20130317984A1 (en) Method and system for processing internet payments using the electronic funds transfer network
US20010051902A1 (en) Method for performing secure internet transactions
US20030105672A1 (en) Method and apparatus to facilitate payment over a computer network
US20020103753A1 (en) Charge splitter application
US20030163423A1 (en) Method and apparatus for secure electronic payment
US20020091634A1 (en) System and method for deferring payments
WO2008018052A2 (en) Secure mechanism and system for processing financial transactions
US20020128911A1 (en) Electronic coupon method, electronic coupon system, marketing server, purchaser terminal, order-receiving terminal, and program
US8321344B2 (en) Self-service terminal
WO2002029508A2 (en) Broker-mediated online shopping system and method
WO2001069832A2 (en) System and method for safe financial transactions in e.commerce
MXPA01004206A (en) An online purchase system and method.
US20030041022A1 (en) Electronic money instrument
WO2000067178A2 (en) Anonymous on-line payment system and method
JP2003534604A (en) System and method for facilitating payment over the internet or similar communication medium
WO2000070514A1 (en) A pre-payment mechanism for use in on-line shopping
WO2000067216A9 (en) A banking card associated with a cash account

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref country code: AU

Ref document number: 2000 18332

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM 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 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 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase