WO2000067104A1 - E-commerce consumer interface - Google Patents

Abstract

A consumer interface (10) and a presentation method for interaction with a consumer in an e-commerce shopping system provided with a server having a merchant interface web site (12), a production section list (16) and a product data (56), a consumer terminal (2) having a display device and being operated by the consumer, and a network (4) connecting the server and the consumer terminal (2), comprising downloading the merchant interface web site (12), the product section list (16) and the product data (56) to the consumer terminal; displaying in a window on the display device of the consumer terminal (2) the merchant interface web site (12); displaying a shopping cart display (14), a product section list (16) and a product display area (18) in the merchant interface web site (12); displaying the product data (56) within the product display area (18); and, displaying in the shopping cart display (14) any products selected by the consumer from interaction with the product display area (18).

Description

E-COMMERCE CONSUMER INTERFACE

CLAIM OF PRIORITY

This application claims the priority of Provisional Application No. 60/132,049, filed on April 30, 1999 and a Provision Application filed on April 27, 2000, both in the name of George E. Shupe, Jr. and Henry Chang and both of which are incorporated herein by reference.

FIELD OF THE INVENTION

This invention relates to e-commerce conducted over a network, such as the Internet, and more particularly, to consumer interfaces for purchasing products or services online. Further, this invention relates to merchant web sites, and more particularly, to automated and efficient construction and maintenance of merchant web sites . BACKGROUND OF THE INVENTION

Conventional on-line consumer shopping interfaces, or "shopping carts", cause viewer and shopper frustration. The page organization and design of conventional shopping interfaces are inefficient, which cause page sprawl and slowed information and transaction flow. Commonly, product displays and listings are fragmented, which inhibit transaction flow and cause cumbersome purchasing procedures.

The viewable screen area on small monitors for computers is limited, and it is difficult to provide comprehensive e-commerce functionality onto a 14 inch screen display without losing legibility for the average viewer. A 14 inch monitor is the practical lowest common denominator for Internet surfers and shoppers. Conventional shopping interfaces have not adequately addressed this problem. As a result, conventional shopping interfaces generally require considerable effort to navigate and purchase items .

Conventionally, e-commerce merchant web sites require custom individual production, which is inefficient and generally expensive. Too much time is being spent to develop e-commerce web sites with product databases, shopping carts and transaction features on a custom basis. Currently, the expenses incurred with custom development, maintenance, adjustments, and upgrades of e-commerce web sites are too excessive. Further, maintaining and updating merchant sites is too complex for laymen. Most web site producers focus on custom production of web sites, which is generally expensive. Many merchants cannot afford the expenses associated with custom design, or they do not want to invest too much money in developing the site. In effect, most web sites produced today are inefficient, from the standpoint of resultant economic flow.

OBJECTS AND SUMMARY OF THE INVENTION

It is an object of the present invention to provide an efficient consumer interface for shopping over a network . A further object of the present invention is to provide an efficient and automated platform for creating and maintaining e- commerce web sites on a network.

Yet a further object of the present invention is to provide an e-commerce consumer shopping interface having a product database listing, a product section list, product search capabilities, and a shopping cart, from which products can be selected and directly viewed in their tabulated shopping list form for immediate entry for purchase.

Still a further object of the present invention is to provide a consumer shopping interface, which displays the products or services available for purchase on the same page as a shopping cart .

A further object of the present invention to provide a consumer shopping interface that will display previous shopping lists. Another object of the present invention is to provide a consumer shopping interface that provides a consumer with the ability to access merchant membership privileges.

Yet another object of the present invention is to provide a merchant interface that enables layman merchants to create a merchant e-commerce web site.

Still a further object of the present invention is to provide a merchant interface that enables merchants to modify their web sites easily, efficiently and on a user-friendly basis. A further object of the present invention is to provide a merchant interface that enables a merchant to create and maintain an e-commerce web site, which does not require web page programming skills.

Yet another object of the present invention is to assist merchants who have declined paying for expensive front end development costs for custom Internet merchant sites, or merchants who desire low cost, solidly designed database product merchant sites for the Internet as a replacement for their current sites . Through the implementation of compact and efficient deployment of displays and functional features, and use of scripting software, such as JavaScript, which is resident on the user's browser that the present invention provides a speedy and efficient shopping site product for e-commerce that gets purchasers to the point of purchase quickly without wasting time or space on a network. The present invention eliminates the problem of expensive up front custom design fees and set up costs for merchants. Further, the maintenance interface is user- friendly so that normal laymen can use and maintain the web sites, instead of requiring computer experts. This product will save time and money.

In summary, an object of the present invention is a method of providing a consumer purchasing interface, comprising, displaying on a client side computer terminal in a single window, a shopping cart, a product category list, an available products display and a checkout button; for each product selection by a consumer via an input device of the client side computer terminal, storing the selection in the shopping cart; for each product removal by the consumer with the input device, removing the product selection from the shopping cart; for each product removal and product selection by the consumer with the input device, calculating a sub-total purchase amount; for each product category change requested by the consumer with the input device, displaying in the available pro a corresponding available product display for the selected category in the available products display; and, transferring product selections to a server via a network, pursuant to the consumers selection of the checkout via the input device .

Further, the present invention provides a consumer interface presentation method for interaction with a consumer in an e-commerce shopping system provided with a server having a merchant consumer interface web site, a production section list and a product description data, a consumer terminal having a display device and being operated by the consumer, and a network connecting the server and the consumer terminal, comprising, downloading the merchant consumer interface web site, the product section list and the product data to the consumer terminal ,- displaying in a window on the display device of the consumer terminal the merchant consumer interface web site; displaying a shopping cart display, a product section list and a product display area in the merchant consumer interface web site; displaying the product data within the product display area; displaying the product section data within the product section list; and, displaying in the shopping cart display any products selected by the consumer from interaction with the product display area. In further summary, the present invention provides a method of viewing and placing orders for products and services over a network, comprising, a client computer system displaying in a single window on a display device, a plurality of available products, available product sections, a shopping cart and a checkout button; recording product selections for order, pursuant to a selection of one of the plurality of available products by a client; totaling the cost of all selected products recorded for order; sending an order submission to a server system, pursuant to a selection of a checkout button by the client; and, on a server system connected to the client computer system via a network, receiving the submission from the sending an order submission step; generating an order form from the submission from the sending an order submission step; and, forwarding the order form to a merchant and the client .

The present invention also provides an e-commerce shopping system comprising, a network; a server being connected to the network, and having a consumer shopping interface including a shopping cart, available product data, a product category list and a checkout; and, a consumer terminal connected to the network and including a display device for displaying the consumer shopping interface and an input device for selecting products from the available product data by a consumer, whereby the consumer may select the checkout to submit the selected products to the server via the network.

The present invention also provides for a computer-readable medium containing instructions for controlling a computer system to create a merchant consumer interface web site from a merchant registration form having a merchant requested folder name, by retrieving a list of new merchants to add; for each merchant in the list of new merchants to add, determining if the merchant requested folder name is available by comparing the merchant requested folder name to merchant folder names database; creating a new merchant folder name if the merchant requested folder name is not available; adding merchant folder name to the merchant folder names database to create a merchant folder; creating a site maintenance structure file; creating a storefront structure file; creating a password file; creating a login file; copying site supporting files from a first memory location to the merchant folder; and, removing merchant from the list of new merchants to add.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of an example e-commerce system configuration in accordance with the present invention.

Figure 2 is a screen configuration of an example of a consumer interface in accordance with the present invention.

Figure 3 is a block diagram of a consumer purchasing process and interaction with an example consumer interface.

Figure 4 is a block diagram of a registration, site startup, maintenance, shopping and purchase processes.

Figure 5A is a block diagram of a merchant registration process . Figure 5B is a block diagram of an automated merchant site set up.

Figure 6 is a block diagram of a merchant site maintenance interface .

Figure 7 is a block diagram of a merchant login page. Figure 8A is a block diagram of a merchant site maintenance interface, namely adding product.

Figure 8B is a block diagram of an add product process. Figure 9A is a block diagram of a merchant site maintenance interface, namely editing product. Figure 9B is a block diagram of an edit product process .

Figure 10A is a block diagram of a merchant site maintenance interface, namely deleting product.

Figure 10B is a block diagram of a delete product process. Figure 11 is a block diagram of a merchant site maintenance interface, namely setting up a welcome page.

Figure 12 is a block diagram of a merchant site maintenance interface, namely providing contact information.

Figure 13 is a block diagram of a merchant site maintenance interface, namely setting tax features.

Figure 14 is a block diagram of a merchant site maintenance interface, namely setting up shipping information.

Figure 15A is a block diagram of a merchant site maintenance interface, namely merchant site database backup/restore. Figure 15B is a block diagram of a backup/restore process.

Figure 16 is a block diagram of a merchant site maintenance interface, namely help functions.

Figure 17 is a block diagram of a merchant site maintenance interface, namely editing consumer interface. Figure 18 is a block diagram of a merchant site maintenance interface, namely viewing the storefront.

Figure 19 is a block diagram of consumer interface functions .

Figure 20 is a block diagram of a checkout page and display of order confirmation. DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a merchant sales web site design that combines a selectable database product display and real time updated shopping cart, with supporting functional features, and fits into a compact but legible 14" screen size display. This legible tight fitting of multiple functions condenses what normally requires more than one functional interface page into a single interface page, thus eliminating the need to click or move between multiple interface pages to maintain a total understanding of product availability, selected products, quantities, and total price of selected products. The present invention enables a consumer or shopper to conduct his browsing and product selection rapidly with the shopping list in full view being constantly updated and totaled. When ready the shopper may click the checkout button to go to a checkout page. The checkout page allows the shopper to input his contact and delivery address information. The checkout software correlates the shopper's delivery address with applicable merchant defined state taxes. The shopper selected shipping method is referenced to the purchase amount and the corresponding merchant defined shipping cost is calculated. Much of the shopping process and interface calculations are designed to occur without calling the server, thus saving shopper time in the case of slow conventional telephone shopper access to the Internet. Additional features that enhance shopper loyalty to the merchant are Member Pricing and Shopping List Memory functions. The present invention also provides a merchant site interface that allows laymen merchant personnel to input and manipulate product price, description, and graphical data, hierarchy of organization, as well as color, text, and graphical look and feel of the merchant's sales site, namely the consumer interface. This on-line layman-friendly interface provides easy manipulation of an Internet product database, and merchant site for non-programmers. The merchant interface also includes other features, such as display of product entries just uploaded to the server, and easy to use tax and shipping entry matrices. The merchant interface pages are laid out in a clear and understandable manner so laymen users will not get lost or confused. The merchant interface functions are also inter-linked and coordinated so that the merchant site database will maintain its integrity as the data is manipulated in diverse ways. These features and more will be described further below.

Figure 1 displays a block diagram of an exemplary e-commerce system configuration in accordance with the present invention. A consumer, using a consumer computer 2, connects to a network 4 to view and access web sites on an e-commerce server 6. A merchant, using a merchant computer 8, connects to network 4 to access e-commerce server 6 to create and maintain web sites, not shown, for viewing and access by consumer computer 2.

Consumer computer 2 and merchant computer 8 are common personal computers having standard peripheral equipment, such as a display device, communication hardware and software, as well as input devices like a keyboard and a mouse. It is understood that consumer computer 2 and merchant computer 8 may be of any type of terminal having communication access with network 4. Further computers 2 and 8 also include commercially available network browsing software such as Netscape Navigator or Internet Explorer, or the like.

Network 4 is preferred to be the Internet, or sometimes referred to as the World Wide Web. Network 4, may however, be any inter or intra network, i.e. a local area network or metropolitan area network, etc. The methods of how computers 2 and 8, and server 6 connect to network 4 are well known in the art . For example a user may connect to the Internet via a commercial Internet Service Provider.

Server 6 consists of hardware, an operating system and peripherals such as input devices, display devices, communication devices, etc. Server 6 will also include software which is HTTP (hypertext transfer protocol) and CGI (common gateway interface) compliant and may or may not include SQL database software. Servers and the appropriate peripherals and communication software necessary for communicating with a network, namely the Internet, and for hosting web sites are common in the industry. A host operates or has someone operate a server for the storing of web sites and software. Further, server 6 can be one computer system or a network of systems or servers .

E-commerce server 6 includes software that provides a consumer interface 10 to be displayed on consumer computer 2, and a merchant interface 12 to be displayed on merchant computer 8, and for maintenance of a merchant site.

Figure 2 displays an embodiment of consumer interface 10 as displayed by a commercially available network browser on a display device of consumer computer 2. The consumer interface 10 shown in Figure 2 is for a hypothetical office supply merchant. Consumer interface 10 may be used for any type of products or services.

Interface 10 includes a shopping cart 14, product section list 16 and a product display 18. A Member Pricing product display, not shown in Figure 2, may be displayed in product display 18 if the merchant has activated this feature, as is discussed further below. Interface 10 also includes a search store area 20, a checkout link 22 and a store banner 24. Interface 10 also includes a date indicator 26, which displays the day of the week and the date.

Shopping cart 14 includes a selected product display 28, a quantity column 30 that corresponds with selected product display 28, a purchase total display 32 and an empty cart button 34. Empty cart button 34 is displayed adjacent checkout link 22. Empty cart button 34 may also be displayed within shopping cart 14. Quantity column 32 is preferred to be adjacent to selected product display 28, and further preferred to be displayed to the left of selected product display 28. The quantities of the selected products are editable in realtime without calling the server, as will be discussed further below.

Product section list 16 includes product section links 36 and other links list 38. Product section links 36 is a listing of the various product categories available at the particular site. Product section list 36 may be thought of as aisles or departments in a store. Other links list 38 includes a welcome page link 40, an introduction/help page link 42 and one or more shopping lists links 44. Other links list 38 can also include links to other external web sites. A slider bar, not shown, may also be included based on the number of product sections listed. If the list is longer than the screen display area, a slider or scroll bar will be provided.

Product display 18 includes the products or services available for purchase 46. A product sort button 48 enables a consumer to sort product display 18 by product name, price, or type. Product sort button is preferred to be a drop-down menu. As will be discussed further below, product display 18 may also include a product viewing options menu 50, allowing the products to be view with or without icons. A slider bar 52 is provided in product display 18 if the displayed products are longer than the viewable area.

Each available product 46 includes a product title 54, a product description 56, a product purchase amount 58 and a buy button 60. A Member Pricing discounted product purchase amount, not shown, may also be included. Available products may also include a product icon 62, which can be clicked to cause the display of an enlarge product image if loaded on the merchant site database, as will be discussed further below. It is preferred to display product title 54 above product description 56. Product purchase amount 58 is displayed adjacent to and to the right of product title 54. Buy button 60 is displayed adjacent to and below product purchase amount 58. To the extent the merchant has made product icons 62 available, product icons 62 are displayed adjacent to and to the left of product title 54. It is further preferred to display product sort button 48 above available products 46. This positioning will provide the consumer with a readily recognizable choice of being able to choose how available products 46 are to be displayed, as will be discussed further below. Further, to the extent the merchant has provided product icons 62, product viewing options menu 50 is displayed above available products 46. This positioning will also give the consumer a readily recognizable choice of whether to view product icons, as will be discussed below.

Consumer interface 10 also includes a miscellaneous section 64 for displaying various other links, such as for example user agreement link 66, disclaimer link 68, and trademark & copyright information link 70. Consumer interface 10 is visually arranged to enhance the e- commerce shopping experience. Product section list 16 is displayed between shopping cart 14 and product display 18. Shopping cart 14 is displayed adjacent to and to the left of product section list 16. Product display 18 is displayed adjacent to and to the right of product section list 16.

Search store area 20 is displayed adjacent to and above shopping cart 14. Checkout link 22 is displayed below shopping cart 14. Store banner 24 is preferably displayed across the top of consumer interface 10. Date indicator 26 may be displayed in any convenient position, but it is preferred to be displayed at the top right position of interface 10.

Product section links 36 and other links list 38 are displayed within product section list 16. It is preferred that product section links 36 be displayed below other links list 38. However these items may be displayed in other relative display arrangements .

Web pages are often comprised of or divided into frames. Shopping cart 14 and product display 18 are in separate frames. This allows the display in product display 18 to be changed separately from changing shopping cart 14. Consumer interface 10 can include many frames to comprise the various components mentioned above separately or in combinations .

Figure 3 displays a block diagram of the consumer process of viewing and ordering products or services with a preferred embodiment of the present invention. A consumer or shopper (used interchangeably) , logs onto network 4, at 72, and then the consumer accesses a particular merchant ' s site at 74 that is hosted by server 6 (shown in Figure 1) . The consumer accesses the merchant sales site by typing in the web site address or URL (Uniform Resource Locator) of the merchant . The shopper may also access the merchant ' s by clicking on an appropriate hyperlink in another web site, provided the merchant's site is linked to the other site. A URL is the address of a file (resource) accessible on the

Internet . The type of resource depends on the Internet application protocol. Using the World Wide Web's (or the Internet's) protocol, the Hypertext Transfer Protocol (HTTP) , the resource can be an HTML page, an image file, a program such as a CGI application or Java applet, or any other file supported by HTTP. The URL contains the name of the protocol required to access the resource, a domain name that identifies a specific computer on the Internet, and a hierarchical description of a file location on the computer. On the Web (which uses the Hypertext Transfer Protocol), an example of a URL is: http://www.example.org/hypothetical which describes a Web page to be accessed with an HTTP (Web browser) application that is located on a computer named www.example.org. The specific file is in the directory named /hypothetical and is the default page in that directory. An HTTP URL can be for any Web page, not just a home page, or any individual file. A URL for a program such as a forms-handling CGI script written in Perl might look like this: httr> : //example . com/cαi-bin/comments .pi . By way of background, the common gateway interface (CGI) is a standard way for a Web server to pass a Web user's request to an application program and to receive data back to forward to the user. When the user requests a Web page (for example, by clicking on a highlighted word or entering a Web site address) , the server sends back the requested page. However, when a user fills out a form on a Web page and sends it in, it usually needs to be processed by an application program. The Web server typically passes the form information to a small application program that processes the data and may send back a confirmation message. This method or convention for passing data back and forth between the server and the application is called the common gateway interface (CGI). It is part of the Web's HTTP protocol. If a Web site is being created and it is desired to have a CGI application to get control, the creator of the site specifies the name of the application in the URL that is coded in an HTML file. This URL can be specified as part of the FORMS tags if a form is being created. For example, a creator might code:

<FORM METHOD=POST ACTION=http : //www.mybiz . com/cgi-bin/formprog.pl> and the server at "mybiz.com" would pass control to the CGI application called "formprog.pl" to record the entered data and return a confirmation message. (The ".pi" indicates a program written in Perl but other languages may be used) .

The common gateway interface provides a consistent way for data to be passed from the user's request to the application program and back to the user. This means that the person who writes the application program can makes sure it gets used no matter which operating system the server uses (PC, Macintosh, UNIX, OS/390, or others) . It's simply a basic way for information to be passed from the Web server about a user's request to the application program and back again. Because the interface is consistent, a programmer can write a CGI application in a number of different languages. The most popular languages for CGI applications are: C, C++, Java, and Perl. An alternative to a CGI application is Microsoft's Active Server Page (ASP), in which a script embedded in a Web page is executed at the server before the page is sent .

Further, JavaScript is an interpreted programming or script language from Netscape. It is somewhat similar in capability to Microsoft's Visual Basic, Sun's Tel, the UNIX-derived Perl, and IBM's REXX. In general, script languages are easier and faster to code in than the more structured and compiled languages such as C and C++. Script languages generally take longer to process than compiled languages, but are very useful for shorter programs. JavaScript is used in Web site development to do such things as: automatically change a formatted date on a Web page; cause a linked-to page to appear in a popup window; or, cause text or a graphic image to change during a mouse rollover. JavaScript uses some of the same ideas found in Java, the compiled object-oriented language derived from C++. JavaScript code can be imbedded in HTML pages and interpreted by the Web browser (or client) . JavaScript can also be run at a server as in Microsoft's Active Server Pages (ASPs) before the page is sent to the requestor. Both Microsoft and Netscape browsers support JavaScript, but sometimes in slightly different ways.

HTML (Hypertext Markup Language) is the set of "markup" symbols or codes inserted in a file intended for display on a World Wide Web browser. The markup tells the Web browser how to display a Web page's words and images for the user. The individual markup codes are referred to as elements (but many people also refer to them as tags) . HTML is a standard recommended by the World Wide Web Consortium (W3C) and adhered to by the major browsers, Microsoft's Internet Explorer and Netscape's Navigator, which also provide some additional non-standard codes. The current version of HTML is HTML 4. However, both Internet Explorer and Netscape implement some features differently and provide non-standard extensions. Web developers using the more advanced features of HTML 4 may have to design pages for both browsers and send out the appropriate version to a user. Significant features in HTML 4 are sometimes described in general as dynamic HTML. What is sometimes referred to as HTML 5 is an extensible form of HTML called XHTML. Referring again to Figure 3, when a consumer connects to the merchant's site, server 6 downloads consumer interface 10 and a default product section page into the memory of the consumer's web browser. The consumer will see displayed on his display device shopping cart 14, product section list 16, product display 18, search store area 20 and checkout 22.

When a consumer virtually "arrives" at a merchant site, shopping cart 14 will initially be empty, i.e. no products selected. The consumer may, in the product section list 16, select a link in the product section list 36 or the other links list 38. The other links are such things as viewing a merchant welcome page 40 (Figure 2) , if such a page is not the default viewing page, viewing an introduction and help page 42 (Figure 2) or viewing shopping lists 44 (Figure 2) from previous visits to the merchant's site. The consumer may selectively choose these links, by clicking with a mouse or by some other input device, and server 6 will download the corresponding page/information to the browser replacing whatever is currently displayed in product display 18. By selecting shopping lists link 44, server 6 will provide a listing of all previous shopping activities at the merchant's site. The names of the previous shopping activities may be customized by the shopper and the shopper may also elect to have a shopping list be the default storefront for the next time the shopper returns to the site. With this option selected, server 6 places a cookie on the shopper's browser and when the shopper returns, server 6 recognizes the cookie and then populates shopping cart 14 with the shopping list . A cookie is information that a web site puts on a user's or shopper's computer hard disk drive so that it can remember something about the shopper at a later time. More specifically, it is information for future use that is stored by the server on the client side of a client/server communication. Typically, a cookie records a user's preferences when using a particular site. Using the Web's Hypertext Transfer Protocol (HTTP), each request for a Web page is independent of all other requests. For this reason, the web page server has no memory of what pages it has sent to a user previously or anything about the user's previous visits. A cookie is a mechanism that allows the server to store its own information about a user on the user's own computer. Cookies are commonly used to rotate the banner ads that a site sends so that it does not keep sending the same ads to a user on subsequent requested pages. They can also be used to customize pages for a user based on the user's browser type or other information the user may have provided the Web site. Web users must agree to let cookies be saved for them, but, in general, it helps Web sites to serve users better. When the consumer is done viewing and selecting any of the other links list 38, the consumer may simply select the "back" function on the browser or choose a product section 36 from product section list 16 or any other link on interface 10. When the consumer selectively chooses a product section at 36, which is different from the default product section or different from the current display in product display 18, server 6 downloads to the browser the corresponding available products for the selected product section to the product display 18 replacing whatever is currently displayed in product display 18. The modification of product display 18 changing product section list 36, or selecting other links list 38 is represented in Figure 3 by dashed lines. The consumer may selectively insert, with an input device such as a keyboard, a string of text in the search store area 20. The consumer, after inserting the desired text that may be associated with a particular product, choose a "go" button 75

(shown in Figure 2) located within the search store area 20, to submit the search request to server 6. Server 6 will then be called and all of the merchant ' s products will be searched to see if there is any matching products. If there are any matches, products or section listings, product display 18 will be modified to display the results. The modification of product display 18 is shown in Figure 3 by a dashed line.

The consumer may in the product display area 18, change the view options 50, change the product sort options 48 or select a product to buy with buy button 60 (Figure 2) .

To change the view options 50, the consumer may selectively choose, via an input device, whether the available products displayed in the product display 18 should be displayed as text only or displayed with icons. View options 50 will not be displayed if the merchant has previously chosen not to have product icons, as will be discussed further below.

To change the sorting of products, the product sort button or menu 48 is selected by the consumer. The products may be sorted alphabetically, by price or by product section.

The shopper views and selects goods or services to be purchased via the product display 18. When viewing the products, if the available products 46 exceed the height of the viewing area, then slider or scroll bar 52 will be provided along the right edge of product display 18. The shopper clicks on buy button 60 to add products to shopping cart 14. As products are selected, the selected product display 18 and the quantity column 30 of shopping cart 14 are modified, represented in Figure 3 by a dashed line. The selections are tabulated in real time in the shopping cart without a call to server 6. The shopper can increase the quantity of the desired product to be purchased by subsequent clicks on buy button 60. The shopper may also selectively increase or decrease the product quantities by directly typing over the quantity shown in an appropriate quantity box 7 (shown in Fig. 2) of shopping cart 14. If a quantity box in quantity column 30 is zero or blank, the corresponding product is removed from the shopping cart 14.

As the quantities of products shown in the quantity column change, purchase total display 32 is correspondingly adjusted based on the selected products purchase amount 58.

This combined product selection and shopping cart interface allows shopping and checking the total to occur on one consolidated interface, before proceeding to a checkout page 76. At anytime, if the shopper desires, shopping cart 14 may be emptied of any selected products by clicking on the empty cart button 34. This modification to the quantity column and the selected product display is shown in Figure 3 as a dashed line.

When the shopper is done shopping, the shopper clicks on the checkout button 22 to advance to the checkout page 76. If shopping cart 14 is not empty, server 6 will download to the shopper's browser a checkout page 76 for the shopper to fill out. If shopping cart 14 is empty, an error prompt will be displayed and the shopper will not be allowed to proceed to checkout page at 76.

When checking out at 76, the shopper fills out an order form, which includes contact information, and shipping method. The consumer may review, on this page, the products selected for purchase, the subtotal cost, applicable merchant defined state tax for his delivery address, applicable merchant defined shipping cost, and total amount to be paid. If the consumer desires to proceed with the purchase, he clicks the Submit This Shopping List button. The order form is sent to server 6 and an email of the order form is sent to the corresponding merchant and a confirmation email is forwarded to the consumer's email address previously provided in the order form.

An Order Confirmation Display 78 appears on the shopper's display screen indicating that the order form has be emailed to the consumer at the consumers e-mail address .

How the consumer concludes the transaction and pays is described below.

When finished with checking out, the consumer may return to shopping via search store interface 20 or product section list 16.

From consumer interface 10, the shopper may also click on the other aforementioned links to access various information. The e-commerce process and various options available to the consumer will be further discussed below, and in particular, in connection with the discussion regarding Figures 4, 19 and 20.

FIGURES 4 - 20

MERCHANT REGISTRATION. SITE START-UP AND SITE MAINTENANCE. AND CONSUMER SHOPPING AND PURCHASE PROCESSES

Figure 4 displays a flow diagram of an overview of merchant registration, site start-up and site maintenance, as well as the shopping and purchasing processes .

The merchant logs on to the Internet with merchant computer or terminal 8. The merchant then accesses the host site, by typing in an appropriate URL or clicking on a hypertext link, for registering with the host and setting up web site at 80. An example of a host site is INSTASITE or IS, (trademarks) , which is run by Shupe Chang Technologies, Inc. of Honolulu, Hawaii and which may be found on the Internet at http://www.Insta-site.com.

Instasite uses a Linux operating system and Perl based middle-ware called ABase to implement most web site interactivity. ABase serves as the interface between HTML web pages and the underlying database management system. Invoking ABase can come from a form submission or from a URL. It can use tab-delimited spreadsheets and mSQL (Mini SQL, which is provided by Hughes Technologies and is a light weight relational database management system) databases interchangeably. ABase can perform multiple database commands and generate multiple static documents with a single execution. Any similar program may be used or employed in the present invention, as there are many commercially available. Many of the functions and processes below refer to ABase functions. However, it is understood that other programs could perform the same or similar functions .

The merchant registration screen interface is displayed in Figure 5A. After accessing the registration page at 82, The merchant views registration display and fills in name address, and contact information at 84. He selects credit card type, and inputs number and expiration date at 86. The merchant inputs a preferred merchant folder name, login and password at 88. He then selects small, medium, or large store size at 90. The merchant selects text only, small or large icons at 92. The store site is how many products that can be included in the merchant site . The merchant may select to the have the host logo removed from his site at 94. The merchant views Monthly Payment based on selected service options at 96. The merchant clicks on PAY NOW button at 98 to submit his order to the credit card processor at 100.

The credit card processor processes the submitted credit card number. If disapproved, the merchant views disapproved transaction display at 102. If approved, the merchant views the card processor's approved transaction display at 104, and the merchant registration information is emailed on to the server On Deck Database at 106. The host then sets up a new merchant site at 108, as is discussed further below. The host server emails the merchant the new site address, maintenance interface address, Login name, and Password at 110. The merchant may then proceed to the maintenance interface 12 at 112.

While at the registration page, the merchant may also select a number of other miscellaneous options or links, such as: viewing the host logo at 726; viewing a registration page title at 728; selecting a site maintenance page link at 730; selecting a monthly charges page link at 732; selecting a general questions e-mail link at 734; selecting a technical questions e-mail link at 736; viewing a copyright notice at 738; viewing a service agreement at 740; viewing a disclaimer at 742; and, viewing trademark and copyright information at 744.

The process of setting up a new merchant site is displayed in Figure 5B. The registration information that was emailed to the server at 106 is what provokes the setting up a new merchant site.

When the server receives the registration information from the card processor, the host will perform manual and automated routines to copy relevant files and set up the merchant site. However, it is understood that all of the routines may be completed automatically by a computer.

A host administrator logs into the Add Merchant Area at 114, by supplying a login identification, a password and selecting a Add Merchant radial button.

All merchants that need to be added are stored in the on- deck database, onDeck.dbf. These merchants are displayed in a radial button list. When the administrator selects a merchant to add at 116, that merchant's registration information fills a merchant add form.

Administrator checks to see if the folder name the merchant requested is already taken at 118. If the requested merchant folder name is already taken the administrator supplies a new folder name not already taken at 120. The new name will be similar to the name requested by the merchant. This renaming process may also be done automatically by a computer routine.

If the folder name is not taken, the administrator clicks an Add Merchant button at 122. JavaScript checks 4 things before submitting the merchant:

1) folder name begins and ends with a ' / ' ; 2) password and password confirmation values are the same; 3) credit card number not empty; and, 4) expiration date not empty. If any one of the 4 checks fail, then an appropriate alert will be displayed. The merchant's registration information is added to the host merchant database, merchants .dbf, using ABase ' s add function ($function = add) at 124.

A maintenance structure file, abase. conf, is created and initialized at 126, with the merchant's folder name, store size, icon size, and INSTASITE Logo option. A storefront structure file, abase. conf, is created and initialized at 128, with the merchant's folder name, icon size, and INSTASITE Logo option. A password file, pass.dbf, is created at 130 and the login supplied by the merchant is placed in the password file. The encrypted value of the password supplied by the merchant is also placed in the password file. A login file, update.html, is created and initialized at 132, with the merchant's folder name, store size, icon size, and the host logo removal option. The following supporting files are copied at 134, from the server into the merchant's site folder: abase . stats .conf, abase.stats.html, astat.conf, products .dbf, re oveSection. conf , removeTemp . conf, search. conf, welcome.html, and welcomeFrameset .html . The merchant's registration information is removed from the on-deck database, onDeck.dbf, at 136, using ABase ' s delete function ($function = delete) . The administrator is returned to the add merchant page at 138. The radial button list of merchants to be added, no longer contains the merchant just added.

When the host finishes setting up the merchant's site, the host notifies the merchant via email that the merchant can access the merchant site and maintenance site at designated web addresses. From this notification to the merchant, the merchant will be able to access his merchant site or storefront (i.e. the consumer interface 10) and maintenance interface 12, bypassing this registration procedure, except in the event of cancellation. Merchant accesses the merchant site Maintenance Interface 12 after he receives his email notification from the host indicating that the site has been setup. Using merchant computer 8 and an network browser, the merchant types in the web site address for the Maintenance Interface site 12 at 140 (Figure 6) .

Figure 6 displays the Merchant Site Maintenance Interface Functions. However, before the maintenance functions can be utilized, the merchant must login at 142. The login page is the initial display when a merchant accesses the Merchant Site Maintenance Interface. The login process is displayed in Figure 7. At the login page, the merchant inputs his login name at 144 and password at 146. He may at this page click on which maintenance function he wishes to start using at 148. The merchant clicks the Enter button at 150 and proceeds to the selected page. After entering, the merchant is free to maneuver between the different functions, which will be described further below. The merchant while at the login page, may also click on the host logo at 152 to view a disclaimer page. The merchant may also view the page title at 154, the day of the week and date at 156 and the copyright notice at 158. The merchant site maintenance area is product based.

Instead of thinking about a site in terms of pages and links the merchant only needs to worry about their inventory of products . The present invention will automatically create and delete the appropriate pages based on this inventory of products. At any time, from any location, so long as the merchant has access to the Internet, he can submit his entries and data modifications to the host server.

Referring again to Figure 6, the merchant while at the merchant maintenance interface may perform many functions to edit and maintain the merchant site. The merchant can perform the following functions: add product at 160; edit product at 162; delete product at 164; modify the welcome page at 166; modify the merchant contact information at 168; modify the merchant applicable tax rate at 170; modify the merchant applicable shipping rates at 172; backup or upload the merchant database at 174; view site visitor statistics at 176; view help pages at 178; modify the consumer interface colors and text at 180; and, view modifications to the storefront at 182. The merchant may also click on the host logo at 184 to view a disclaimer page. The merchant may also view the page title at 186, the day of the week and date at 188 and the copyright notice at 190.

When the add product function is selected by the merchant at 160, the merchant advances to an add product interface page at 192, as shown in Figure 8A.

At this page, the merchant may create a new product section at 194. The merchant will then be prompted to input the name of a new product section. If an input section name does not yet exist, a new section will be created.

The merchant can select a product section at 196, via drop-down menu. The drop-down menu displays the first alphabetical listed section.

The merchant can input a new product name at 198 and a new product identification number at 200. The merchant can also input a product description at 202, input a product price at 204 and input a product Member Price, not shown, . The merchant can also input the new product icon path and file name at 206 to upload a product icon or an enlarged product image, not shown. The merchant can view the storefront at 208, based on most current data submitted to the server. The merchant can reset all input boxes and settings to original settings at 210.

The merchant can submit the new product information to the database on the server by selecting the Add Product option at

212. Figure 8B displays the process of adding a product. If the merchant clicks the Add Product button at 214, the new inputted information will be forwarded to the server at 216. Before submitting the form information, JavaScript checks the total number of products currently in the store. If the store is at its maximum number of allowable products, an alert will be displayed, such as: "Your database is currently at its maximum of [#] products. To add a new product you must either delete an existing product first or contact [the host ' s name] to upgrade your service."

If the total number of products is under the maximum allowed, a message is displayed, such as: "Adding [product name]..." and the product database, products .dbf, is updated using ABase ' s add function ($function = add) at 216. It is determined at 218 whether the new product has an icon.

This determination is based on whether the merchant previously selected to upload an icon. JavaScript checks the appropriate the Add Product form to make this determination. For the small to large icon services and or image that the merchant previously chose, uploading a graphic at 220 is optional. The ABase template upload.txt handles the upload. The file name is the product's ID number preceded by the letter 'p' with a gif extension. So if the product's ID number is FL0002 the file is named pFL0002.gif. If the merchant does not have an icon or an image for a product, it is displayed as text only. Also, for the text only service, version the answer to this is always no.

A confirmation display is created at 222. An ABase template creates the temporary display file, display.html.

Whenever a product is added, the maintenance structure file, abase. conf, must be updated at 224. This file contains all the section names as well as the number of products in each section. At 226, it must be determined if the section for the new product already exists. If the merchant previously checked the

'Select a section' radial button, then the answer to this is yes. If the merchant checked the 'Create a new section' radial button the answer to this is not necessarily no. The text typed into the new section input box at 194 (Fig. 8A) could be an existing section. Before submitting the form, a JavaScript For Loop checks this text against the existing sections. Only if a match is not found is the answer no.

If no, a new section must be created at 228. Say a product was just added into the Bar Soap section and that this is the first product to reside in the Bar Soap section, first Abase searches the product database for all products that have section = Bar Soap. The results of this search are then put into the newly created html file, Bar_Soap.html. Whenever a store's section information changes its storefront structure file, index.html, must be updated at 230. Because this file does not need the number of products in each section, it does not need updating if a product is added to an existing section.

If the answer at 226 is yes, the appropriate product section must be updated at 234. For example, say a product was just added to the Cereal section, first ABase searches the product database for all products that have section = Cereal. The results of this search are put into an html file, Cereal.html. This new file replaces the old Cereal.html file. After steps 230 and 232, a confirmation is displayed at 234.

The temporary display file (display.html) created at 222 is displayed. It shows what the newly created product will look like in the merchant's storefront.

Referring again to Figure 8A, the merchant can also select a different maintenance area function at 236, by drop-down menu, or edit the text, color, and graphics of the consumer interface at 238. Further, the merchant can also click on the host logo at 240 to view a disclaimer page. The merchant may also view the page title at 242, the day of the week and date at 244 and the copyright notice at 246.

When the edit product function is selected by the merchant at 162 (Fig. 6) , the merchant advances to an edit product interface page at 248, as shown in Figure 9A.

The merchant must find the product that needs to be edited at 250. The merchant selects the product by category by selecting the product's name section via this drop-down menu, or by inputting a product name to search for the product. If no product is found, a screen display notification will appear.

Once a product is found the merchant can select the product at 252. This selection is performed by clicking on the radial button next to the product that is to be edited. A display appears, based on the selected or default section, and what is currently in the merchant product database, per product section. The merchant can edit the product section at 254, by inputting the new text. Inputting a non-existent section will create a new section. The product name can be edited at 256.

The merchant can view the product ID number at 258, but not edit it.

The merchant can edit the product description at 260, edit the product price at 262 and edit the Member Price, not shown. The merchant can upload a product icon at 264 and upload a product image, not shown. The merchant can view the storefront at 266, based on most current data submitted to the server.

The merchant can submit the EDIT product information to the database at 268. Figure 9B displays the process of how a product edited.

The merchant clicks the edit product button at 270. Before submitting the edit product information, JavaScript displays the message, "Editing [product name]..." The product database, products .dbf, is updated at 272, using ABase ' s modify function ($function = modify) .

It is then determined at 274 whether the icon changes for the edited product. This determination is based on whether the merchant previously selected to upload an icon and/or an image . JavaScript checks the appropriate the Edit Product form to make this determination. If yes, then the new graphic must be uploaded at 276. The ABase template upload.txt handles the upload. The file name is the product's ID number preceded by the letter 'p' with a gif extension. So if the product's ID number is FL0002, the file is named pFL0002.gif. This new file overwrites the older graphic if the product previously had an icon. For the text only version the answer to step 274 is always no. For the small and large icon or image versions the merchant can upload a new icon or image for the product.

A confirmation display is created at 278. An ABase template creates the temporary display file, display.html. At 280, it is determined whether the product section for the edited product has been modified. This determination is made by Javascript, which checks whether the particular field on the edit product interface has been altered or modified and then issues appropriate instructions to ABase. Most of the time the edit page is used to make minor modifications, such as changing a product's price. In these cases the section is left unchanged. Editing a product's section should be thought of as moving that product out of its current section and into a new or existing section. If the section is not modified, the section must be updated at 282. For example, say the price of a product that resides in the Cereal section was just changed, first ABase searches the product database for all products that have section = Cereal. The results of this search are put into an html file, Cereal.html. This new file replaces the old Cereal.html file. If it is determined at 280 that the section has been modified, the maintenance structure file must be updated at 284. Whenever a product is moved, the maintenance structure file, abase. conf, must be updated. This file contains all the section names as well as the number of products in each section. In step 302, below, there is a similar file that is generally called the storefront structure file. This file contains all the section names but does not need the number of products in each section. The number of products is only relevant on the maintenance side because this number is used to determine when to remove a section.

It will be determined at 286 if the new section already exists. If the new section does not yet exist it must be created at 288. For example, say a product was just moved into the Bar Soap section and this is the first product to reside in the Bar Soap section, Abase will search the product database for all products that have section = Bar Soap. The results of this search are then put into a newly created html file, Bar_Soap . html .

If at 286 it is determined that the section already exists, then the section must be updated at 290. For example, say a product was just moved into the Beverages section and the Beverages section already exists, ABase will search the product database for all products that have section = Beverages. The results of this search are put into an html file, Beverages.html. This new file replaces the old Beverages.html file.

Whether a new section is created at 288 or a section is updated at 290, it will then be determined at 292 and 294, respectively, whether the edited product was the last product in the old section.

If the edited product was not the last product in the old section, then the old section needs to be updated or recreated at 296 and 298 without the edited product in it. For example, say a product was just moved out of the Cereal section and that there were two (2) or more products in the Cereal section, ABase will search the product database for all products that have section = Cereal. The results of this search are put into an html file, Cereal.html. This new file replaces the old Cereal.html file. If it is determined at 292 and 294 that the edited product was the last product in the old section, then the old section is now empty and will be removed at 300. A temporary ABase configuration file, remove. conf, is created. In this file it is indicated which section is to be removed. An ABase executable is then used to call remove . conf so that it can remove the appropriate file. If this was the default section, the section where the edited product now resides becomes the default section. The storefront structure file is updated at 302. Whenever a store's section information changes its storefront structure file, index.html, must be updated. Because this file does not need the number of products in each section there is one case when the maintenance structure file is updated in step 284, but the storefront structure is not. This is when a product is moved from an existing section to and existing section. The number of products in each section changes but the actual sections are unchanged.

Following steps 282, 298 and 302, described above, a confirmation is displayed at 304. The file created at 278 is displayed and it shows what the newly modified product will look like in the merchant's storefront.

Referring again to Figure 9A, the merchant can select a different maintenance area function at 306, by a drop-down menu, or edit the text, color, and graphics of the sales page via the Edit Interface at 308. Further, the merchant can also click on the host logo at 310 to view a disclaimer page. The merchant may also view the page title at 312, the day of the week and date at 314, and a copyright notice at 316. When the delete product function is selected by the merchant at 164 (Fig. 6) , the merchant advances to a delete product interface page at 318, as shown in Figure 10A.

The merchant finds the product he wishes to delete by category at 320, by selecting the product's name section via a drop-down menu. If the merchant makes no selection the interface will select a default section.

The merchant will then at 322, check a box next to the product the merchant wishes to delete. This displays what is currently in the merchant product database, per section selected. The merchant can view changes or current status of the consumer interface or storefront at 324, by clicking the view storefront hypertext. The merchant can clear all check box entries at 326, by clicking the Reset button. The merchant can submit Delete product information to the server at 328, by clicking on the Delete button. The process of deleting a product from the product database is displayed in Figure 10B, which begins with the merchant clicking the delete product button at 330. If the merchant has not checked any products to delete an alert will be displayed by JavaScript, such as: "Please check the products you wish to delete."

If a product has been selected for deletion, then the product database will be updated at 332. The product database, products. dbf, is updated using ABase 's delete function ($function = delete). The 'image' column of the database is designated as an Attach File Column so if the products deleted have icons they are automatically removed.

A confirmation display file is created at 334. An ABase template creates the temporary display file, display.html. Whenever a product is deleted, the maintenance structure file, abase. conf, must be updated at 336. This file contains all the section names as well as the number of products in each section. In step 342 below, there is a similar file that is generally called the storefront structure file. This file contains all the section names but does not need the number of products in each section. The number of products is only relevant on the maintenance side because this number is used to determine when to remove a section. It will be determined at 338, whether all products have been deleted from the deleted product's section. This is determined by comparing the number of products deleted to the total number of products in the section.

If all the products have been deleted for the section, then the section will be removed at 340. A temporary ABase configuration file, remove. conf, is created. In this file it is indicated which section is to be removed. An ABase executable is then used to call remove. conf so that it can remove the appropriate file. If this was the default section, the software will select a new default section by alphabetical order.

The storefront structure file will be updated at 342. Whenever a store ' s section information changes its storefront structure file, index.html, must be updated. Because this file does not need the number of products in each section, it only needs updating if a section is removed.

A confirmation will then be displayed at 344. The file created in step 334 is displayed. If a single product was deleted, display.html shows the message, "1 item deleted from the database." Otherwise display.html shows the message, " [#] items deleted from the database." This message is shown for 2 seconds. It will then be determined if there any products left in the store at 346. If the section just removed was the only one left, the store is now empty and the merchant will be forwarded at 348 to the Add Product Page discussed above. If there are products left in the store, the merchant will be forwarded at 350 to the delete product interface page for the section that appears first alphabetically. If it is determined at 338 that all the products were not deleted from the section, then the section must be updated at 352. For example, say two (2) of the Cereal section's 5 products were deleted. First Abase searches the product database for all products that have section = Cereal. The results of this search (the 3 products that remain) are put into an html file,

Cereal.html. This new file replaces the old Cereal.html file. A confirmation is displayed at 354. The file created in step 334 is displayed. If a single product was deleted, display.html shows the message, "1 item deleted from the database." Otherwise display.html shows the message, " [#] items deleted from the database." This message is shown for 2 seconds.

The merchant is then returned at 356 to the delete product page and the check box list of products shown no longer contains the products just deleted. Referring again to Figure 10A, the merchant can select a different maintenance area function at 358, by drop-down menu, or select the edit interface at 360 to edit the text, color, and graphics of the consumer interface. Further, the merchant can also click on the host logo at 362 to view a disclaimer page. The merchant may also view the page title at 364, the day of the week and date at 366 and a copyright notice at 368.

When the welcome page function is selected by the merchant at 166 (Fig. 6) , the merchant advances to a welcome page interface page at 370, as shown in Figure 11.

The merchant can input title text for the merchant's Welcome Page at 372. When the Welcome page is called up, the data currently on the server is displayed. The merchant can input text into the Welcome Body text input box at 374, to display on the Welcome page. The merchant can select which page to set as the default page to be first viewed when a shopper accesses the merchant site at 376, via a drop-down menu function. The merchant can also select the type of Welcome page to use, not shown; either a standard welcome page as described, or upload a custom programmed page, or link to an existing site.

The merchant can reset all entries by clicking the Reset button at 378. The merchant can submit the changes by clicking the Submit Changes button 380. Before submitting the changes, JavaScript checks to see if the Welcome Title input box at 372 was modified. If it was, the new Welcome Title is inserted into the Default Page drop down menu at 376, just in case it is also selected as the Default Page.

If the submit changes at 380 is selected, the welcome page for the storefront will be updated at 382. The ABase template welcome. tpl overwrites the old welcome.html file. This is the welcome page displayed in the merchant's storefront. Similarly, the welcome page for maintenance structure will be updated at 384. The ABase template welcomeFrameset . tpl overwrites the old welcorneFrameset.html file. This is the modify welcome page found in the site maintenance area. This page needs modification so that the next time the merchant wants to make changes the form contains the current welcome page information.

It is then determined at 386 if either the default page or the welcome title have been modified. JavaScript checks the values entered at 372 and 376 against the values from the maintenance structure file. If either have been modified, the storefront structure file will be updated at 388 and the maintenance structure file will be updated at 390. The storefront structure file, index.html, contains both the default page and welcome title. If either of these values change this file will be updated. The maintenance structure file, abase. conf, also contains both the default page and welcome title and if either of these values change this file will be updated. A confirmation will be displayed at 400, following the steps of 388 and 390, and 386. The new values for the default page, welcome title, and welcome body are displayed.

The merchant can select a different maintenance area function at 402, by a drop-down menu, or select the Edit Interface button at 402 to edit the text, color, and graphics of the consumer interface. The merchant can also select View Storefront at 406 to view the modifications to the consumer interface. Further, the merchant can also click on the host logo at 408 to view a disclaimer page. The merchant may also view the page title at 410, the day of the week and date at 412 and a copyright notice at 414.

When the Contact Information function is selected by the merchant at 168 (Fig. 6) , the merchant advances to a Maintenance Contact Info Interface Page at 416, as shown in Figure 12. The merchant can input at 418, any relevant information on how customers can contact the merchant . Only the master Login name and Password is allowed access to this interface. When first calling up this page, current data that has been submitted to the server appears in the input boxes. This data is retrieved from the merchant database [merchant . dbf] .

The merchant can view modifications to the merchant site by clicking view storefront at 420. The merchant can submit the changes by clicking the Submit button at 422 and data inputted above is submitted to the server. The INSTASITE or host merchant database, merchants .dbf, is updated at 424, using ABase ' s modify function ($function = modify) . Each record in the database has a password. The records are secured allowing only two people who can modify the merchant information record, namely the merchant (if he supplies the correct password) , and the host administrator.

A confirmation is displayed at 426. The confirmation display is identical to the previous page that appeared, except that 'Information Updated' in bold appears on the form, with the new in filled merchant data that has been submitted to the server. The form contains new contact information. If the merchant notices any errors, he can correct and resubmit the form at 428. Form data is resubmitted to the server.

The merchant can select a different maintenance area function at 430, by a drop-down menu, or select the Edit

Interface button at 4432 to edit the text, color, and graphics of the consumer interface. Further, the merchant can also click on the host logo at 434 to view a disclaimer page. The merchant may also view the page title at 436, the day of the week and date at 438 and a copyright notice at 440.

When the tax function is selected by the merchant at 170 (Fig. 6) , the merchant advances to a Maintenance Tax Interface Page at 442, as shown in Figure 13.

The merchant can input applicable Taxes per location to be applied to matching location purchase orders in the Tax Check Box and Text Input Box Array at 444. When the TAX page is called up, the data currently on the server is displayed. The merchant can check off all locations by clicking the Check All button at 446. The merchant can view modifications to the merchant site by clicking view storefront at 448. The merchant can clear all check boxes by clicking the Clear button at 450. The merchant can reset all entries by clicking the Reset button at 452. The merchant can submit the Tax rates by clicking the Submit

Rates button at 454. The tax info is stored in two JavaScript arrays, taxState and taxAmount . The taxState array contains two- character state abbreviations. Example: new array ("CA" , "HI" , "WA") . The taxAmount contains rates for each state. Example: new array (8.61, 4.16, 5.32); first rate goes with first state abbreviation (for example, tax for CA is 8.61%) . Before submission the JavaScript "for" loop checks all 51 check boxes. If checked, the value in rate box is tested to see if it is a number. If not, then JavaScript sends the alert 'Please enter a numeric value such as "4.16.". If it is a non-zero number, [if the number is 0 (zero) , then value is skipped] the two text strings that represent taxAmount and taxState are updated. For taxState string the software concatenates the two-character state abbreviation. For tax amount, the software concatenates the state tax amount .

The storefront structure file will be updated at 456, when submit rates is selected at 454. The storefront structure file, index.html, contains tax info so checkout can calculate correct total.

The maintenance structure file will also be updated at 458. The maintenance structure file, abase. conf, contains tax information so the Tax Page will displayed with current values, when it is next displayed.

A confirmation display, identical to the previous page appears at 460, except that 'Tax Rates Updated' in bold appears on the form, with in filled tax rates that have been submitted to the server. If the merchant notices any errors, he can correct and resubmit the form at 462. Form data is then resubmitted to the server.

The merchant can select a different maintenance area function at 464, by a drop-down menu, or select the Edit Interface button at 466 to edit the text, color, and graphics of the consumer interface. Further, the merchant can also click on the host logo at 468 to view a disclaimer page. The merchant may also view the page title at 470, the day of the week and date at 472 and a copyright notice at 474.

When the shipping function is selected by the merchant at 172 (Fig. 6) , the merchant advances to a maintenance shipping interface page at 476, as shown in Figure 14.

The merchant can input purchase amounts and their respective shipping rates per delivery method in the shipping input box array at 478. These rates will be correlated with purchaser shipping method selection, and purchase amount to arrive at a shipping cost for orders as applicable. When the shipping interface page is called up, the data currently on the server is displayed. When the merchant inputs purchase amounts, the first upper left hand box is always zero dollars. Amounts can be input into subsequent boxes. If a number is input in the right hand column, then the amount left hand column in the next row is automatically updated to $0.01 [one cent] more than the previous amount. If an amount in the left-hand column, is changed, then the amount in the right hand column in the previous row is automatically updated to $0.01 [one cent] less than the following amount.

The merchant can view modifications to the consumer interface by clicking view storefront at 480. The merchant can clear all input boxes by clicking the Clear button at 482. The merchant can reset all entries to the immediately current database setting by clicking the Reset button at 484.

The merchant can submit the Shipping rates by clicking the Submit button at 486. If the Submit button is clicked, the shipping information is stored in a multi-dimensional JavaScript array, called "shipping". Up to 5 levels of shipping service, up to 10 levels of product price ranges are allowed. Before submission, JavaScript compiles a string representing the multidimensional array. If a product price range entry is less than the previous entry, it is treated as the last row. If a shipping value is empty or not a number, it is treated as 0.00.

When the Submit button at 486 is clicked, the storefront structure file will be updated at 488. The storefront structure file, index.html, contains shipping information so Checkout can calculate a correct total. The maintenance structure file will also be updated at 490. The maintenance structure file, abase. conf, contains shipping information, so Shipping page will be displayed with current values, when it is next displayed. A confirmation display, identical to the previous page appears at 492, except that 'Shipping Updated' in bold appears on the form, with in filled merchant data that has been submitted to the server. If the merchant notices any errors, he can correct and resubmit the form at 494. The form data is then resubmitted to the server.

The merchant can select a different maintenance area function at 496, by a drop-down menu, or select the Edit Interface button at 498 to edit the text, color, and graphics of the consumer interface. Further, the merchant can also click on the host logo at 500 to view a disclaimer page. The merchant may also view the page title at 502, the day of the week and date at 504 and a copyright notice at 506.

When the backup restore function is selected by the merchant at 174 (Fig. 6) , the merchant advances to a maintenance backup/restore interface page at 508, as shown in Figure 15A.

The merchant can backup the merchant site database from the server to the merchant computer or terminal at 510. The merchant must then follow the instructions displayed on the interface. To backup the merchant site database, the merchant right clicks product database link (macintosh computer users click and hold) at 512. This will cause a pop up menu to appear. The merchant then selects "Save this Link as..." from the menu. A standard save file window appears. The merchant then inputs a filename and location for the file to go on the merchant computer, at 514. A copy of the product database will be downloaded to the merchant's computer at 516. After double-checking the merchant's password (the one provided when logging in) , ABase outputs the Product Database as a template ($template=products .dbf) . The merchant can restore and upload the merchant site database to the server from the merchant terminal at 518, if necessary or desired.

The merchant can clear all input boxes by clicking the Clear button at 520. The merchant can submit the merchant site database to be uploaded to the server by clicking the Submit button at 522.

Figure 15B displays a diagram for the uploading function. The merchant clicks the Submit button at 524. It is determined whether a new database is to be upload database at 526. If the merchant has selected a product database to upload, then the answer to this is yes. And if so, the product database will be uploaded at 528. The ABase template uploadDatabase.txt handles the upload. The file is named products .dbf . This new file overwrites the older database. If the answer at 526 is no and after uploading the product database at 528, section names will be retrieved at 530. ABase searches for all the different section names in the product database, products .dbf . These names are put into a temporary database, temp. dbf, for later use. The old section pages are removed at 532. ABase deletes the folder, 'section', which contains all the section pages. A confirmation display is created at 534. An ABase template creates a temporary display file, display.html. This is the file that will be used below. New section pages are created at 536. A page is created for each section name retrieved in step 530. The maintenance structure file will be updated at 538. The new site structure is put into the maintenance structure file, abase. conf. The storefront structure file will also be updated at 540. The new site structure is put into the storefront structure file, index. html .

The confirmation display created at 534 is displayed at 542. A list of each section along with the number of products in that section is displayed as confirmation.

Referring again to Figure 15A, the merchant can view modifications to the merchant ' s consumer interface site by clicking View Storefront at 544. The merchant can select a different maintenance area function at 546, by a drop-down menu, or select the Edit Interface button at 548 to edit the text, color, and graphics of the consumer interface .550 to view a disclaimer page. The merchant may also view the page title at 552, the day of the week and date at 554 and a copyright notice at 556. When the help function is selected by the merchant at 178

(Fig. 6) , or whether help function is selected anywhere else in the merchant interface, the merchant advances to a maintenance help interface page at 558, as shown in Figure 16.

The merchant can access Help pages per topic at 560. When the HELP page is called up, the default help page will refer to the last or current maintenance area page that the merchant viewed.

The merchant can select View Storefront at 562 to view the modifications to the consumer interface. The merchant can select a different maintenance area function at 564, by a drop-down menu, or select the Edit Interface button at 566 to edit the text, color, and graphics of the consumer interface. Further, the merchant can also click on the host logo at 568 to view a disclaimer page. The merchant may also view the page title at 570, the day of the week and date at 572 and a copyright notice at 574.

When the edit interface function is selected by the merchant at 180 (Fig. 6) , the merchant advances to a maintenance edit interface page at 576, as shown in Figure 17.

When any changes are initiated at the maintenance edit interface page, the changes are immediately displayed on the viewer's screen. When the viewer is satisfied with the changes, he can submit the changes to the server. The merchant can select a background color selector at 578 to set a desired background color for the consumer interface. The background color of the upper, left, and curved frames of the consumer interface can be modified by clicking on the desired color on the color bar. When the EDIT INTERFACE page is called up, the data currently on the server is displayed.

The merchant can select a text color RGB (red, green and blue) value box at 580 to set the text in the left and upper background areas of the consumer interface by changing the RGB color values in this color box. The merchant cannot at this point change the color of the title text and the host logo.

The merchant can click radial buttons to mix colors to set a resultant text color for the text in the left and upper background areas, except for the title text and the host logo, by clicking on text color mixer at 582. The merchant can select middle column color selector at 584, to set the merchant site middle bar (product section list) background color by clicking on the desired color on the color bar. The merchant can upload a banner graphic at 586. The merchant clicks the radial button and inputs, or browses to find, the path and file name for banner graphic to be uploaded to the server for the page title position.

The merchant can input a text only banner at 588. The merchant inputs the desired banner text on one or two lines and then clicks the size radial buttons to set the desired text size. The merchant can also set the title text color at 590, by changing the RGB (red, green and blue) color values in a color box. The merchant can also mix colors to set resultant color of the banner (title) text by clicking on a banner text color mixer at 592.

In order to exit this page, the merchant can close it as a window or go to another page .

The merchant can submit any changes to the server by clicking the Submit Interface Changes button at 594. JavaScript displays the message, "Changing Interface...", gathers information from the various frames and submits it from a single form to the server. It is determined at 596 whether a banner graphic needs to be uploaded based on the merchant submission. The answer to this is yes only if the 'Upload Banner Graphic' radial button is checked and the merchant has already selected a graphic to upload. If yes, a graphic will be uploaded to the server at 598. The ABase template uploadBanner.txt handles the upload. The file is named banner.gif. This new file overwrites the older graphic if the storefront previously had a banner graphic .

If the answer at 596 is no and after uploading a graphic at 598, the storefront structure file and the maintenance structure file will be updated at 600 and 602, respectively. The interface changes are put into the storefront structure file, index.html. The interface changes are put into the maintenance structure file, abase. conf.

The login page will also be updated at 604. The consumer interface changes are included in the login page, update.html, to provide a customized look.

A confirmation message, "Changes Complete", is displayed at 606. New interface is applied to the maintenance page banner. If the merchant upon viewing the confirmation finds errors, the merchant can make appropriate changes and submit the changes at 608. JavaScript again displays the message, "Changing Interface...", gathers information from the various frames and submits it from a single form to the server and the process is at 596 again. The merchant can click on the host logo at 610 to view a disclaimer page. The merchant may also view the page title at 612, the day of the week at 614, the current date at 616 and a copyright notice at 618.

When the view storefront function is selected by the merchant at 182 (Fig. 6) , or when it is selected anywhere else in the maintenance interface, the merchant advances to a maintenance view storefront interface page at 620, as shown in Figure 18.

The merchant can view modifications to the merchant site by clicking a Storefront Display button (hypertext) at 622. JavaScript checks to see if the storefront window is already open. If yes, then the window is brought to the front. If no, then a new window is launched. The consumer interface, or storefront, is displayed at 624. When the storefront is displayed, whatever was last edited will be shown. The

JavaScript variable lastChange records what was last modified.

For Add, Edit, and Delete functions, the lastChange variable records the section name of the entry last modified. For Welcome page editing functions, the lastChange variable records the welcome page as the determinant to show the Welcome page on the View Storefront display.

The maintenance functions all have confirmation pages. Within the confirmation pages a JavaScript variable lastChange is set. The lastChange variable holds the section, i.e., cereal [so that the cereal section will be displayed, as the last section that was edited], or holds the page name, i.e., Welcome page [so that the Welcome page will be displayed, as the last section that was edited] .

The merchant can click on the host logo at 626 to view a disclaimer page. The merchant can also view the page title at 628, the day of the week at 630, the current date at 632 and a copyright notice at 634.

After a merchant site has been created, as described above, a consumer or shopper may access the site via a network a merchant site or a merchant's consumer interface, at 636 as shown in Figure 19. Figure 19 displays an e-commerce process for a consumer when visiting a merchant ' s site that has been setup in accordance with the above. The following information regarding the consumer shopping process and consumer interface revisits as well as supplements the discussion provided above regarding consumer interface 10, as shown in Figure 2. Accordingly, Figure 19 is a further explanation and further embodiment of some of the functions available on consumer interface 10 as shown in Figure 2.

When a hosted merchant site is visited by a first time shopper/visitor, the server will post default HTML pages for viewing. These HTML pages will have been generated by the merchant ' s last editing of the database content of the pages via the Instasite Maintenance interface. If the shopper is returning to the site, and has saved one or more memorized shopping pages, the server will run CGI scripts to create the shopper's default shopping page with updated product pricing based on shopper- defined criteria contained Shopping Page Memory, discussed below. If the shopper is a Member registered on the merchant site database, and the Member has enabled username and password memory, the server will run CGI scripts to bypass the Member Logon interface and post Member Pricing product pages as defined in the Member Logon discussed below, and if enabled subject to Shopping Page Memory discussed below.

While at the consumer interface, the shopper can view the product display at 638. The shopper selects goods or services to be purchased via Product Display by clicking Buy buttons next to products to add the products in real time to the shopping cart, discussed below. Selecting products does not call or access the server. The function of adding products to the shopping cart and calculating the total cost of goods on the shopping cart occurs on the shopper ' s browser. If a shopper is registered as a member on the merchant site database, the shopper may call up the Member Pricing Logon interface at 640. Member pricing is not shown in Figure 2. The shopper can input a user name and password to access Member Pricing product pages. The Member shopper can click on a check box on the Logon interface to enable the server to remember the Member's user name and password for a period of time, sot that the Member does not have to call up the Member Pricing logon interface when the Member returns to the merchant site. If the Member enables this user name and password feature, the Member will see the Product Display with Member Pricing whenever the Member returns, until the period of time defined above expires. The Member can modify the period of time of the Logon memory, or disable the Logon memory whenever he wants to do so. When a Member logs on, the server is called and a CGI scripting routine is run to verify that the Member's input user name and password match with the user name and password registered on the server.

The shopper can also view the shopping cart at 642. As the shopper adds products and quantities to the shopping cart the consumer interface automatically tabulates the total cost of the list of goods in a box labeled Total, located below the shopping cart. The shopper may highlight product quantities to the left of the shopping cart and manually change them by changing the quantity number and clicking outside of the quantity box. The quantity box will automatically resize to accommodate the new quantity, and the interface will recalculate the shopping cart Total immediately. These cart functions occur in real time and do not call the server. When the shopper is ready to check out, he clicks the Checkout button, and the server is called to run a CGI script to create and post a Checkout page that shows the items listed for purchase on the shopping cart. This CGI script will also verify products and corresponding unit costs against product and cost listings registered by the merchant on the server.

The shopper can also view the product section display at 644. The shopper can click on product section names in the production section display and see products by section appear on the product display. When section names are clicked, the server is called to post corresponding HTML pages in the product display.

The shopper can view shopping page memory at 646. If a shopper has saved a shopping cart list of products and quantities as one or more Shopping Pages, the next time the shopper returns to the merchant site, the last Shopping Page he saved or a page that he has designated as his preferred default page will be displayed. If the shopper sets any Shopping Page to fill the shopping cart with quantities it will do so, otherwise, there will appear a Buy All button on the Shopping Page to allow him to click on to fill the shopping cart with previously memorized quantities. Shopping Pages set to fill the shopping cart will do so only if the shopping cart is empty, or else will provide a Buy All button to provide the cart-additive Shopping Page capability. Initially, a shopper shops on a merchant site without a host cookie on the shopper's web browser. The shopper can click on Save Shopping Page button/link to save a customized shopping page. The shopper may save one or multiple shopping pages that will appear in the Shopping Lists link 44, in the product section list 16. The shopper can define the products and quantity of products on the shopping page and display by text-only, icons and preferred sort method. Shopper may select a default shopping page to appear whenever the shopper returns to the merchant ' s site. If no default shopping page is selected by the shopper, the merchant selected default page will appear in the product display 18 and the shopping cart 14, will not automatically fill. The shopper can set a custom shopping page to automatically fill the shopping cart. Subsequent shopper pages if selected during the same shopping session will not automatically add to the shopping cart, but the shopper can click the Buy All and/or Buy buttons to add the products and memorized quantities of the shopping page to the shopping cart. The shopper can modify and save modifications to any memorized shopping page list, such as the selected products, quantities, auto-fill shopping cart or non-auto-fill cart option, the name for the memorized shopping list, and other settings such as text-only or icons. For shoppers who are members, as discussed above, auto- fill cart if enabled will not occur until after the member has logged in. The shopper search the merchant site at 648. To search, the shopper inputs a product name in the search area, clicks the go button, and views searched products that appear on the Product Display. The server is called and runs CGI scripts to generate Product Display pages. The shopper can view and select the product sort function at

650. The shopper sorts products by name, type, or price. The server is not called as the sorting is calculated locally on the shopper ' s computer . The shopper can select to view icon or text only Product Displays at 652. The server is not called as the icon or text formatting is calculated locally on the shopper's computer.

The shopper can click the Empty button to empty the shopping cart at 654. The server is not called as the Empty routine is calculated locally on the shopper's computer.

The shopper can enlarge the product images at 655. The shopper can click on an icon to view a pop-up enlarged product image, if the enlarged image is loaded on the merchant site database. The server is called to display a HTML page enlarged image .

The shopper views the total order amount at 656. The server is not called as the Total routine is calculated in real time locally on the shopper's computer as products and or quantities are added or reduced on the shopping cart.

The shopper can click on the Checkout button at 658 to advance to Checkout Page 76. If the merchant site credit card feature is enabled, then the Checkout Page will be secure. The server will be called and display a HTML page if a non-Member checks out. The server will be called and run CGI scripts to generate a display if a Member checks out.

When the shopper is ready, he clicks on the Checkout Button to go to access the Checkout Page at 660. If the shopping cart is empty, an error prompt appears and the shopper does not access the checkout page.

Accessing checkout page 76 and the checkout interface functions are displayed in Figure 20. The shopper access the checkout page at 662, as described above. At checkout page 76, the shopper views the checkout display at 664 and fills out the order form, which includes contact information, and payment method. The interface registers this information without calling the server.

The shopper selects shipping method at 666. The interface registers this information without calling the server.

The shopper reviews his shopping list at 668. The shopper reviews the Subtotal cost at 670. The shopper can view the tax being applied to the order at 672. Applicable merchant defined Tax to his delivery address state is displayed. The server is not called as this is calculated real time on the shopper's computer, based on merchant provided State Tax rates loaded onto the Checkout Page interface.

The shopper can also view applicable merchant defined shipping cost at 674. The shipping cost information is displayed based on shopper selected Shipping Method. The server is not called as this is calculated real time on the shopper's computer, based on merchant provided Shipping rates loaded onto the Checkout Page interface .

The shopper views the Total Order Amount at 676. The server is not called as this is calculated real time on the shopper's computer.

If the shopper is ready to make the purchase, the shopper clicks the Submit This Shopping List button at 678. The order form is sent to the server. The server runs CGI scripts to compare and verify line items and unit costs on the Shopping List against the server resident line item and cost data prior to completing the order. If the product line items and or unit costs do not match with the server resident merchant product and cost data, the transaction will be denied and the shopper asked to input the correct product data or contact the merchant directly with his order.

Upon submission of the order, a merchant definable Order Confirmation Display appears on the shopper's screen at 680. The confirmation states: "Your order form has been e-mailed to you at [shopper email address] . Please print out this order form and mail it along with your check to: [merchant's address] ." The server sends the order form to the shopper and merchant via email. From receipt of the emailed order forms, the shopper and merchant can communicate to finish the transaction.

Alternatively, the merchant can enable PGP encrypted email of credit card number to the merchant by the shopper. Additionally, the merchant can enable the interface to process credit card transactions online. The shopper can return to shopping via the Search Store interface at 682. The server will run CGI scripts to generate a searched Product Display. The shopper can also click on a Product Section name at 684, and see products by section appear on the Product Display. The server is called to display a HTML page .

The shopper can click on links to see the Intro/Help page at 686, or Welcome page at 688. Other supporting functions include viewing the host logo at 690, viewing the disclaimer page at 692, viewing the Page Title at 694, the day at 696 and the date at 698. The shopper can also view the user agreement at 700, the copyright notice at 702 and trademark notices at 704.

Referring to Figure 19 again, and similar to the options available to the shopper at the checkout page, the shopper can at the consumer interface, click on links to see the Intro/Help page at 706, or Welcome page at 708. Other supporting functions include viewing the host logo at 710, viewing the disclaimer page at 712, viewing the Page Title at 714, the day at 716 and the date at 718. The shopper can also view the user agreement at 720, the copyright notice at 722 and trademark notices at 724.

Set forth below is Chart 1, which displays various shopping interface functions and the corresponding server call type, if any. Chart 1.

The software programs to carry the invention may be fixed in any computer readable medium, such as but not limited to CD-Rom, Cd-R/W, magnetic tapes, floppy discs, resident memory modules, hard drives, etc.

While this invention has been described as having a preferred design, it is understood that it is capable of further modification, uses and/or adaptations following in general the principles of the invention and including such departures from the present disclosure as come within known or customary practice in the art to which the invention pertains, and as may be applied to the essential features set forth, and fall within the scope of the invention or the limits of the appended claims .

Claims

What is claimed is:

1. A method of providing a consumer purchasing interface, comprising : a. displaying on a client side computer terminal in a single window, a shopping cart, a product category list, an available products display and a checkout button; b. for each product selection by a consumer via an input device of said client side computer terminal, storing said selection in said shopping cart; c . for each product removal by the consumer with said input device, removing said product selection from said shopping cart; d. for each product removal and product selection by the consumer with said input device, calculating a subtotal purchase amount; e. for each product category change requested by the consumer with said input device, displaying in said available pro a corresponding available product display for the selected category in said available products display; and, f . transferring product selections to a server via a network, pursuant to the consumers selection of said checkout via said input device.

2. A consumer interface presentation method for interaction with a consumer in an e-commerce shopping system provided with a server having a merchant consumer interface web site, a production section list and a product description data, a consumer terminal having a display device and being operated by the consumer, and a network connecting the server and the consumer terminal, comprising: a. downloading the merchant consumer interface web site, the product section list and the product data to the consumer terminal; b. displaying in a window on the display device of the consumer terminal the merchant consumer interface web site; c. displaying a shopping cart display, a product section list and a product display area in the merchant consumer interface web site; d. displaying the product data within said product display area; e. displaying the product section data within said product section list; and, f . displaying in the shopping cart display any products selected by the consumer from interaction with said product display area.

3. A method of viewing and placing orders for products and services over a network, comprising: a. on a client computer system: i. displaying in a single window on a display device, a plurality of available products, available product sections, a shopping cart and a checkout button; ii . recording product selections for order, pursuant to a selection of one of said plurality of available products by a client. iii. totaling the cost of all selected products recorded for order; iv. sending an order submission to a server system, pursuant to a selection of a checkout button by the client; and, b. on a server system connected to said client computer system via a network: i. receiving the submission from said sending an order submission step; ii . generating an order form from said submission from said sending an order submission step; and, iii . forwarding said order form to a merchant and the client.

4. An e-commerce shopping system comprising: a. a network b. a server being connected to said network, and having a consumer shopping interface including a shopping cart, available product data, a product category list and a checkout; and, c . a consumer terminal connected to said network and including a display device for displaying said consumer shopping interface and an input device for selecting products from said available product data by a consumer, whereby the consumer may select said checkout to submit said selected products to said server via said network.

5. A computer-readable medium containing instructions for controlling a computer system to create a merchant consumer interface web site from a merchant registration form having a merchant requested folder name, by: a. retrieving a list of new merchants to add; b. for each merchant in said list of new merchants to add, i. determining if the merchant requested folder name is available by comparing the merchant requested folder name to merchant folder names database; ii. creating a new merchant folder name if the merchant requested folder name is not available; iii . adding merchant folder name to said merchant folder names database to create a merchant folder; iv. creating a site maintenance structure file; v. creating a storefront structure file; vi. creating a password file; vii. creating a login file; viii. copying site supporting files from a first memory location to said merchant folder; and, ix. removing merchant from said list of new merchants to add.