METHOD FOR PROVIDING AUTOMATIC DISPLAY OF PRIOR ORDER
HISTORY OVER A COMPUTER NETWORK
CROSS REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of provisional patent application Serial No. 60/173,798 filed December 30, 1999, the disclosure of which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
The present invention relates generally to conducting electronic commercial transactions over a computer network. More particularly, the present invention relates to automatically displaying a prior order history to a customer over the network.
Electronic commerce systems for conducting commercial transactions over a distributed computer network, such as the Internet, are shown and described in numerous U.S. Patents, including U.S. Patents 5,285,383 and 5,063,507 to Lindsey et al., U.S.
Patent 5,963,915 to Kirsch et al., U.S. Patent 5,319,542 to King, Jr. et al., and U.S. Patent 5,774,873 to Berent et al.
U.S. Patent 5,319,542 to King, Jr. et al., for example, discloses a system for ordering items from a supplier. The system includes an electronic catalogue and an electronic requisition facility. The catalogue includes a public-access portion, stored on a publicly-accessible database for access by customers, and a private portion, stored on a customer's computer system. The private portion contains unique pricing data based on pricing agreements. Customers use the electronic requisition facility to create purchase requisitions based on the information in the electronic catalogue. The requisi- tions are routed through an appropriate approval process, processed through the customer's procurement system, and transmitted to the supplier.
Electronic commercial transactions such as those described in King, Jr. et al. commonly take place over the World Wide Web. The World Wide Web is a collection of servers connected to the Internet that utilize the Hypertext Transfer Protocol ("HTTP"). This protocol permits documents (commonly referred to as web pages) written in a standard mark-up language (e.g., html) to be transmitted across the Internet from remote server computers to client computers, even where such remote and client computers share different operating systems or platforms. A browser application running on the client computer then translates the commonly formatted documents and displays them to the user.
Although the Internet is an "open" network accessible to the general public, individual web site owners may wish to restrict access to their web sites or portions thereof to those previously authorized for entry. This permits businesses to clearly identify users of the site and tQ conduct confidential transactions or discussions over the Internet. Site access restrictions also allow web site owners to track usage of their site in order to match page visitation with particular users.
One common method of restricting access for the purposes of e-commerce is to require users of the site to register themselves with the web site prior to full entry into the site. This commonly entails submitting an amount of personal information to the site in exchange for access to the site's contents. This information could be as mini- mal as a name and electronic mail ("e-mail") address, or as detailed as the user's home address, credit card numbers, and detailed information regarding personal interests and activities. A registered user is often given a username and password that they may enter upon each return visit to the site. The user then "logs in" to the site using the username and password.
A supplement to the "login" method of restricting access is utilization of
"cookies". Cookies, as described below, may be implemented to eliminate the need for the user to re-enter their login (or additional) information each time the user requests access to the site. As disclosed in U.S. Patent No. 5,999,971 to Buckland, a web site (a series of related web pages) can be customized to a specific user of a client computer when information about that user is available to the site. For example, if a
web site has access to a record indicating that a user is a sports fan (e.g., from the user's registration information), then the site may be specially configured to display a sports advertisement whenever that user accesses the site. Such functionality can encourage sports sponsors for the web site, consequently increasing site revenue.
To that end, the World Wide Web utilizes "cookies" to provide user information to a web site. As is known in the art, a cookie is a data block that is transmitted to a client browser by a web site, either upon user registration or at various times during site navigation. Upon receipt, the browser stores the cookie in a given manner such as, for example, in a text file called "cookie.txt." The cookie is transmitted back to the web site each time the browser requests access to a web page from the web site.
Among other things, cookies commonly include data identifying the user requesting access. When used in this manner, such data may be utilized to access a database at the web site to ascertain relatively large quantities of data about the user.
In one example of the use of cookies in electronic commerce, U.S. Patent 5,963,915 to Kirsch et al. discloses a system and method for performing Internet transactions between a client browser and a merchant server. The method includes establishing a cookie on the browser which corresponds to an account record stored on the server; providing a web page including a Uniform Resource Locator ("URL") identifying an item for sale to the browser; receiving the URL, with a reference to the cookie, at the merchant server; validating the cookie; and recording the identity of the corresponding item by the merchant server. The method is intended to avoid redundant user input, to provide for secure transactions, and to increase transaction efficiencies.
Although the use of access restrictions and cookies are known in the realm of electronic commerce, particularly in the retail environment, the needs of the business to business customers have not adequately been met in this respect. Focusing on the realm of bulk material purchases, it is common for buyers to repeat identical or substantially identical orders for materials time and time again. Often, these orders include lengthy product numbers or nondescript titles requiring precise entry into the order form. There remains a clear need for increased web site customization for pur-
chasers of bulk materials, such as chemicals, in order to increase the efficiency and accuracy with which such purchases are made.
BRIEF SUMMARY OF THE INVENTION
The present invention overcomes the problems noted above, and provides additional advantages, by providing a method and system for providing to commercial web site users a listing of prior submitted orders, automatically upon entry to the commercial web site. A method in accordance with an exemplary embodiment of the invention is performed by providing, through a web site on the World Wide Web, a means for identifying a user to the web site server. Upon identification of the user, the web site automatically provides an interface displaying to the user a listing of all previously submitted orders. The interface permits the user to examine and/or modify prior orders and to present the modified orders to the web site as a new order.
Methods, systems and programs in accordance with the present invention greatly increase the efficiency and convenience of ordering bulk materials, such as chemicals, over a computer network, by reducing re-entry of order information, thus reducing order placing time and the likelihood of ordering error through miskeyed entries.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention can be understood more completely by reading the following Detailed Description of exemplary embodiments, in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram of a computer network suitable for implementing a method according to the present invention;
FIG. 2 is a flow chart describing a first method for identifying a client associated with the purchaser to a server associated with the supplier over the computer network of FIG. 1;
FIG. 3 is a flow chart describing a second method for identifying a client associated with the purchaser to a server associated with the supplier over the computer network of FIG. 1; and
FIG. 4 is a flow chart describing a method for automatically displaying the prior order history of an identified customer over the computer network of FIG. 1.
DETAILED DESCRIPTION OF THE INVENTION
A computer system 10 connected to a computer network such as the Internet is generally illustrated in FIG. 1. A conventional client computer system 12 (hereinafter "client") owner by a customer, executes a client browser application that supports the HTTP protocol, (e.g., Internet Explorer™, available from Microsoft Corporation). The client 12 is typically connected through an Internet Service Provider (ISP) to the
Internet 14. A supplier owned server computer system 16 (hereinafter "server") is also coupled typically through an Internet Service Provider to the Internet 14. The server 16, controlled by a local console 18, executes a web server application and also hosts at least one web page for distribution over the Internet.
The client 12 requests a web page by issuing a URL request through the Internet 14 to the server system 16. A URL consistent with the present invention may be a simple URL of the form:
<protocol_identifier>://<server_path>/<web_page_path>
A " protocol_identifier" of "http" specifies the conventional hyper-text transfer proto- col. A URL request for a secure Internet transaction typically utilizes the secure protocol identifier "https," assuming that the client browser and web server are presumed to support and implement the secure sockets layer (SSL). The "server_path" is typically of the form "prefix.domain," where the prefix is typically "www" to designate a web server and the "domain" is the standard Internet sub-domain. top-level-domain of the server 16. The optional "web_page_path" is provided to specifically identify a particular hyper-text page maintained by the web server.
In response to a received URL identifying an existing web page, the server 16 returns the web page, subject to the HTTP protocol, to the client 12. This web page typically incorporates both textural and graphical information including embedded hyper-text links (hereinafter "hyperlink") that permit the client user to readily select a next URL for issuance to the Internet 14.
The URL issued from the client 12 may also be of a complex form that identifies a common gateway interface (CGI) program on server 16. Such a HTML hyperlink reference is typically of the form:
<form action="http://www.vendor.com/cgi-bin/logon.cgi" method=post>
A hyperlink of this form directs the execution of the logon.cgi program on an HTTP server in response to a client side selection of a hyperlink. A logon form supported by a logon CGI program is typically used to obtain a client user login name and password to initiate an authenticated session between the client browser and Web server for purposes of supporting, for example, a secure purchase transaction.
Referring now to FIG. 2, there is illustrated a flow chart describing a first method for identifying a client associated with the purchaser to a server associated with the supplier over a computer network (e.g., as shown and described above). This method can be implemented by a software program resident in one or more servers associated with the supplier. In step 200, the server 14 receives a request by the client 12 to ac- cess the web site.
Once the request is received by the server 14, the process continues to step 202 in which the server 14 interacts with the client 12, in a conventional manner, to determine if the client 12 possesses a cookie received from server 14 during a prior visit to the site. As is known in the art, the client 12 may posses the cookie if that cli- ent 12 had accessed the site at some earlier time and the site had transmitted (a/k a
"dropped") a cookie to the client 12 for subsequent retrieval by the server 14.
If, at step 202, it is determined that the client 12 includes a cookie, then the process continues to step 204 in which a client identifier is extracted from the cookie. The client identifier may be any indicia, character string, or other identifying data that uniquely identifies the client 12 to the server 14. Based upon the client identifier, information may be ascertained about the client 12 from a database in step 206 (discussed in greater detail below with reference to step 218).
If, however, it was determined at step 202 that the client did not posses a cookie, then the process continues to step 208 in which the client is redirected (also referred to as "relocated") to a login/registration page, where, in step 210, it is determined whether the customer is a returning customer or a new customer. If the cus- tomer had previously registered with the supplier, a username and password are entered in step 211 to allow entrance into the site. If the customer is new to the site, information is submitted in step 212, typically via a conventional template that is generated with common gateway interface scripts ("CGI scripts"). In exchange, a username and password are generated in step 213 which enable access to the site. For example, the user of the client may complete fields of a form requesting the user's name, address, billing address, shipping address, etc. Information retrieved in this manner is be stored, in step 214, in a database created to store information about the customer.
Regardless of whether a prior username and password had been obtained or whether a new username and password were registered, a cookie is dropped, in accord with conventional practices, onto the client in step 216, to facilitate expedited access to the site upon future visits. The cookie preferably includes at least a client identifier, uniquely identifying the client to the server. Further, in step 218 a plurality of client records may be initialized in the database for retrieval upon receipt of the appropriate client identifier. These records preferably include site preferences, customer information (e.g., the information obtained during registration), as well as a detailed history of all prior orders placed by the customer with the supplier.
The process then continues to step 204 (discussed above), in which the client identifier is extracted from the cookie. The server, in step 206, then accesses the information in the database associated with the client identifier. The process continues to step 220 in which information about the client is shared between the database and the server. The process then continues to step 222 in which the client is permitted access to the site.
Referring now to FIG. 3, there is illustrated a flow chart describing an alternative method for identifying the client 12, associated with the purchaser, to the server 14, associated with the supplier. As with the method described above, this method can be
implemented by a software program resident in one or more servers associated with the supplier. In step 300, the server 14 receives a request by the client 12 to access the web site at the site's login/registration page.
The process continues to step 302 in which the server 14 determines whether the cus- tomer is a repeat customer or a first time user. If the customer had previously registered with the supplier, a username and password are entered in a suitable form in step
303. After determining whether the username and password are valid in step 305, the server accesses the database for the associated customer information in step 306. This information is shared between the server and the database in step 308 and the cus- tomer is permitted access to the site in step 310. However, if the customer is new to the site, information is submitted by the customer and received by the server in step 312, typically via a conventional template similar to that described in step 212 above. For example, the customer may complete fields of a form requesting the user's name, address, billing address, shipping address, etc. The server then generates a username and password in step 314 and stores the registration information in the database in step 316 associated with the customer's client application. Also, several customer records in the database are initialized. The database is also configured to preferably include site preferences, customer information (e.g., the information obtained during registration), as well as a detailed history of all orders placed by the customer with the supplier. Preferably, the detailed history includes information on all orders placed with the supplier including: electronic orders, telephone orders, facsimile orders, and written orders. Upon receipt of a properly submitted form, the process returns to step
304, where the customer enters the newly generated username and password and gains access to the site in step 310. If, for some reason, the customer enters an invalid username or password, the site displays an appropriate error message at step 306 and asks the customer to resubmit a valid username and password at step 304.
Referring now to FIG. 4, there is illustrated a flow chart describing a method for automatically displaying the prior order history of an identified customer. Once the server has positively determined the identity of a customer through one of the two methods described in FIGS. 2 and 3 above, the customer is provided access to the web site in step 400. The server, in step 402, accesses the information in the customer in-
formation database corresponding to the particular customer and, in step 404, displays a listing of all prior orders (electronic or otherwise) to the customer. Preferably, this prior order history display initially includes a brief description of each particular order including at least the order date, and the order number, as well as a hyperlink linking the initial general display to an order details web page, particular for each order.
Upon selecting a particular past order, the server displays, in step 406, the order details web page including a more detailed description of the various components of the particular order.
Preferably, in describing the specific details of a particular order, the server, in step 408 determines whether any materials included in the prior order are currently out of stock or discontinued (i.e., no longer produced). At step 410, the server flags the out of stock or discontinued items. This is preferably done through the use of graphical icons or color schemes, the implementation of which are well known in the art. Also, the server may display additional information regarding the out of stock item, for ex- ample, it's restocking date, or suitable alternatives or replacements. By providing the customer with indications regarding out of stock or discontinued items, the customer is placed in a better position regarding future orders. Also, preferably, the past order history display also includes a product/site searching tool which enables customers to search, at step 412, for additional products or materials.
The order details page also serves as a new order entry page which includes, as order information, all information present in the selected prior order. By simply selecting a past order, the customer can choose to resubmit a duplicate order at step 414. This works very well for a large number of bulk material purchases and eliminates errors caused by miskeying of order information. At step 416, the server determines whether any items in the resubmitted order are out of stock or discontinued. If not, the order is received by the server at step 418 and processed in a suitable manner, described in detail below. If items in the resubmitted order are out of stock or discontinued, a message indicating this is displayed to the customer at step 420 and the customer is returned to the order details page.
The customer may also choose to modify the past order is various respects and substitute a new modified order in step 422. The modified order is checked for out of stock or discontinued items in step 424 and, if none exist, the order is received at step 426 and processed in a suitable manner, described in detail below. If out of stock or discontinued items are include in the order, a suitable error message is displayed and the customer is returned to the modified order entry page.
Following reception of a submitted order, the sever, at step 428, examines an inventory database to determine an estimated delivery date for the ordered item(s). In step 430, a list of potential delivery dates or times is determined for the ordered item(s).
In step 432, the server determines whether an off list price (OLP), or discounted price, is available for the ordered item(s). If such an alternative price exists, the process continues to step 434, where the customer or user is requested to identify the end user of the product on whose behalf the user is purchasing the product. In step 436, whether or not the customer or user can identify an end user for which the product or item is intended determines whether the OLP, or some other price, will be applied. If a specific end user is identified, the process continues to determine a price and/or price bracket as will be described in more detail below. If the purchaser is not ordering the item(s) on behalf of some other end user, the process continues to step 438, where it is determined whether a customer price list (CPL) exists for the ordered item(s). If such a CPL exists, the process jumps to step 446, where a unit price and price breakdown are determined in a manner to be described below.
If such a CPL is determined not to exist in step 438, then the process continues to step 440, where it is determined whether a list price exists. If a list price exists, it is determined whether that list price is equal to a predetermined default value representing an insufficient order quantity (in this example, $99.99) in step 442. If a list price is found not to exist in step 440, or if the list price is found to be a default value, step 444 will cause the customer to be informed that there is no price found for the product, and the process will end. If a list price is found to exist, and the list price is not a default value, or if the customer is purchasing a product on behalf of another user, the process continues to step 446, where a unit price and price bracket are determined.
In step 448, the customer is presented with a "shopping cart" page which displays all the information entered during the ordering process for each non-finalized order. In step 450, the customer submits the shopping cart to the supplier. In response to this submission, in step 452, the pricing, inventory availability, and delivery date are cal- culated, and in step 454, the customer is presented with an order summary.
In step 456, it is determined whether an order confirmation number is available for the customer's order. If such a number is available, it is provided to the customer in step 458 (e.g., by automatically causing an electronic mail message to be sent), and if such a number is not available due to the presence of order exceptions, the order exceptions are resolved in step 460, and the number is provided to the customer at a later time.
It should be understood that the network of FIG. 1 and the order processing method described above are merely exemplary models used to illustrate the environment in which the present invention may be used. The present invention may be used with any suitable network or electronic commerce method and should not be limited to those described above.
While the foregoing description includes many details and specificities, it is to be understood that these have been included for purposes of explanation only, and are not to be interpreted as limitations of the present invention. Many modifications to the embodiments described above can be made without departing from the spirit and scope of the invention, as is intended to be encompassed by the following claims and their legal equivalents.