EXHIBIT 1004
`
`
`
`TO PETITIONER GOOGLE INC.’S
`PETITION FOR COVERED BUSINESS
`METHOD REVIEW OF
`U.S. PATENT NO. 7,334,720
`
`
`
`
`
`

`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`International Bureau
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(51) International Patent Classification 6 ‘
`H04L 25/02
`
`(11) International Publication Number:
`_
`_
`_
`(43) International Publication Date:
`
`WO 99/07121
`
`1] February 1999 (1l.02.99)
`
`(21) International Application Number:
`
`PCT/US98/15884
`
`(22) International Filing Date:
`
`28 July 1998 (28.07.98)
`
`(30) Priority Data:
`60/054,121
`
`29 July 1997 (2907.97)
`
`US
`
`(71) Applicant: NETADVANTAGE CORPORATION [US/US];
`Suite B, 1674 North Shoreline Boulevard, Mountain View,
`CA 94043-1316 (US).
`
`(81) Designated States: 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, TI,
`TM, TR, TT, UA, UG, UZ, VN, YU, ZW, ARIPO patent
`(GH, GM, KE, LS, MW, SD, SZ, UG, ZW), Eurasian patent
`(AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European patent
`(AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT,
`LU, MC, NL» PT, SE), OAPI patent (BF, BJ, CF, CG, CI,
`CM, GA, GN, GW, ML, MR, NE, SN, TD, TG).
`
`(72) Inventor: FETIK, Richard, J.; #4 Comstock Queen Court,
`Mountain View, CA 94043 (US).
`
`Published
`Without international Search report and to be republished
`upon receipt of that report.
`
`(74) Agents: HOFFMAN, Brian, M. et al.; Fenwick & West LLP,
`Two Palo Alto Square, Palo Alto, CA 94306 (US).
`
`(54) Title: METHOD AND SYSTEM FOR CONDUCTING ELECTRONIC COMMERCE TRANSACTIONS
`
`(57) 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.
`
`Google Exhibit 1004 Page 00001
`
`Google Exhibit 1004 Page 00001
`
`

`
`FOR THE PURPOSES OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
`
`Albania
`Armenia
`Austria
`Australia
`Azerbaijan
`Bosnia and Herzegovina
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belarus
`Canada
`Central African Republic
`Congo
`Switzerland
`Cote d’Ivoire
`Cameroon
`China
`Cuba
`Czech Republic
`Germany
`Denmark
`Estonia
`
`ES
`FI
`FR
`GA
`GB
`GE
`GH
`GN
`GR
`HU
`IE
`IL
`IS
`IT
`JP
`KE
`KG
`KP
`
`KR
`KZ
`LC
`LI
`LK
`LR
`
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenya
`Kyrgyzstan
`Democratic People's
`Republic of Korea
`Republic of Korea
`Kazakstan
`Saint Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`
`LS
`LT
`LU
`LV
`MC
`MD
`MG
`MK
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`NO
`NZ
`PL
`PT
`RO
`RU
`SD
`SE
`SG
`
`Lesotho
`Lithuania
`Luxembourg
`Latvia
`Monaco
`Republic of Moldova
`Madagascar
`The fonner Yugoslav
`Republic of Macedonia
`Mali
`Mongolia
`Mauritania
`Malawi
`Mexico
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`Singapore
`
`SI
`SK
`SN
`SZ
`TD
`TG
`TJ
`TM
`TR
`TT
`UA
`UG
`US
`UZ
`VN
`YU
`ZW
`
`Slovenia
`Slovakia
`Senegal
`Swaziland
`Chad
`Togo
`Tajikistan
`Turkmenistan
`Turkey
`Trinidad and Tobago
`Ukraine
`Uganda
`United States of America
`Uzbekistan
`Viet Nam
`Yugoslavia
`Zimbabwe
`
`Page 00002
`
`Page 00002
`
`

`
`wo 99/07121
`
`PCT/US98/15884
`
`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
`
`Page 00003
`
`Page 00003
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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 Intemet-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 or 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 paymentoptions that are
`
`acceptable to the merchant, such as which currencies and payment systems are allowed and
`
`when or how often to bill the customer.
`
`Page 00004
`
`Page 00004
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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
`
`Page 00005
`
`Page 00005
`
`

`
`WO 99/07121
`
`PCT/US98/15884
`
`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-
`
`Intemet-based system, the terms defined above also include the non-Intemet-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”) H2, and a commerce server (“CS”) 114, all coupled to the Internet ll6. In a
`
`4
`
`Page 00006
`
`Page 00006
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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
`
`5
`
`Page 00007
`
`Page 00007
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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 C S 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 S1lCC6SSfU.i. 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 sofiware 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.
`
`Page 00008
`
`Page 00008
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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 r
`
`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
`
`7
`
`Page 00009
`
`Page 00009
`
`

`
`WO 99/07121
`
`PCT/US98/15884
`
`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
`
`r
`
`abstraction module 220 also translates data received from the payment system 222 or merchant
`
`223 into the format utilized by the transaction engine 21 0. 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 (“S SL”), 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
`
`8
`
`Page 00010
`
`Page 00010
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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
`
`1 12 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 afier 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 ll2 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.
`
`Page 00011
`
`Page 00011
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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
`
`10
`
`Page 00012
`
`Page 00012
`
`

`
`W0 99/07121
`
`PCT/US98/15884
`
`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