WO1999007121A9 - Method and system for conducting electronic commerce transactions - Google Patents

Method and system for conducting electronic commerce transactions

Info

Publication number
WO1999007121A9
WO1999007121A9 PCT/US1998/015884 US9815884W WO9907121A9 WO 1999007121 A9 WO1999007121 A9 WO 1999007121A9 US 9815884 W US9815884 W US 9815884W WO 9907121 A9 WO9907121 A9 WO 9907121A9
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
payment
customer
remote
item
Prior art date
Application number
PCT/US1998/015884
Other languages
French (fr)
Other versions
WO1999007121A2 (en
WO1999007121A3 (en
Inventor
Richard J Fetik
Original Assignee
Netadvantage Corp
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 Netadvantage Corp filed Critical Netadvantage Corp
Priority to EP98938165A priority Critical patent/EP1004086A2/en
Priority to JP2000505721A priority patent/JP2001512863A/en
Priority to AU86753/98A priority patent/AU8675398A/en
Priority to IL13417898A priority patent/IL134178A0/en
Priority to CA002297930A priority patent/CA2297930A1/en
Publication of WO1999007121A2 publication Critical patent/WO1999007121A2/en
Publication of WO1999007121A9 publication Critical patent/WO1999007121A9/en
Publication of WO1999007121A3 publication Critical patent/WO1999007121A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention pertains in general to electronic commerce and in particular to a method and system for conducting electronic payment transactions via the Internet.
  • these goods and services are displayed on the merchant's web site and a prospective customer views, selects, and purchases the goods using web browsing software such as NETSCAPE NAVIGATOR ® .
  • the customer usually pays for a product by establishing a secure connection with the merchant's web server and transmitting payment information, such as a credit card number, to the merchant.
  • the merchant uses back-end processing to verify the payment information and receive payment.
  • the merchant may use a secure telephone line or network link to contact the credit card issuer before accepting the customer's order.
  • the merchant and credit card issuer settle payment and the merchant delivers the product or service to the customer.
  • a difficulty with the above-described scenario is that each merchant must implement an inventory and payment database and a payment acceptance and verification system.
  • the merchant must establish and maintain a database tracking sales, delivery, and payment information and product inventories in order to support the electronic commerce system.
  • This database There is significant cost and complexity in maintaining this database, including the difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by the scarcity of truly skilled personnel.
  • the merchant must design web pages to securely accept the order and payment information and implement the functionality to verify the payment. These tasks can be extremely difficult if the merchant accepts payment using many different methods, such as credit cards and electronic fund transfers, or accepts payment in more than one currency.
  • having a large number of separate payment acceptance systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of each system can be exploited.
  • the method and system will allow the merchant to easily and verifiably perform inventory, sales, and delivery tracking and transparently support different types of payments and currencies.
  • the above needs are met by a method and system for conducting electronic commerce transactions that allows a merchant to easily sell a mix of physical and intangible items and supports sales, inventory, and delivery tracking and a variety of payment systems by having the merchant establish an account on a commerce server.
  • the commerce server provides the merchant with inventory, accounting, and order management systems. Furthermore, the commerce server allows merchants to conduct electronic commerce with other merchants and vendors.
  • the commerce server includes a web server providing web pages to the merchant. By using these web pages, the merchant establishes an account on the commerce server. Then, the merchant provides the commerce server with information about an item sold by the merchant, such as a plane ticket, clothing, a book, a software product, or playing time with an online game. The merchant also provides the commerce server with other attributes of the item from which the customer may select, for example, the quantity or duration of an item. In addition, the merchant supplies payment processing rules defining the payment options that are acceptable to the merchant, such as which currencies and payment systems are allowed and when or how often to bill the customer. The commerce server preferably stores the information received from the merchant in an entry of a database.
  • the database entry categorizes the item as a hard good, soft good, or online good depending upon the delivery options available for the item.
  • the commerce server provides the merchant with a "payment button” including a universal resource locator ("URL") that points to the commerce server and includes information allowing the commerce server to identify the database entry with which the payment button is associated.
  • the merchant preferably publishes the payment button on the merchant's web site.
  • the customer selects the payment button when the customer wishes to purchase the associated product.
  • the customer's computer is automatically directed to the web server managed by the commerce server and provided with the item information entered by the merchant.
  • the customer is presented with the payment options allowed by the merchant's payment processing rules.
  • the customer then provides the web server with the payment information necessary to complete the transaction.
  • the commerce server preferably identifies the remote payment system selected by the customer and contacts it to complete the electronic commerce transaction.
  • a module within the commerce server converts calls generated by the commerce server into the format used by the selected payment system. Likewise, the module converts responses received from the payment system into the format used by the commerce server. Then, the commerce server notifies the customer and the merchant of the result of the electronic commerce transaction and, if appropriate, delivers the item using one of the delivery options specified in the database.
  • a method of conducting electronic commerce between a remote customer and a remote merchant in accordance with the present invention includes receiving information identifying an item to be purchased by the customer, receiving payment information specifying a payment method to be used by the customer to purchase the item, conducting a payment transaction with a remote payment system specified by the payment information, and providing the customer and the merchant with the result of the payment transaction.
  • computer program instructions for conducting electronic commerce transactions include instructions for storing item information received from the merchant, instructions for issuing the merchant a reference to the stored item information, instructions for receiving an electronic commerce transaction identifier from the customer containing the reference to the stored item information issued to the merchant, instructions for accepting payment information from the customer, and instructions for conducting the electronic commerce transaction with a remote payment system.
  • FIGURE 1 is a high-level block diagram of an electronic commerce system according to an embodiment of the present invention.
  • FIGURE 2 is a high-level block diagram illustrating functional components of a commerce server according to an embodiment of the present invention
  • FIGURE 3 is a high-level block diagram of an entry in a database associated with the commerce server according to an embodiment of the present invention
  • FIGURE 4 is a flow diagram illustrating the interactions between the customer, merchant, commerce server, and payment system when completing a payment transaction according to an embodiment of the present invention.
  • FIGURE 5 illustrates an exemplary screen display of a web page seeking payment information from a customer
  • FIGURE 6 illustrates an exemplary screen display of an order confirmation web page.
  • the "Internet” refers to the global network of interconnected computer systems and the “World Wide Web” (“WWW”) refers to the global hypertext system using the Internet as its transport mechanism.
  • a "universal resource locator” (“URL”) is a reference to a piece of information or a software function on a computer connected to the Internet.
  • a “web server” is a program that accepts requests for information framed according to the HyperText Transport Protocol (“HTTP”).
  • Web pages are the information supplied by the web server in response to the requests.
  • the Common Gateway Interface (“CGI”) is the standard that describes how the web server accesses external programs, usually called “CGI programs” or “CGI scripts,” called by a web page.
  • CGI Common Gateway Interface
  • the present invention is not limited to the Internet and may be used with any digital network supporting electronic commerce.
  • the terms defined above also include the non-Internet-based equivalents for communicating between the various entities described herein.
  • FIG. 1 is a high-level block diagram of an electronic commerce system 100 according to an embodiment of the present invention. Illustrated are a customer computer (sometimes referred to as “the customer") 110, a merchant web server (sometimes referred to as “the merchant”) 112, and a commerce server (“CS") 114, all coupled to the Internet 116.
  • the customer computer 110 is a personal computer having, among other things, a processor, memory, storage device, and monitor.
  • the customer computer 110 is coupled to the Internet 116 via a network connection 118.
  • the network connection may be, for example, a modem coupled to an analog telephone line, a digital subscriber line, a cable modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any other communications medium.
  • Web browsing software such as NETSCAPE NAVIGATOR ® preferably executes on the client computer and sends data from the client computer 110 to the merchant web server 112 via the network connection 118 and Internet 116.
  • the customer computer 110 is a palm-top device or personal digital system communicating via radio waves with the Internet 116 or another electronic commerce system.
  • the merchant web server 112 is preferably similar to the customer computer 110 except that it is has the processing power and communications 116 bandwidth to handle multiple simultaneous customer transactions.
  • the merchant 112 sells items, such as merchandise, information, intellectual property, and/or services via a web site hosted on the merchant web server 112.
  • the merchant's 112 web site may, for example, display a catalog of software available for purchase, allow the customer 110 to view flight schedules and purchase a plane ticket, or allow the customer 110 to play an online game, download a book or music, or access a database of information.
  • the terms "customer" and “merchant” depend upon the specific transaction being conducted. In a chain of commerce transactions, the "customer" in a first transaction may be a "merchant" in a second transaction.
  • the customer 110 may buy components of a product from several different vendors or merchants 112 using the electronic commerce system described herein and then, in turn, sell the combined product via the customer's own web site and the CS 114.
  • the merchant's web site displays at least one "payment button.”
  • a payment button is a graphic button, a region of a larger graphic, a text string, or another form of URL link which the customer 110 may "press” by selecting it with a mouse, physical button, or other input device.
  • the payment button may be utilized on a non-Internet-based electronic commerce system.
  • the payment button is considered to be "pressed” whenever a customer 110 expresses a desire to purchase an item.
  • the payment button is pressed by the customer 110 when the customer 110 wishes to purchase and pay for an item displayed for sale on the merchant's web site.
  • every type of item for sale on the merchant's web site has a separate payment button.
  • the 110 customer presses the product's associated payment button. Then, the customer 110 is preferably presented with a menu allowing the customer 110 to specify attributes, such as quantity or duration, of the items that the customer 110 wishes to purchase.
  • the merchant web site has only one payment button or has only one payment button for each class of items for sale.
  • the customer 110 is preferably presented with a menu of choices after pressing the payment button. For example, the menu of choices may ask the customer 110 to identify a specific product or an attribute of a product, like color, that the customer 110 wishes to purchase. Every payment button has an associated URL that points to information in the CS 114.
  • a database key that uniquely identifies the merchant 112 and/or item for sale is encoded within the URL.
  • the customer 110 presses the payment button, the customer 110 is redirected to a web page provided by the CS 114 and specific to the merchant 112 and/or item.
  • the CS 114 queries the customer for the quantity or duration of the item that the customer 110 wishes to purchase and payment information.
  • the CS 114 receives the customer's responses and conducts the electronic commerce transaction according to payment processing rules and delivery options specified by the merchant 112.
  • the CS 114 records the transaction in its database and notifies the customer and merchant whether the transaction was successful. Accordingly, the merchant 112 is relieved of the responsibility of conducting the electronic commerce transaction with the customer 110.
  • FIG. 2 is a high-level block diagram illustrating functional components of the CS 114 and also illustrating a remote payment system 222 and a remote merchant 223 according to a preferred embodiment of the present invention.
  • the CS 114 is preferably similar to the customer 110 and merchant 112 computers, except that the CS 114 has enough processing power and Internet 116 bandwidth to support many simultaneous payment button transactions as described herein.
  • the functionality of the CS 114 described herein may be performed by hardware or software modules within the CS 114.
  • the functionality of the CS 114 is provided by software applications executing on INTEL x86- or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1.
  • the functionality of the CS 114 is provided by a distributed computing system as described below.
  • the remote payment system 222 is preferably a third-party payment gateway or system.
  • the gateway or system is preferably connected to a financial transaction network, which, in turn, typically links to computers at banks and other financial institutions for approval and settlement of electronic commerce transactions.
  • Typical gateways or systems may include CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is illustrated in FIG. 2, the CS 114 may be in communication with many different remote payment systems 222, either through a secure link on the Internet 116 or a dedicated secure link. Each payment system has an applications programming interface ("API"). By using the API, the CS 114 communicates with the payment system 222 and performs secure and verifiable payment transactions.
  • API applications programming interface
  • the remote merchant 223 is preferably a merchant selling items via a web site as described above.
  • the remote merchant 223 may have an account on the CS 114 or the merchant 223 may have an interface for selling items similar to the remote payment system 222.
  • the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 110 electronic commerce transaction performed by the CS 114 may contact a remote payment system 222 and/or a remote merchant 223.
  • the CS 114 includes a payment button transaction engine 210 which is coupled to a database 212 and a web server 214.
  • a firewall 216 preferably sits between the web server 216 and the transaction engine 210. While these functional components are illustrated in FIG. 2 as discrete entities, the CS 114 may be executed on a distributed computer system having a plurality of engines, databases, and web servers working together the perform the functions described herein. For example, one embodiment of the CS 114 uses multiple transaction engines 210 and web servers 214 and a single distributed database 212, thereby providing scalability to the CS 114.
  • the number of web servers 214 and transaction engines 210 depends on the actual system load and the desire to achieve better performance through balancing the transaction load across the system.
  • the payment button transaction engine 210 includes a rules module 218 that controls the interactions and flows of information necessary to complete a payment transaction.
  • the transaction engine 210 preferably includes a Payment Application Programming Interface ("PAPI") module 220 enabling communication between the CS 114 and the remote payment systems 222 and merchants 223.
  • PAPI Payment Application Programming Interface
  • the PAPI module 220 abstracts the different APIs of each payment system 222 and merchant 223 into a single, higher level, PAPI that can interface with each of the payment systems 222 and merchants 223.
  • the transaction engine 210 performs payment transactions with a payment system 222 or merchant 223 by making calls to the PAPI.
  • the PAPI abstraction module 220 translates these calls into the specific API of the payment system 222 or merchant 223 being used for that transaction.
  • the PAPI abstraction module 220 also translates data received from the payment system 222 or merchant 223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction module 220 allows support for new payment systems 222 and merchants 223 to be added to the CS 114 by merely creating a new PAPI to payment system or merchant API mapping in the PAPI abstraction module 220.
  • the payment button store module (“PB store”) 224 in combination with the web server 214, allows a merchant 112 to obtain a payment button.
  • the web server 214 is preferably an industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the
  • the web server 214 provides secure communication with the customer 110 and preferably uses industry standard technologies including HyperText Markup Language (“HTML”), and HTTP to deliver information to the customer 110.
  • HTTP HyperText Markup Language
  • the web server preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP”) and the secure sockets layer (“SSL”), to ensure that communications with the customer 110 are private.
  • S-HTTP secure HTTP
  • SSL secure sockets layer
  • the firewall 216 allows only authorized communications between the web server 214 and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the transaction engine 210.
  • the PB store 224 allows the merchant to purchase payment buttons and add product descriptions, merchant configurations, and other information to the database 212.
  • the merchant 112 accesses the PB store through a web site on the web server 214.
  • the PB store module 224 captures the merchant 112 actions on the web server 214 and creates the appropriate entries in the database 212.
  • the PB store web site describes the payment button mechanism, the services offered by the payment button vendor, and the costs of the services.
  • the web site preferably has a merchant registration form 226 for registering new merchants, a merchant renewal form 228 for renewing merchant registrations, and a payment button generation form 230 for issuing payment buttons to registered merchants.
  • the forms preferably include CGI programs for performing the functionality described herein.
  • the merchant registration form 226 allows the merchant 112 to input information identifying the merchant 112 and includes a payment button with which the merchant 112 can pay a registration fee. After the fee payment is verified, the merchant 112 is preferably issued a login password pair and an account with the CS 114 through which the merchant 112 can access the payment button generation form and maintain the merchant's account. Similarly, the merchant renewal form 228 preferably includes a payment button with which the merchant 112 can pay a renewal fee.
  • the payment button generation form 230 allows the merchant 112 to enter item description data, such as item names and descriptions, prices, types, and delivery options, and payment processing rules, such as supported credit cards, payment systems, and currencies.
  • the payment processing rules may rank the payment systems in order of preference, describe when payment is required (e.g., the merchant may require billing after 90 days), and/or describe the quantity or duration of an item available for a certain price.
  • the merchant 112 enters the item description data and payment processing rules by uploading a file to web site having the information in a standardized format.
  • the payment button generation form 230 sends the data to the transaction engine 210, which stores the information in the database 212 at a location specified by a key.
  • the transaction engine 210 passes the key back to the PB store web site, which provides the merchant with a payment button download page displaying the results of the payment button generation transaction. If the transaction was successful, the payment button download page includes the payment button issued to the merchant 112.
  • the payment button has an associated URL that specifies the key. Accordingly, little or no engineering effort is required to maintain each merchant configuration on the CS 114.
  • PB store web sites communicating with the database 212 through the transaction engine 210.
  • the transaction engine 210 creates a field in the database 212 entry specifying the PB store that generated the payment button. Accordingly, payment buttons may be "branded" among different payment button vendors.
  • the database 212 is preferably a robust relational database.
  • a preferred embodiment of the present invention uses the ORACLE 7 database to implement the functionality described herein.
  • the database 212 stores item descriptions, payment processing rules, and other information necessary to complete a payment transaction on behalf of a merchant 112. This merchant information is preferably accessed in the database by using a key assigned to each merchant 112 and/or item for sale.
  • the database 212 is also used as a repository of transaction information including authorization logs, payment status and completion records, and other information required by the merchant 112 and the CS 114.
  • FIG. 3 is a high-level block diagram of functional components within the database 212. Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one of three types of item entries 312, 314, 316.
  • the primary entry 310 is the entry identified by the key provided to the merchant 112. Accordingly, the primary entry 310 is typically accessed either when the merchant 112 provides the key while using the PB store web site or when the customer 110 uses the URL provided by a payment button to purchase the item identified in the database entry 310.
  • the primary entry 310 contains a field 318 storing the payment processing rules for the item as specified by the merchant 112 through the PB store.
  • the primary entry 310 also contains a field 320 holding item type information as specified by the merchant 112.
  • the item type information preferably describes the item attributes input by the merchant 112.
  • the item type information field 320 preferably contains at least one link to another database entry 312, 314, 316 describing delivery options for the item.
  • FIG. 3 illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and online items.
  • a hard item is typically a manufactured physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 holding delivery options 322 may list various shipping methods and companies available for delivering the hard item to the customer 110.
  • a soft item in contrast, is typically intangible intellectual property such as music, electronic books, or software.
  • the soft item may be a streaming music file that can be played by the customer 110.
  • the entry 314 holding delivery options 324 may list a URL or electronic key that can be provided to the customer to effectuate the purchase.
  • the options 324 may provide instructions for initiating an FTP session to download the purchased soft item to the customer's 110 computer system.
  • An online item is typically access to an online service or other software executing remotely from the customer 110.
  • the online item may be access to an electronic database of information or an online game.
  • the entry 316 holding delivery options 326 preferably includes instructions for allowing the customer 110 to access the online item.
  • the options 326 may provide instructions for initiating a telnet session with an electronic database for a limited duration of time.
  • FIG. 4 is a flow diagram illustrating the interactions between the customer 110, merchant 112. CS 114, database 212 and a payment system 222 when completing a payment transaction according to a preferred embodiment of the present invention.
  • time flows from the top of the diagram to the bottom and horizontal lines represent communications between the various entities.
  • FIG. 4 illustrates only major interactions between the entities and does not represent every interaction.
  • FIG. 4 illustrates a simple case of the present invention wherein the merchant's 112 payment processing rules specify that the payment transaction should be processed at the time the customer's 110 order is received.
  • the customer 110 is browsing the merchant's web site and decides to purchase an item by pressing 410 the associated payment button.
  • the merchant's web server 112 redirects 412 the customer's browser to the location on the CS 114 specified by the URL associated with the payment button.
  • the customer's browser fetches 414 the referenced page from the CS 114.
  • the CS 114 parses the URL received from the customer 110 for the database 212 key corresponding to the item that the customer 110 wishes to purchase. Using this key, the CS 114 accesses 416 the database 212 and dynamically generates a web page indicating the attributes and payment options available for the item as defined by the merchant 112. In addition, the CS 114 preferably determines the language utilized by the customer 110 and currencies supported by the merchant 112 and modifies the web page accordingly. This generated web page is sent 418 to the customer 110.
  • FIG. 5 illustrates an exemplary screen display 500 of the web page seeking payment information from the customer 110.
  • the customer selects the desired item attributes and payment service, enters any necessary payment information, such as a credit card or account number, and transmits 420 these data to the CS 114.
  • the CS 114 stores 422 the received data in the database 212 and contacts the selected payment system 222.
  • the CS 114 preferably uses the PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API of the selected payment system 222.
  • the CS 114 preferably stores 426 records of all communications with the payment system 222, customer 110, and merchant 112 in the database 212. Therefore, the database 212 can be used to reconstruct transaction histories in order to provide error tracking and accounting services. If the payment system 222 rejects the transaction, the CS 114 publishes a web page to the customer indicating this result and presenting alternative payment methods, if any (this interaction is not shown in FIG. 4).
  • the CS dynamically generates a web page containing payment status information and publishes 428 this information to the customer 110.
  • This page preferably contains a receipt or confirmation number generated by the CS 114.
  • the confirmation number is a unique number encoding transaction, session, and merchant identifications and a time and date stamp.
  • This confirmation number is preferably a key to a database entry holding the transaction information and can be used later by the merchant 112 and customer 110 to confirm payment, to query the CS 114 for payment status information, and to use the CS 114 to query the payment system for account status information.
  • the web page also preferably contains any other information required by the merchant 112 and a link to a confirmation page on the merchant's web site 112.
  • FIG. 6 illustrates an exemplary screen display 600 of an order confirmation web page.
  • the CS 114 also notifies 428 the merchant 112 that payment was accepted and provides the same receipt or confirmation number as was provided to the customer 110. In one embodiment, this notification is performed via a secure electronic mail message. Accordingly, both the customer 110 and merchant 112 are notified that the purchase was made.
  • the customer 110 fetches 430 the confirmation web page on the merchant's web site.
  • this web page provides the customer 110 with additional information about the purchase or any other information which the merchant 112 desires to provide.
  • the present invention is a system, method, and computer program instructions for conducting electronic commerce transactions via the Internet or any electronic communication system.
  • the merchant 112 opens an account on the CS 114 and supplies information about items sold by the merchant 112.
  • the CS 114 stores this information in a database 212 entry and issues the merchant 112 a URL containing the key to database entry.
  • the merchant 112 supplies this URL to customers wishing to purchase an item, causing a customer 110 to be connected to the CS 114.
  • the CS 114 collects payment information from the customer 110, conducts the electronic commerce transaction with a remote payment system 222, and notifies the customer 110 and merchant 112 of the result.

Abstract

A system and method for conducting electronic payment transactions accepts and stores information describing an item sold by a merchant on a commerce server. The merchant also defines payment processing rules that define the payment methods accepted by the merchant. The merchant, in turn, is provided with a reference identifying the commerce server and the item. The merchant preferably publishes this reference at the merchant's web site on a web page offering the item for sale. A customer viewing the merchant's web site indicates a desire to purchase the item by selecting the reference. As a result, the customer is put in contact with the commerce server and is provided with information from the commerce server about the item and is given a list of payment options. The customer preferably selects a payment option and provides the commerce server with payment information, such as a credit card number. In response, the commerce server contacts a selected payment system and completes the electronic commerce transaction. The commerce server then notifies the customer and the merchant of the results of the electronic commerce transaction and delivers the item to the customer.

Description

METHOD AND SYSTEM FOR CONDUCTING ELECTRONIC COMMERCE TRANSACTIONS
CROSS-REFERENCE TO RELATED APPLICATION This application is a continuation-in-part of U.S. Provisional Application No.
60/054,121, filed July 29, 1997.
BACKGROUND FIELD OF THE INVENTION
This invention pertains in general to electronic commerce and in particular to a method and system for conducting electronic payment transactions via the Internet.
BACKGROUND OF THE INVENTION
Electronic commerce conducted over the Internet has become increasingly important over the last decade. Online merchants offer goods and services for sale or rent including physical objects such as compact disks, books, and clothing, and intellectual property such as streaming music and movies and electronic books. Physical items may be delivered to the customer via the mail or a variety of other shipping options. Intellectual property, in contrast, may be delivered to the customer by allowing a download via the file transfer protocol ("FTP"), providing the customer with an access key, establishing a telnet session, or through some other form of electronic delivery.
Typically, these goods and services are displayed on the merchant's web site and a prospective customer views, selects, and purchases the goods using web browsing software such as NETSCAPE NAVIGATOR®. The customer usually pays for a product by establishing a secure connection with the merchant's web server and transmitting payment information, such as a credit card number, to the merchant. The merchant then uses back-end processing to verify the payment information and receive payment. For example, the merchant may use a secure telephone line or network link to contact the credit card issuer before accepting the customer's order. Eventually, the merchant and credit card issuer settle payment and the merchant delivers the product or service to the customer. A difficulty with the above-described scenario is that each merchant must implement an inventory and payment database and a payment acceptance and verification system. For example, the merchant must establish and maintain a database tracking sales, delivery, and payment information and product inventories in order to support the electronic commerce system. There is significant cost and complexity in maintaining this database, including the difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by the scarcity of truly skilled personnel. In addition, the merchant must design web pages to securely accept the order and payment information and implement the functionality to verify the payment. These tasks can be extremely difficult if the merchant accepts payment using many different methods, such as credit cards and electronic fund transfers, or accepts payment in more than one currency. Moreover, having a large number of separate payment acceptance systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of each system can be exploited.
Although Internet-based electronic commerce clearinghouses have been developed to handle transactions from many different parties, these clearinghouses do not provide a convenient interface to the merchant. In addition, the merchant must still establish the payment, verification, and database systems described above.
Accordingly, there is a need in the art for a method and system for conducting electronic commerce on the Internet which reduces the amount of work that must be performed by the online merchant. Preferably, the method and system will allow the merchant to easily and verifiably perform inventory, sales, and delivery tracking and transparently support different types of payments and currencies.
SUMMARY OF THE INVENTION
The above needs are met by a method and system for conducting electronic commerce transactions that allows a merchant to easily sell a mix of physical and intangible items and supports sales, inventory, and delivery tracking and a variety of payment systems by having the merchant establish an account on a commerce server. The commerce server provides the merchant with inventory, accounting, and order management systems. Furthermore, the commerce server allows merchants to conduct electronic commerce with other merchants and vendors.
The commerce server includes a web server providing web pages to the merchant. By using these web pages, the merchant establishes an account on the commerce server. Then, the merchant provides the commerce server with information about an item sold by the merchant, such as a plane ticket, clothing, a book, a software product, or playing time with an online game. The merchant also provides the commerce server with other attributes of the item from which the customer may select, for example, the quantity or duration of an item. In addition, the merchant supplies payment processing rules defining the payment options that are acceptable to the merchant, such as which currencies and payment systems are allowed and when or how often to bill the customer. The commerce server preferably stores the information received from the merchant in an entry of a database. In one embodiment, the database entry categorizes the item as a hard good, soft good, or online good depending upon the delivery options available for the item. The commerce server, in addition, provides the merchant with a "payment button" including a universal resource locator ("URL") that points to the commerce server and includes information allowing the commerce server to identify the database entry with which the payment button is associated. The merchant preferably publishes the payment button on the merchant's web site.
The customer selects the payment button when the customer wishes to purchase the associated product. In response, the customer's computer is automatically directed to the web server managed by the commerce server and provided with the item information entered by the merchant. In addition, the customer is presented with the payment options allowed by the merchant's payment processing rules. Preferably, the customer then provides the web server with the payment information necessary to complete the transaction. When the merchant's payment terms specify that payment is required, the commerce server preferably identifies the remote payment system selected by the customer and contacts it to complete the electronic commerce transaction. Preferably, a module within the commerce server converts calls generated by the commerce server into the format used by the selected payment system. Likewise, the module converts responses received from the payment system into the format used by the commerce server. Then, the commerce server notifies the customer and the merchant of the result of the electronic commerce transaction and, if appropriate, delivers the item using one of the delivery options specified in the database.
A method of conducting electronic commerce between a remote customer and a remote merchant in accordance with the present invention includes receiving information identifying an item to be purchased by the customer, receiving payment information specifying a payment method to be used by the customer to purchase the item, conducting a payment transaction with a remote payment system specified by the payment information, and providing the customer and the merchant with the result of the payment transaction.
Similarly, computer program instructions for conducting electronic commerce transactions in accordance with the present invention include instructions for storing item information received from the merchant, instructions for issuing the merchant a reference to the stored item information, instructions for receiving an electronic commerce transaction identifier from the customer containing the reference to the stored item information issued to the merchant, instructions for accepting payment information from the customer, and instructions for conducting the electronic commerce transaction with a remote payment system.
BRIEF DESCRIPTION OF THE DRAWINGS FIGURE 1 is a high-level block diagram of an electronic commerce system according to an embodiment of the present invention;
FIGURE 2 is a high-level block diagram illustrating functional components of a commerce server according to an embodiment of the present invention;
FIGURE 3 is a high-level block diagram of an entry in a database associated with the commerce server according to an embodiment of the present invention;
FIGURE 4 is a flow diagram illustrating the interactions between the customer, merchant, commerce server, and payment system when completing a payment transaction according to an embodiment of the present invention; and
FIGURE 5 illustrates an exemplary screen display of a web page seeking payment information from a customer; and
FIGURE 6 illustrates an exemplary screen display of an order confirmation web page.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
As used herein, the "Internet" refers to the global network of interconnected computer systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a piece of information or a software function on a computer connected to the Internet. A "web server" is a program that accepts requests for information framed according to the HyperText Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in response to the requests. The Common Gateway Interface ("CGI") is the standard that describes how the web server accesses external programs, usually called "CGI programs" or "CGI scripts," called by a web page. Of course, the present invention is not limited to the Internet and may be used with any digital network supporting electronic commerce. In a non- Internet-based system, the terms defined above also include the non-Internet-based equivalents for communicating between the various entities described herein.
FIG. 1 is a high-level block diagram of an electronic commerce system 100 according to an embodiment of the present invention. Illustrated are a customer computer (sometimes referred to as "the customer") 110, a merchant web server (sometimes referred to as "the merchant") 112, and a commerce server ("CS") 114, all coupled to the Internet 116. In a typical embodiment, the customer computer 110 is a personal computer having, among other things, a processor, memory, storage device, and monitor. The customer computer 110 is coupled to the Internet 116 via a network connection 118. The network connection may be, for example, a modem coupled to an analog telephone line, a digital subscriber line, a cable modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any other communications medium. Web browsing software, such as NETSCAPE NAVIGATOR®, preferably executes on the client computer and sends data from the client computer 110 to the merchant web server 112 via the network connection 118 and Internet 116. In another embodiment, the customer computer 110 is a palm-top device or personal digital system communicating via radio waves with the Internet 116 or another electronic commerce system.
The merchant web server 112 is preferably similar to the customer computer 110 except that it is has the processing power and communications 116 bandwidth to handle multiple simultaneous customer transactions. The merchant 112 sells items, such as merchandise, information, intellectual property, and/or services via a web site hosted on the merchant web server 112. The merchant's 112 web site may, for example, display a catalog of software available for purchase, allow the customer 110 to view flight schedules and purchase a plane ticket, or allow the customer 110 to play an online game, download a book or music, or access a database of information. As used herein, the terms "customer" and "merchant" depend upon the specific transaction being conducted. In a chain of commerce transactions, the "customer" in a first transaction may be a "merchant" in a second transaction. For example, the customer 110 may buy components of a product from several different vendors or merchants 112 using the electronic commerce system described herein and then, in turn, sell the combined product via the customer's own web site and the CS 114.
The merchant's web site displays at least one "payment button." A payment button is a graphic button, a region of a larger graphic, a text string, or another form of URL link which the customer 110 may "press" by selecting it with a mouse, physical button, or other input device. In another embodiment, the payment button may be utilized on a non-Internet-based electronic commerce system. In such an embodiment, the payment button is considered to be "pressed" whenever a customer 110 expresses a desire to purchase an item. As described below, the payment button is pressed by the customer 110 when the customer 110 wishes to purchase and pay for an item displayed for sale on the merchant's web site. In a preferred embodiment, every type of item for sale on the merchant's web site has a separate payment button. When a customer 110 wishes to purchase the product, the 110 customer presses the product's associated payment button. Then, the customer 110 is preferably presented with a menu allowing the customer 110 to specify attributes, such as quantity or duration, of the items that the customer 110 wishes to purchase. In another embodiment, the merchant web site has only one payment button or has only one payment button for each class of items for sale. In this embodiment, the customer 110 is preferably presented with a menu of choices after pressing the payment button. For example, the menu of choices may ask the customer 110 to identify a specific product or an attribute of a product, like color, that the customer 110 wishes to purchase. Every payment button has an associated URL that points to information in the CS 114.
Preferably, a database key that uniquely identifies the merchant 112 and/or item for sale is encoded within the URL. When the customer 110 presses the payment button, the customer 110 is redirected to a web page provided by the CS 114 and specific to the merchant 112 and/or item. In one embodiment, the CS 114 queries the customer for the quantity or duration of the item that the customer 110 wishes to purchase and payment information. The CS 114 receives the customer's responses and conducts the electronic commerce transaction according to payment processing rules and delivery options specified by the merchant 112. The CS 114 records the transaction in its database and notifies the customer and merchant whether the transaction was successful. Accordingly, the merchant 112 is relieved of the responsibility of conducting the electronic commerce transaction with the customer 110.
FIG. 2 is a high-level block diagram illustrating functional components of the CS 114 and also illustrating a remote payment system 222 and a remote merchant 223 according to a preferred embodiment of the present invention. The CS 114 is preferably similar to the customer 110 and merchant 112 computers, except that the CS 114 has enough processing power and Internet 116 bandwidth to support many simultaneous payment button transactions as described herein. The functionality of the CS 114 described herein may be performed by hardware or software modules within the CS 114. In one embodiment of the present invention, the functionality of the CS 114 is provided by software applications executing on INTEL x86- or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1. In another embodiment of the present invention, the functionality of the CS 114 is provided by a distributed computing system as described below. The remote payment system 222 is preferably a third-party payment gateway or system. The gateway or system is preferably connected to a financial transaction network, which, in turn, typically links to computers at banks and other financial institutions for approval and settlement of electronic commerce transactions. Typical gateways or systems may include CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is illustrated in FIG. 2, the CS 114 may be in communication with many different remote payment systems 222, either through a secure link on the Internet 116 or a dedicated secure link. Each payment system has an applications programming interface ("API"). By using the API, the CS 114 communicates with the payment system 222 and performs secure and verifiable payment transactions.
The remote merchant 223 is preferably a merchant selling items via a web site as described above. The remote merchant 223 may have an account on the CS 114 or the merchant 223 may have an interface for selling items similar to the remote payment system 222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 110 electronic commerce transaction performed by the CS 114 may contact a remote payment system 222 and/or a remote merchant 223.
The CS 114 includes a payment button transaction engine 210 which is coupled to a database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 and the transaction engine 210. While these functional components are illustrated in FIG. 2 as discrete entities, the CS 114 may be executed on a distributed computer system having a plurality of engines, databases, and web servers working together the perform the functions described herein. For example, one embodiment of the CS 114 uses multiple transaction engines 210 and web servers 214 and a single distributed database 212, thereby providing scalability to the CS 114. The number of web servers 214 and transaction engines 210 depends on the actual system load and the desire to achieve better performance through balancing the transaction load across the system.
The payment button transaction engine 210 includes a rules module 218 that controls the interactions and flows of information necessary to complete a payment transaction. In addition, the transaction engine 210 preferably includes a Payment Application Programming Interface ("PAPI") module 220 enabling communication between the CS 114 and the remote payment systems 222 and merchants 223. The PAPI module 220 abstracts the different APIs of each payment system 222 and merchant 223 into a single, higher level, PAPI that can interface with each of the payment systems 222 and merchants 223. The transaction engine 210 performs payment transactions with a payment system 222 or merchant 223 by making calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API of the payment system 222 or merchant 223 being used for that transaction. The PAPI abstraction module 220 also translates data received from the payment system 222 or merchant 223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction module 220 allows support for new payment systems 222 and merchants 223 to be added to the CS 114 by merely creating a new PAPI to payment system or merchant API mapping in the PAPI abstraction module 220.
The payment button store module ("PB store") 224, in combination with the web server 214, allows a merchant 112 to obtain a payment button. The web server 214 is preferably an industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the
APACHE web server. The web server 214 provides secure communication with the customer 110 and preferably uses industry standard technologies including HyperText Markup Language ("HTML"), and HTTP to deliver information to the customer 110. In addition, the web server preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") and the secure sockets layer ("SSL"), to ensure that communications with the customer 110 are private. The firewall 216 allows only authorized communications between the web server 214 and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the transaction engine 210.
The PB store 224 allows the merchant to purchase payment buttons and add product descriptions, merchant configurations, and other information to the database 212. In a preferred embodiment of the present invention, the merchant 112 accesses the PB store through a web site on the web server 214. The PB store module 224 captures the merchant 112 actions on the web server 214 and creates the appropriate entries in the database 212.
In one embodiment of the present invention, the PB store web site describes the payment button mechanism, the services offered by the payment button vendor, and the costs of the services. In addition, the web site preferably has a merchant registration form 226 for registering new merchants, a merchant renewal form 228 for renewing merchant registrations, and a payment button generation form 230 for issuing payment buttons to registered merchants. The forms preferably include CGI programs for performing the functionality described herein.
The merchant registration form 226 allows the merchant 112 to input information identifying the merchant 112 and includes a payment button with which the merchant 112 can pay a registration fee. After the fee payment is verified, the merchant 112 is preferably issued a login password pair and an account with the CS 114 through which the merchant 112 can access the payment button generation form and maintain the merchant's account. Similarly, the merchant renewal form 228 preferably includes a payment button with which the merchant 112 can pay a renewal fee.
The payment button generation form 230 allows the merchant 112 to enter item description data, such as item names and descriptions, prices, types, and delivery options, and payment processing rules, such as supported credit cards, payment systems, and currencies. In addition, the payment processing rules may rank the payment systems in order of preference, describe when payment is required (e.g., the merchant may require billing after 90 days), and/or describe the quantity or duration of an item available for a certain price. In one embodiment of the present invention, the merchant 112 enters the item description data and payment processing rules by uploading a file to web site having the information in a standardized format.
When entry of this data is completed, the payment button generation form 230 sends the data to the transaction engine 210, which stores the information in the database 212 at a location specified by a key. The transaction engine 210 passes the key back to the PB store web site, which provides the merchant with a payment button download page displaying the results of the payment button generation transaction. If the transaction was successful, the payment button download page includes the payment button issued to the merchant 112. The payment button has an associated URL that specifies the key. Accordingly, little or no engineering effort is required to maintain each merchant configuration on the CS 114.
In one embodiment of the present invention, there are multiple PB store web sites communicating with the database 212 through the transaction engine 210. When a payment button is created, the transaction engine 210 creates a field in the database 212 entry specifying the PB store that generated the payment button. Accordingly, payment buttons may be "branded" among different payment button vendors.
The database 212 is preferably a robust relational database. A preferred embodiment of the present invention uses the ORACLE 7 database to implement the functionality described herein. The database 212 stores item descriptions, payment processing rules, and other information necessary to complete a payment transaction on behalf of a merchant 112. This merchant information is preferably accessed in the database by using a key assigned to each merchant 112 and/or item for sale. The database 212 is also used as a repository of transaction information including authorization logs, payment status and completion records, and other information required by the merchant 112 and the CS 114. FIG. 3 is a high-level block diagram of functional components within the database 212. Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by the key provided to the merchant 112. Accordingly, the primary entry 310 is typically accessed either when the merchant 112 provides the key while using the PB store web site or when the customer 110 uses the URL provided by a payment button to purchase the item identified in the database entry 310.
The primary entry 310 contains a field 318 storing the payment processing rules for the item as specified by the merchant 112 through the PB store. The primary entry 310 also contains a field 320 holding item type information as specified by the merchant 112. The item type information preferably describes the item attributes input by the merchant 112. In addition, the item type information field 320 preferably contains at least one link to another database entry 312, 314, 316 describing delivery options for the item.
The available delivery options for an item depend upon the type of item. FIG. 3 illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and online items. However, an embodiment of the present invention may have many different types of items and corresponding delivery options. A hard item is typically a manufactured physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 holding delivery options 322 may list various shipping methods and companies available for delivering the hard item to the customer 110.
A soft item, in contrast, is typically intangible intellectual property such as music, electronic books, or software. For example, the soft item may be a streaming music file that can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 may list a URL or electronic key that can be provided to the customer to effectuate the purchase. For example, the options 324 may provide instructions for initiating an FTP session to download the purchased soft item to the customer's 110 computer system.
An online item is typically access to an online service or other software executing remotely from the customer 110. For example, the online item may be access to an electronic database of information or an online game. Accordingly, the entry 316 holding delivery options 326 preferably includes instructions for allowing the customer 110 to access the online item. For example, the options 326 may provide instructions for initiating a telnet session with an electronic database for a limited duration of time.
FIG. 4 is a flow diagram illustrating the interactions between the customer 110, merchant 112. CS 114, database 212 and a payment system 222 when completing a payment transaction according to a preferred embodiment of the present invention. In the flow diagram, time flows from the top of the diagram to the bottom and horizontal lines represent communications between the various entities. FIG. 4 illustrates only major interactions between the entities and does not represent every interaction. In addition, FIG. 4 illustrates a simple case of the present invention wherein the merchant's 112 payment processing rules specify that the payment transaction should be processed at the time the customer's 110 order is received.
Initially, the customer 110 is browsing the merchant's web site and decides to purchase an item by pressing 410 the associated payment button. In response to the press, the merchant's web server 112 redirects 412 the customer's browser to the location on the CS 114 specified by the URL associated with the payment button. The customer's browser fetches 414 the referenced page from the CS 114.
The CS 114 parses the URL received from the customer 110 for the database 212 key corresponding to the item that the customer 110 wishes to purchase. Using this key, the CS 114 accesses 416 the database 212 and dynamically generates a web page indicating the attributes and payment options available for the item as defined by the merchant 112. In addition, the CS 114 preferably determines the language utilized by the customer 110 and currencies supported by the merchant 112 and modifies the web page accordingly. This generated web page is sent 418 to the customer 110. FIG. 5 illustrates an exemplary screen display 500 of the web page seeking payment information from the customer 110.
The customer selects the desired item attributes and payment service, enters any necessary payment information, such as a credit card or account number, and transmits 420 these data to the CS 114. The CS 114 stores 422 the received data in the database 212 and contacts the selected payment system 222. As described above, the CS 114 preferably uses the PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API of the selected payment system 222. The CS 114 preferably stores 426 records of all communications with the payment system 222, customer 110, and merchant 112 in the database 212. Therefore, the database 212 can be used to reconstruct transaction histories in order to provide error tracking and accounting services. If the payment system 222 rejects the transaction, the CS 114 publishes a web page to the customer indicating this result and presenting alternative payment methods, if any (this interaction is not shown in FIG. 4).
If the payment system 222 approves the transaction, the CS dynamically generates a web page containing payment status information and publishes 428 this information to the customer 110. This page preferably contains a receipt or confirmation number generated by the CS 114. In a preferred embodiment of the present invention, the confirmation number is a unique number encoding transaction, session, and merchant identifications and a time and date stamp. This confirmation number is preferably a key to a database entry holding the transaction information and can be used later by the merchant 112 and customer 110 to confirm payment, to query the CS 114 for payment status information, and to use the CS 114 to query the payment system for account status information. The web page also preferably contains any other information required by the merchant 112 and a link to a confirmation page on the merchant's web site 112. FIG. 6 illustrates an exemplary screen display 600 of an order confirmation web page. The CS 114 also notifies 428 the merchant 112 that payment was accepted and provides the same receipt or confirmation number as was provided to the customer 110. In one embodiment, this notification is performed via a secure electronic mail message. Accordingly, both the customer 110 and merchant 112 are notified that the purchase was made.
Finally, the customer 110 fetches 430 the confirmation web page on the merchant's web site. Preferably, this web page provides the customer 110 with additional information about the purchase or any other information which the merchant 112 desires to provide.
In summary, the present invention is a system, method, and computer program instructions for conducting electronic commerce transactions via the Internet or any electronic communication system. The merchant 112 opens an account on the CS 114 and supplies information about items sold by the merchant 112. The CS 114 stores this information in a database 212 entry and issues the merchant 112 a URL containing the key to database entry. The merchant 112 supplies this URL to customers wishing to purchase an item, causing a customer 110 to be connected to the CS 114. The CS 114 collects payment information from the customer 110, conducts the electronic commerce transaction with a remote payment system 222, and notifies the customer 110 and merchant 112 of the result.

Claims

CLAIMSI claim:
1. A computer system for supporting electronic commerce transactions between a customer and a remote merchant, the computer system comprising: a database having an entry including merchant information identifying an item offered for sale by the remote merchant; and a transaction engine in communication with the database and a remote payment system for performing an electronic commerce transaction, the transaction engine comprising: a first module for receiving an electronic commerce transaction identifier from the customer, the electronic commerce transaction identifier specifying the entry in the database; a second module for accepting payment information from the customer, the payment information identifying the remote payment system; and a third module for performing the electronic commerce transaction with the remote payment system using the payment information received from the customer.
2. The computer system of claim 1, wherein the transaction engine further comprises: a fourth module for notifying the remote merchant and the customer of a result of the electronic commerce transaction.
3. The computer system of claim 1, further comprising: a web server in communication with the transaction engine for communicating with the remote merchant and customer; and a firewall between the web server and the transaction engine for securing communications between the web server and the transaction engine.
4. The computer system of claim 3, wherein the transaction engine further comprises: a fifth module for dynamically generating a web page from the entry in the database and providing the web page to the customer via the web server, the web page providing information about the item offered for sale by the remote merchant and facilitating collection of the payment information from the customer.
5. The computer system of claim 3, wherein the computer system further comprises: a sixth module for accepting the merchant information identifying the item offered for sale by the remote merchant via the web server, creating the database entry for holding the merchant information, and providing the remote merchant with a reference to the database entry.
6. The computer system of claim 1, wherein the electronic commerce transaction identifier is a URL identifying the computer system and including a key to the entry in the database.
7. The computer system of claim 1 , wherein the database further comprises: an entry specifying payment processing rules defined by the remote merchant; and an entry specifying delivery options for the item offered for sale by the remote merchant.
8. The computer system of claim 1 , wherein there are a plurality of available remote payment systems and wherein the second module for accepting payment information from the customer accepts payment information identifying one of the available remote payment systems.
9. The computer system of claim 1 , wherein the transaction engine is executed by a plurality of distributed computer systems.
10. A method of conducting electronic commerce between a remote customer and a remote merchant, the method comprising the steps of: receiving information identifying an item to be purchased by the remote customer; receiving payment information specifying a payment method to be used by the remote customer to purchase the item; conducting a payment transaction with a remote payment system specified by the payment information; and providing the remote customer and the remote merchant with a result of the payment transaction.
11. The method of claim 10, further comprising the steps of: receiving information about the item to be purchased from the remote merchant; storing the information about the item to be purchased at a specified location; and providing the remote merchant with a reference to the specified location.
12. The method of claim 11, wherein the remote merchant provides the reference to the specified location to the remote customer responsive to the remote customer desiring to purchase the item.
13. The method of claim 10, further comprising the step of: providing the remote customer with a list of item attributes from which the customer can select.
14. The method of claim 10, wherein the step of receiving information identifying the item to be purchased by the remote customer comprises the steps of: receiving payment processing rules specifying payment options available for purchasing the item; and receiving delivery options for the item.
15. A computer-readable medium having computer instructions encoded thereon for conducting electronic commerce transactions between a remote merchant and a remote customer, the computer instructions comprising: instructions for storing item information received from the remote merchant; instructions for issuing the remote merchant a reference to the stored item information; instructions for receiving an electronic commerce transaction identifier from the remote customer containing the reference to the stored item information issued to the remote merchant; instructions for accepting payment information from the remote customer, the payment information identifying a remote payment system; and instructions for conducting the electronic commerce transaction with the remote payment system using the payment information received from the remote customer.
16. The computer-readable medium of claim 15, wherein the instructions further comprise: instructions for notifying the remote merchant and the remote customer of a result of the electronic commerce transaction.
17. The computer-readable medium of claim 15, wherein the instructions for storing item information received from the remote merchant comprise: instructions for receiving payment processing rules from the remote merchant specifying payment options for the electronic commerce transaction; and instructions for receiving delivery rules from the remote merchant specifying delivery options for the electronic commerce transaction.
PCT/US1998/015884 1997-07-29 1998-07-28 Method and system for conducting electronic commerce transactions WO1999007121A2 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP98938165A EP1004086A2 (en) 1997-07-29 1998-07-28 Method and system for conducting electronic commerce transactions
JP2000505721A JP2001512863A (en) 1997-07-29 1998-07-28 Method and system for processing e-commerce transactions
AU86753/98A AU8675398A (en) 1997-07-29 1998-07-28 Method and system for conducting electronic commerce transactions
IL13417898A IL134178A0 (en) 1997-07-29 1998-07-28 Method and system for conducting electronic commerce transactions
CA002297930A CA2297930A1 (en) 1997-07-29 1998-07-28 Method and system for conducting electronic commerce transactions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US5412197P 1997-07-29 1997-07-29
US60/054,121 1997-07-29

Publications (3)

Publication Number Publication Date
WO1999007121A2 WO1999007121A2 (en) 1999-02-11
WO1999007121A9 true WO1999007121A9 (en) 1999-04-29
WO1999007121A3 WO1999007121A3 (en) 1999-07-08

Family

ID=21988926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/015884 WO1999007121A2 (en) 1997-07-29 1998-07-28 Method and system for conducting electronic commerce transactions

Country Status (7)

Country Link
EP (1) EP1004086A2 (en)
JP (1) JP2001512863A (en)
CN (1) CN1267380A (en)
AU (1) AU8675398A (en)
CA (1) CA2297930A1 (en)
IL (1) IL134178A0 (en)
WO (1) WO1999007121A2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8010417B2 (en) 1997-07-08 2011-08-30 Walker Digital, Llc System and process for local acquisition of products priced online
US8880428B2 (en) 2001-03-19 2014-11-04 Ipventure, Inc. Restricted purchase of regulated items over a network
US8892470B2 (en) 1997-12-19 2014-11-18 Walker Digital, Llc Pre-sale data broadcast system and method
US9171316B2 (en) 1997-08-26 2015-10-27 Inventor Holdings, Llc Method and apparatus for vending a combination of products
US9342808B2 (en) 1999-05-11 2016-05-17 June Ray Limited Load balancing technique implemented in a data network device utilizing a data cache
US9413808B2 (en) 2000-05-10 2016-08-09 June Ray Limited Data transmission and rendering techniques by a device via a network
US9471910B2 (en) 1999-10-25 2016-10-18 Smartflash, LLC Data storage and access systems
US11651369B2 (en) 2018-07-12 2023-05-16 American Express Travel Related Services Company, Inc. Remote EMV payment applications

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970837B1 (en) 1996-09-04 2005-11-29 Walker Digital, Llc Methods and apparatus wherein a buyer arranges to purchase a first product using a communication network and subsequently takes possession of a substitute product at a retailer
US7711604B1 (en) 1997-07-08 2010-05-04 Walker Digital, Llc Retail system for selling products based on a flexible product description
CA2291920A1 (en) * 1998-12-11 2000-06-11 Karuna Ganesan Technique for conducting secure transactions over a network
US7177825B1 (en) 1999-05-11 2007-02-13 Borders Louis H Integrated system for ordering, fulfillment, and delivery of consumer products using a data network
AUPQ028599A0 (en) * 1999-05-11 1999-06-03 Vista Group Pty Limited Telecommunications system
US7139637B1 (en) 1999-05-11 2006-11-21 William Henry Waddington Order allocation to minimize container stops in a distribution center
EP1101209A1 (en) * 1999-06-03 2001-05-23 Global Payment Advisors An automated payment system for execution and settlement of network purchase transactions
WO2001008029A2 (en) * 1999-07-23 2001-02-01 Supertracks. Com, Inc. Digital/internet distribution channel management system for digital content
US6285986B1 (en) * 1999-08-11 2001-09-04 Venturemakers Llc Method of and apparatus for interactive automated registration, negotiation and marketing for combining products and services from one or more vendors together to be sold as a unit
DK199901135A (en) * 1999-08-18 2001-02-19 Webcard Aps Procedure and arrangement for carrying out financial transactions
WO2001016822A1 (en) * 1999-09-01 2001-03-08 Sony Corporation Electronic commodity purchasing method and commerce device
US7370006B2 (en) 1999-10-27 2008-05-06 Ebay, Inc. Method and apparatus for listing goods for sale
US7774234B1 (en) 1999-10-27 2010-08-10 Half.Com, Inc. Method and apparatus for optimizing seller selection in a multi-seller environment
US7373317B1 (en) 1999-10-27 2008-05-13 Ebay, Inc. Method and apparatus for facilitating sales of goods by independent parties
JP2001125977A (en) * 1999-10-29 2001-05-11 Fujitsu Ltd Network system, charging processor, dealer processor and recording medium
WO2001041097A1 (en) * 1999-11-30 2001-06-07 Brian Mollagrean System for facilitating payment for goods
WO2001045057A1 (en) * 1999-12-14 2001-06-21 Hypercom Corporation Method and apparatus for point of sale device to access web site for processing orders and fulfillment information
SG89314A1 (en) * 2000-01-18 2002-06-18 Cazh Pte Ltd Secure network electronic transactions and payments system
US7742989B2 (en) 2000-02-03 2010-06-22 Afterbot, Inc. Digital receipt generation from information electronically read from product
CA2399101A1 (en) * 2000-02-03 2001-08-09 Afterbot, Inc. Electronic transaction receipt system and method
US7552087B2 (en) 2000-02-03 2009-06-23 Afterbot, Inc. Electronic transaction receipt system and method
US20010032878A1 (en) * 2000-02-09 2001-10-25 Tsiounis Yiannis S. Method and system for making anonymous electronic payments on the world wide web
AUPQ556600A0 (en) * 2000-02-14 2000-03-02 Ong, Yong Kin (Michael) Electronic funds transfers-zipfund
AUPQ696500A0 (en) * 2000-04-17 2000-05-11 Qsi Payment Technologies Pty Ltd Electronic commerce payment system
US6618705B1 (en) * 2000-04-19 2003-09-09 Tiejun (Ronald) Wang Method and system for conducting business in a transnational e-commerce network
AU2001257280C1 (en) 2000-04-24 2009-01-15 Visa International Service Association Online payer authentication service
WO2001090971A2 (en) * 2000-05-26 2001-11-29 Nvcnet Web Business Services Secure payment process for on-line transactions
US7269160B1 (en) * 2000-05-26 2007-09-11 Buffalo International, Inc. Voice over internet call center integration
US6978380B1 (en) 2000-06-06 2005-12-20 Commerciant, L.P. System and method for secure authentication of a subscriber of network services
EP1164515A1 (en) * 2000-06-09 2001-12-19 INTERSHOP Software Entwicklungs GmbH Method and apparatus for processing an online transaction over a communication network
EP2770455B1 (en) * 2000-06-16 2017-01-25 MIH Technology Holdings BV Method and system to exercise geographic restrictions over the distribution of content via a network
GB2367411C (en) 2000-07-10 2007-12-12 Garry Harold Gibson Pyment system
JP2002049844A (en) * 2000-08-04 2002-02-15 Nec Corp Method and system acting for campaign advertisement, and recording medium
GB2366162A (en) * 2000-08-15 2002-02-27 Chargenet Ltd Controlling access to a telecommunicated data file
ITRE20000084A1 (en) * 2000-09-06 2002-03-06 Credemtel S P A COMPUTERIZED SYSTEM TO PERFORM ONLINE TRADE EXCHANGES
WO2002037341A1 (en) * 2000-10-27 2002-05-10 Mitsubishi Denki Kabushiki Kaisha Facility plan support method, server computer of facility plan support system, and client computer of facility plan support system
JP2002251529A (en) * 2001-02-22 2002-09-06 Sony Corp System for providing and acquiring contents, device for providing contents, device for acquiring contents, method of providing and acquiring contents, method of providing contents, method of acquiring contents, storage medium for program for providing contents, storage medium for program for acquiring contents, program for providing contents, and program for acquiring contents
CN1593038A (en) * 2001-02-26 2005-03-09 陈军 Method of realizing product and service distributing and its commercial network system
WO2002071173A2 (en) * 2001-03-01 2002-09-12 Fisher-Rosemount Systems, Inc. Data sharing in a process plant
US7752134B2 (en) * 2001-03-20 2010-07-06 United Parcel Service Of America, Inc. Hybrid credit card transaction system
FR2823334A1 (en) * 2001-04-05 2002-10-11 Alain Sztajnman Internet on-line payment, uses a verification stage on a intermediary server of a digital file containing a vendors identifier
FR2829601B1 (en) * 2001-09-13 2007-03-09 Alexandre Fusiller METHOD AND INSTALLATION FOR SECURING A PAYMENT OPERATION CARRIED OUT FOR THE REMOTE PURCHASE OF PRODUCTS AND / OR SERVICES OVER A DIGITAL INFORMATION COMMUNICATION NETWORK
FI20012044A (en) 2001-10-22 2003-04-23 Portalify Oy Procedure and telecommunication networks to offer and bill for services
ES2659723T3 (en) * 2002-06-12 2018-03-19 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US7693739B2 (en) 2003-09-05 2010-04-06 Sensitech Inc. Automated generation of reports reflecting statistical analyses of supply chain processes
JP2005135093A (en) * 2003-10-29 2005-05-26 Fujitsu Ltd Electronic payment support system and electronic payment support apparatus
FR2867293B1 (en) * 2004-03-03 2006-06-16 Biz N Cash MICROPAYMENT METHOD AND SYSTEM
GB2459529A (en) * 2008-04-28 2009-11-04 Ice Organisation Online transaction authentication using two servers
US8762210B2 (en) 2008-06-03 2014-06-24 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US10157375B2 (en) 2008-06-03 2018-12-18 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
CN102024217A (en) * 2009-09-14 2011-04-20 上海领意信息技术有限公司 Large-payment transaction access system
GB201117293D0 (en) * 2011-10-07 2011-11-16 Mgt Plc Secure payment system
CN103581106A (en) * 2012-07-19 2014-02-12 深圳市财付通科技有限公司 Interactive processing method and interactive processing system
US20140122328A1 (en) * 2012-10-29 2014-05-01 Bank Of America Corporation Mobile device for multiple payment modes
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US10460367B2 (en) 2016-04-29 2019-10-29 Bank Of America Corporation System for user authentication based on linking a randomly generated number to the user and a physical item
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
GB2567081A (en) 2016-07-15 2019-04-03 Cardinalcommerce Coorporation Authentication to authorization bridge using enriched messages
CN107016116A (en) * 2017-04-18 2017-08-04 赖灿 A kind of method by quoting specific knowledge progress commodity production

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5745681A (en) * 1996-01-11 1998-04-28 Sun Microsystems, Inc. Stateless shopping cart for the web
US6490567B1 (en) * 1997-01-15 2002-12-03 At&T Corp. System and method for distributed content electronic commerce

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8010417B2 (en) 1997-07-08 2011-08-30 Walker Digital, Llc System and process for local acquisition of products priced online
US9171316B2 (en) 1997-08-26 2015-10-27 Inventor Holdings, Llc Method and apparatus for vending a combination of products
US8892470B2 (en) 1997-12-19 2014-11-18 Walker Digital, Llc Pre-sale data broadcast system and method
US9342808B2 (en) 1999-05-11 2016-05-17 June Ray Limited Load balancing technique implemented in a data network device utilizing a data cache
US9396451B2 (en) 1999-05-11 2016-07-19 June Ray Limited Method and system for order fulfillment in a distribution center
US9471910B2 (en) 1999-10-25 2016-10-18 Smartflash, LLC Data storage and access systems
US9413808B2 (en) 2000-05-10 2016-08-09 June Ray Limited Data transmission and rendering techniques by a device via a network
US8880428B2 (en) 2001-03-19 2014-11-04 Ipventure, Inc. Restricted purchase of regulated items over a network
US11651369B2 (en) 2018-07-12 2023-05-16 American Express Travel Related Services Company, Inc. Remote EMV payment applications

Also Published As

Publication number Publication date
JP2001512863A (en) 2001-08-28
WO1999007121A2 (en) 1999-02-11
CA2297930A1 (en) 1999-02-11
CN1267380A (en) 2000-09-20
IL134178A0 (en) 2001-04-30
AU8675398A (en) 1999-02-22
EP1004086A2 (en) 2000-05-31
WO1999007121A3 (en) 1999-07-08

Similar Documents

Publication Publication Date Title
WO1999007121A9 (en) Method and system for conducting electronic commerce transactions
US10163101B1 (en) Electronic commerce using a transaction network
US5710887A (en) Computer system and method for electronic commerce
US6799165B1 (en) Apparatus and methods for inventory, sale, and delivery of digitally transferable goods
US7668782B1 (en) Electronic commerce system for offer and acceptance negotiation with encryption
US20040078276A1 (en) System for electronic merchandising and shopping
US20020103753A1 (en) Charge splitter application
US20020077973A1 (en) Method and apparatus for issuing prepaid e-cash and calling cards and method of using the same
US20020174018A1 (en) Method, system, and computer readable medium for facilitating a transaction between a customer, a merchant and an associate
US20020184104A1 (en) Integrated retail and wholesale system
US20060161484A1 (en) Method and system for operating an internet accessible multi-merchant universal compilation of items
JP2001243386A (en) System and method for executing electronic commercial transaction while using commercial transaction substituting processing with electronic wallet
US20070299745A1 (en) Method and apparatus for marketing products over the internet
WO2003054819A2 (en) Global integrated payment system
JP2001306864A (en) Agent purchase method, agent purchase system and recording medium with transaction management program recorded therein
US20030120549A1 (en) Method and apparatus for offering digital content for sale over a communications network
WO2002029508A2 (en) Broker-mediated online shopping system and method
US7647244B2 (en) Method for providing a certificate for an online product
KR20010077123A (en) A package payment and delivery method using a common shopping cart in a computer network shopping
US20030088475A1 (en) Remote transaction and tracking protocol for internet commerce
JP3632051B2 (en) Network payment processing system, network payment processing device, network payment processing method, and network payment processing program
KR100437123B1 (en) System and method for sanction through electronic shopping mall on network
US7761338B1 (en) Automation goods and services transaction systems and methods
KR100372919B1 (en) Electronic Commerce System and Selling Method in the Same
KR20020053814A (en) System and methods for implementing e-commerce services

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 134178

Country of ref document: IL

Ref document number: 98807677.2

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SZ 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

AK Designated states

Kind code of ref document: C2

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

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW SD SZ 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

COP Corrected version of pamphlet

Free format text: PAGES 1/6-6/6, DRAWINGS, REPLACED BY NEW PAGES 1/6-6/6; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

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

Kind code of ref document: A3

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

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SZ 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

ENP Entry into the national phase

Ref document number: 2297930

Country of ref document: CA

Ref document number: 2297930

Country of ref document: CA

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1998938165

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: PA/A/2000/000978

Country of ref document: MX

NENP Non-entry into the national phase

Ref country code: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 1998938165

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1998938165

Country of ref document: EP