WO2001046847A9

WO2001046847A9 - Placing a purchase order using one of multiple procurement options

Info

Publication number: WO2001046847A9
Application number: PCT/US2000/035484
Authority: WO
Inventors: William Allocca; Jordan Hay; Jonathan A Leblang; Colleen Mcqueen; James Prudente
Original assignee: Amazon Com Inc
Priority date: 1999-12-23
Filing date: 2000-12-21
Publication date: 2002-06-27
Also published as: EP1247202A2; US20100185532A1; US9092817B2; US20070061222A1; US9953361B1; WO2001046847A2; AU2604901A; US7720712B1; US8543462B2; US20140025541A1

Description

PLACING A PURCHASE ORDER USING ONE OF MULTIPLE PROCUREMENT OPTIONS

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional U.S. Patent Application No. 60/171,947, filed December 23, 1999, and of U.S. Patent Application No. 60/190,264, filed March 17, 2000, each of which are hereby incorporated by reference.

TECHNICAL FIELD

The present invention relates to a computer method and system for placing an order and, more particularly, to a method and system for ordering items over the Intemet.

BACKGROUND

The Internet comprises a vast number of computers and computer networks that are interconnected through communication links. The interconnected computers exchange information using various services, such as electronic mail, Gopher, and the World Wide Web ("WWW"). The WWW service allows a server computer system (i.e., Web server or Web site) to send graphical Web pages of information to a remote client computer system. The remote client computer system can then display the Web pages. Each resource (e.g., computer or Web page) of the WWW is uniquely identifiable by a Uniform Resource Locator ("URL"). To view a specific Web page, a client computer system specifies the URL for that Web page in a request (e.g., a HyperText Transfer Protocol ("HTTP") request). The request is forwarded to the Web server that supports that Web page. When that Web server receives the request, it sends that Web page to the client computer system. When the client computer system receives that Web page, it typically displays the Web page using a browser. A browser is a special- purpose application program that effects the requesting of Web pages and the displaying of Web pages.

Currently, Web pages are typically defined using HyperText Markup Language ("HTML"). HTML provides a standard set of tags that define how a Web page is to be displayed. When a user indicates to the browser to display a Web page, the browser sends a request to the server computer system to transfer to the client computer system an HTML document that defines the Web page. When the requested HTML document is received by the client computer system, the browser displays the Web page as defined by the HTML document. The HTML document contains various tags that control the displaying of text, graphics, controls, and other features. The HTML document may contain URLs of other Web pages available on that server computer system or other server computer systems. The World Wide Web' is especially conducive to conducting electronic commerce. Many Web servers have been developed through which vendors can advertise and sell product. The products can include items (e.g., music) that are delivered electronically to the purchaser over the Internet and items (e.g., books) that are delivered through conventional distribution channels (e.g., a common carrier). A server computer system may provide an electronic version of a catalog that lists the items that are available. A user, who is a potential purchaser, may browse through the catalog using a browser and select various items that are to be purchased. When the user has completed selecting the items to be purchased, the server computer system then prompts the user for information to complete the ordering of the items. This purchaser-specific order information may include the purchaser's name, the purchaser's credit card number, and a shipping address for the order. The server computer system then typically confirms the order by sending a confirming Web page to the client computer system and schedules shipment of the items. Since the purchaser-specific order information contains sensitive information (e.g., a credit card number), both vendors and purchasers want to ensure the security of such information. Security is a concern because information transmitted over the Internet may pass through various intermediate computer systems on its way to its final destination. The information could be intercepted by an unscrupulous person at an intermediate system. To help ensure the security of the sensitive information, various encryption techniques are used when transntitting such information between a client computer system and a server computer system. Even though such encrypted information can be intercepted, because the information is encrypted, it is generally useless to the interceptor. Nevertheless, there is always a possibility that such sensitive information may be successfully decrypted by the interceptor. Therefore, it would be desirable to minimize the sensitive information transmitted when placing an order.

The selection of the various items from the electronic catalogs is generally based on the "shopping cart" model. When the purchaser selects an item from the electronic catalog, the server computer system metaphorically adds that item to a shopping cart. When the purchaser is done selecting items, then all the items in the shopping cart are "checked out" (i.e., ordered) when the purchaser provides billing and shipment information. In some models, when a purchaser selects any one item, then that item is "checked out" by automatically prompting the user for the billing and shipment information. Although the shopping cart model is very flexible and mtuitive, it has a downside in that it requires many interactions by the purchaser. For example, the purchaser selects the various items from the electronic catalog, and then indicates that the selection is complete. The purchaser is then presented with an order Web page that prompts the purchaser for the purchaser-specific order information to complete the order. That Web page may be prefilled with information that was provided by the purchaser when placing another order. The information is then validated by the server computer system, and the order is completed. Such an ordering model can be problematic for a couple of reasons. If a purchaser is ordering only one item, then the overhead of confirming the various steps of the ordering process and waiting for, viewing, and updating the purchaser- specific order information can be much more than the overhead of selecting the item itself. This overhead makes the purchase of a single item cumbersome. Also, with such an ordering model, each time an order is placed sensitive information is transmitted over the Internet. Each time the sensitive information is transmitted over the Internet, it is susceptible to being intercepted and decrypted.

BRIEF DESCRIPTION OF THE DRAWINGS

Figures 1A-1C illustrate an embodiment of single-action ordering. Figure 2 is a block diagram _illustrating an embodiment of a system that supports single-action ordering.

Figure 3 is a flow diagram of an embodiment of a routine that enables single-action ordering for a customer.

Figure 4 is a flow diagram of an embodiment of a routine to generate a Web page in which single-action ordering is enabled.

Figure 5 is a flow diagram of an embodiment of a routine which processes a single-action order.

Figure 6 is a flow diagram of an embodiment of a routine for generating a single-action order summary Web page. Figure 7 is a flow diagram of an embodiment of a routine that implements an expedited order selection algorithm.

Figures 8A-8C illustrate a hierarchical data entry mechanism in one embodiment. Figures 9A-9B illustrate one embodiment of the use of a single- action to give an item as a gift to one or more recipients.

Figure 10 illustrates an embodiment of a grid for creation of a group and the entry of identifying information for recipients associated with the group (i.e., members).

Figure 11 is a flow diagram of an embodiment of the overall flow of the gift delivery system.

Figure 12 is a block diagram illustrating the components of an embodiment of the gift delivery system, Figure 13 is a state diagram illustrating the various states of a gift order in one embodiment. ^****"

Figure 14 is a flow diagram of an embodiment of a routine that controls the receiving of gift orders.

Figure 15 is a flow diagram of an embodiment of a routine that controls the attempt at first contact of the recipient.

Figure 16 is a flow diagram of an embodiment of a routine that controls the processing of the initial voice telephone contact.

Figure 17 is a flow diagram of an embodiment of a routine that controls the processing of the initial response. Figure 18 is a flow diagram of an embodiment of a routine that controls the collecting of additional contact information.

Figure 19 is a flow diagram of an embodiment of a routine that controls the verifying of the delivery information.

Figures 20A-20D illustrate an embodiment of multi- procurement option ordering.

Figures 21A-21C illustrate an embodiment of adding an additional customer procurement option.

Figure 22 illustrates an embodiment of adding an additional recipient procurement option. Figure 23 illustrates an embodiment of multi-procurement option ordering after an additional customer procurement option has been added.

Figure 24 is a block diagram illustrating an embodiment of a system for multi-procurement option ordering.

Figure 25 is a flow diagram of an embodiment of the Generate Item Web Page routine.

Figure 26 is a flow diagram of an embodiment of the Process Selection Of Procurement Option routine. Figure 27 is a flow diagram of an embodiment of the Create

New Customer Procurement Option subroutine.

Figure 28 is a flow diagram of an embodiment of the Create New Recipient Procurement Option subroutine.

Figures 29A-29B illustrate example results of multi- procurement option ordering in one embodiment.

Figure 30 is a flow diagram of an embodiment of the Generate Order Web Page Summary routine.

Figures 31A-31G illustrate an embodiment of multi- procurement option ordering. Figures 32A-32B illustrate an embodiment of a user's address book from which procurement options can be determined.

Figure 33 illustrates an embodiment of multi-procurement option ordering used with items in a user's shopping cart.

Figure 34 illustrates an embodiment of single-action ordering from a user's wish list

Figure 35 illustrates an embodiment of a post-order summary page from which order options can be modified. DETAILED DESCRIPTION

A method and system for ordering of items in a client/server environment is described. In some embodiments, a single-action ordering system is used to reduce the number of purchaser interactions needed to place an order and to reduce the amount of sensitive information that is transmitted between a client system and a server system.

In one embodiment, the server system assigns a unique client identifier to each chent system. The server system also stores purchaser- specific order information for various potential purchasers. The purchaser- specific order information may have been collected from a previous order placed by the purchaser. The server system maps each client identifier to a purchaser that may use that client system to place an order. The server system may map the client identifiers to the purchaser who last placed an order using that client system. When a purchaser wants to place an order, the purchaser uses a chent system to send the request for information describing the item to be ordered along with its chent identifier. The server system determines whether the chent identifier for that chent system is mapped to a purchaser. If so mapped, the server system determines whether single-action ordering is enabled for that purchaser at that client system. If enabled, the server system sends the requested information (e.g., via a Web page) to the chent computer system along with an indication of the single action to perform to place the order for the item. When single-action ordering is enabled, the purchaser need only perform a single action (e.g., click a mouse button) to order the item. When the purchaser performs that single action, the chent system notifies the server system. The server system then completes the order by adding the purchaser-specific order information for the purchaser that is mapped to that chent identifier to the item order information (e.g., product identifier and quantity). Thus, once the description of an item is displayed, the purchaser need only take a single action to place the order to purchase that item. Also, since the chent identifier identifies purchaser-specific order information already stored at the server system, there is no need for such sensitive information to be transmitted via the Internet or other communications medium. Figures 1A-1C illustrate one embodiment of single-action ordering. Figure 1 A illustrates the display of a Web page describing an item that may be ordered. This example Web page was sent from the server system to the chent system when the purchaser requested to review detailed information about the item. This example Web page contains a summary description section 101, a shopping cart section 102, a single-action ordering section 103, and a detailed description section 104. One skilled in the art would appreciate that these various sections can be omitted or rearranged or adapted in various ways. In general, the purchaser need only be aware of the item or items to be ordered by the single action and of the single action ^" needed to place the order. The summary description and the detailed description sections provide information that identifies and describes the item(s) that may be ordered. The shopping cart section provides the conventional capability to add the described item to a shopping cart. The server system adds the summary description, the detailed description, and the shopping cart sections to each Web page for an item that may be ordered. The server system, however, only adds the single-action ordering section when single-action ordering is enabled for that purchaser at that chent system. (One skilled in the art would appreciate that a single Web page on the server system may contain all these sections but the single-action ordering section can be selectively included or excluded before sending the Web page to the chent system.) This example single-action ordering section allows the purchaser to specify with a single click of a mouse button to order the described item. Once the purchaser clicks the mouse button, the item is ordered, unless the purchaser then takes some action to modify the order. The single-action ordering section contains a single-action ordering button 103a, purchaser identification subsection 103b, and single-action ordering information subsections 103c and 103d. The purchaser information subsection displays enough information so that the purchaser can verify that the server system correctly recognizes the purchaser. To reduce the chances of sensitive information being intercepted, the server system sends only enough information so that the purchaser is confident that the server system correctly identified the purchaser but yet not enough information to be useful to an unscrupulous interceptor. The additional information subsections allow the purchaser to obtain various settings or obtain more information related to the single-action ordering. If the purchaser wants to verify the shipping address, the purchaser can select the "check shipping address" label. In response to this selection, the server system may require the purchaser to perform a "login" so that the identity of the purchaser can be verified before the shipping information is viewed or modified. The server system then sends a Web page to the chent system for display and possible modification of the shipping address. In this way, the ttansnύtting of the sensitive shipping address can be avoided unless requested by the verified purchaser.

When the purchaser selects the single-action ordering button, the chent system sends a message to the server system requesting that the displayed item be ordered. After the server system processes the message, the server system provides to the chent system a new Web page that confirms receipt of the single-action order. Figure IB illustrates the display of a Web page confirming a single-action order. The confiπning Web page contains essentially the same information as the Web page describing the item (i.e., Figure 1A) except that an order confirmation section 105 is displayed at the top of the Web page. The order confirmation section confirms that the order has been placed and provides an opportunity for the purchaser to review and change the single-action order. Alternatively, the confirming Web page can be identical to the Web page describing the item (i.e., Figure 1A), except that the single-action ordering button is replaced with a message confirming the order.

If a single-action ordering is not currently enabled for the chent system but could be enabled, then the server system can generate a Web page like Figure 1A, except that the single-action ordering button 103a is replaced by a single-action ordering enable button. Such a replacement button could contain text mstructing the purchaser to click on the button to enable single- action ordering. When the purchaser clicks on that button, the server system would send the Web page of Figure 1A to be displayed. Single-action ordering can be enabled whenever the server system has stored sufficient purchaser-specific order information for that chent system to complete a single-action order. If the server system does not have sufficient information, then when the purchaser selects the single-action ordering button, the server system can provide a Web page to collect the additional information that is needed. The server system may require the purchases to "login" so that the identify of the purchaser can be verified before the single- action ordering is enabled.

To help minimize shipping costs and purchaser confusion, the server system may combine various single-action orders into a multiple-item order. For example, if a purchaser orders one item using the single-action ordering and five minutes later orders another item using the single-action ordering, then those orders may be cost effectively combined into a single order for shipping. The server system combines the single-action orders when their expected ship dates are similar. For example, if one item is immediately available and the other item will be available in one day, then the two single-action orders may be cost-effectively combined. However, if the other item will not be available for two weeks, then the two single-item orders would not be combined. Figure IC illustrates the display of a Web page representing four single-action orders that have been combined into two separate multiple-item orders based on the availabihty of the items. The order information 106 indicates that item 1 and item 2, which will be available in three or fewer days, have been combined into one order. The order information 107 indicates that items 3 and 4, which will not be available within one week, are combined into a separate order. In one embodiment, the server system may combine single-action orders that are placed within a certain time period (e.g., 90 minutes). Also, the server system may combine or divide orders when the orders are scheduled for shipment based on the then current availability of the items ordered. This delayed modification of the orders is referred to as "expedited order selection" and is described below in detail.

Figure 2 is a block diagram illustrating an embodiment of a system that supports single-action ordering. This embodiment supports the single-action ordering over the Internet using the World Wide Web. The server system 210 includes a server engine 211, a chent identifier/customer table 212, various Web pages 213, a customer database 214, an order database 215, and an inventory database 216. The server engine receives HTTP requests to access Web pages identified by URLs and provides the Web pages to the various chent systems. Such an HTTP request may indicate that the purchaser has performed the single action to effect single- action ordering. The customer database contains customer information for various purchasers or potential purchasers. The customer information includes purchaser-specific order information such as the name of the customer, billing information, and shipping information. The order database 215 contains an entry for each order that has not yet been shipped to a purchaser. The inventory database 216 contains a description of the various items that may be ordered. The chent identifier/customer table 212 contains a mapping from each chent identifier, which is a globally unique identifier that uniquely identifies a chent system, to the customer last associated with that chent system. The chent system 220 contains a browser and its assigned chent identifier. The chent identifier is stored in a file, referred to as a "cookie." In one embodiment, the server system assigns and sends the chent identifier to the chent system once when the chent system first interacts with the server system. From then on, the client system includes its chent identifier with all messages sent to the server system so that the server system can identify the source of the message. The server and chent systems interact by exchanging information via communications link 230, which may include transmission over the Internet.

One skilled in the art would appreciate that the single-action ordering techniques can be used in various environments other than the Internet. For example, single-action ordering can also be in an electronic mail environment in which an item is described in an electronic mail message along with an indication of the single action that is to be performed to effect the ordering of the item. Also, various communication channels may be used such as local area network, wide area network, or point-to-point dial up connection. Also, a server system may comprise any combination of hardware or software that can generate orders in response to the single action being performed. A chent system may comprise any combination of hardware or software that can interact with the server system. These systems may include television-based systems or various other consumer products through which orders may be placed.

Figure 3 is a flow diagram of an embodiment of a routine that enables single-action ordering for a customer. To enable single-action ordering, a server system needs to have information about the customer that is equivalent to the purchaser-specific order information. The server system can obtain this information in various ways. First, the server system could ask the customer if they would like to have single-action ordering enabled. If so, then the server system could prompt the customer using a Web page for the purchaser-specific order information. Second, the server system could also save the purchaser-specific order information collected when an order is placed conventionally. The server system could, either automatically or with the customer's assent, enable single-action ordering. In step 301, the server system retrieves the chent identifier, that was sent by the chent system. In step 302, the server system updates the chent identifier/customer table to indicate that the generated chent identifier has been associated with that customer. In step 303, the server system sets a flag indicating that single- action ordering is enabled for that chent identifier and that customer combination. That flag may be stored in the chent identifier/customer table. In step 304, the server system supplies a confirming Web page to the chent system. The next time a purchaser attempts to order an item, the chent system wih supply its chent identifier to the server system. If single-action ordering is enabled for that purchaser, the server system wih assume that the purchaser is the customer associated with that chent identifier in the chent identifier/customer table. Thus, a purchaser may not want to allow the server system to enable single-action ordering if there is a possibility that someone else may use that same chent system.

Figure 4 is a flow diagram of an embodiment of a routine to generate a Web page in which single-action ordering is enabled. When single-action ordering is enabled, the server system generates a Web page describing an item as is conventionally done and then adds a single-action ordering section. In one embodiment, the server system adds partial purchaser-specific order information to the section. This information may include the customer's name, a shipping address moniker selected by the purchaser (e.g., "at home"), and the last five digits of a credit card number or a nickname selected by the purchaser. Such partial information should be the m imum information sufficient to indicate to the purchaser whether or not the server system is using the correct purchaser-specific order irifermation. In step 401, the server system generates a standard shopping cart-type Web page for the item. In step 402, if the single-action ordering flag has been set for the chent identifier and customer combination, then the server system continues at step 403, else the server system completes. In step 403, the server system adds the single-action section to the Web page and completes.

Figure 5 is a flow diagram of an embodiment of a routine which processes a single-action order. When a purchaser performs the single action needed to place an order, the chent system notifies the server system. The server system then combines the purchaser-specific order information for the customer associated with the chent system with the item order information to complete the order. The single-action order may also be combined with other single-action orders and possibly with other conventionahy placed orders to reduce shipping costs. In one embodiment, single-action orders can be combined if they are placed wilhin a certain time period of each other (e.g., 90 minutes). This routine illustrates the combining of the single-action orders into a short-term order (e.g., available to be shipped in less than a week) and a long-term order (e.g. , available to be shipped in more than a week). One skilled in the art would appreciate that the single-action orders can be combined in various ways based on other factors, such as size of shipment and intermediate-term availability. In step 501, if the item is expected to be shipped in the short term, then the server system continues at step 502, else the server system continues at step 505. In step 502, if a short-term order has aheady been opened for the purchaser, then the server system continues at step 504, else the server system continues at step 503. In step 503, the server system creates a short-term order for the purchaser. In step 504, the server system adds the item to the short-term order and continues at step 508. In step 505, if a long-term order has already been opened for the purchaser, then the server system continues at step 507, else the server system continues at step 506. In step 506, the server system creates a long-term order for the purchaser. In step 507, the server system adds the item to the long-term order. In step 508, the server system generates and sends the confirmation and completes. Figure 6 is a flow diagram of an embodiment of a routine for generating a single-action order summary Web page. This Web page (e.g., Figure IC) gives the user the opportunity to view and modify the short-term and long-term single-action orders. In step 601, the server system adds the standard single-action order information to the Web page. In step 602, if a short-term order is open, then the server system adds the short-term order to the Web page in step 603. In step 604, if a long-term order is open, then the server system adds the long-term order information to the Web page in step 605 and completes. Figure 7 is a flow diagram of an embodiment of a routine that implements an expedited order selection algorithm. The goal of the expedited order selection algorithm is to minimize the number of orders sent to each destination so that shipping costs are reduced. A destination may be a specific shipping address plus a specific purchaser's billing details. Orders that are sent to the same destination are known as "sibhng orders." The algorithm has two stages. In the first stage, the algorithm schedules for shipment the orders for destinations for which all the sibling orders are filled. An order is filled when ah its items are currently in inventory (i.e., available) and can be shipped. For each group of sibling orders, the algorithm combines those sibling orders into a single combined order so that only one order is currently scheduled for shipment to each destination. In the second stage, the algorithm combines and schedules groups of sibling orders for which some of the sibling orders are not filled or partially filled. The algorithm may spht each partially filled sibling order into a filled sibling order and a completely unfilled sibling order. The algorithm then combines aU the filled sibhng orders into a single combined order and schedules the combined order for shipment. If any group has only one sibling order and that order is partially filled, then the algorithm in one embodiment does not spht that order to avoid making an extra shipment to that destination. During the second stage, the algorithm may select and schedule groups of sibling orders in a sequence that is based on the next fulfillment time for an item in the group. The next fulfillment time for a group of sibling orders is the minimum expected fulfillment time of the items in that group of sibhng orders. For example, if a group of sibling orders has seven items that are not yet fulfilled and their expected fulfillment times range from 3 days to 14 days, then the next fulfillment time for that group is 3 days. The algorithm first schedules those groups of sibling orders with the largest next ftilfillment time. For example, if 6 groups have next fulfillment times of 3, 5, 7, 10, 11, and 14 days, respectively, then the algorithm first selects and schedules the sibling orders in the group with the next fulfillment time of 14 days, followed by the group with the next fulfillment time of 11 days, and so on. By delaying the scheduling of groups with short next fulfillment times, the algorithm increases the chances of additional items becoming available (because of the shortness of the next fulfillment time) and thus combined with the scheduled order.

Steps 701-703 represent the first stage of the expedited order selection algorithm, and steps 704-706 represent the second stage of the expedited selection order algorithm. In steps 701-703, the algorithm loops selecting groups in which ah sibhng orders are fihed and combining the orders. In step 701, the algorithm selects the next group with all sibling orders that are fihed. In step 703, if ah such groups have already been selected, then the algorithm continues with the second stage in step 704, else the algorithm continues at step 703. In step 703, the algorithm combines and schedules the orders in the selected group and loops to step 701. In step 704, the algorithm selects the next group of sibling orders that has the largest next fulfillment time. In step 705, if ah such groups have already been selected, then the algorithm is done, else the algorithm continues at step 706. In step 706, the algorithm combines and schedules the orders in the selected group and loops to step 704. When the expedited order selection algorithm is being performed, new orders and new inventory may be received. Whenever such new orders and new inventory is received, then the algorithm restarts to schedule and combine the new orders as appropriate.

Although the algorithm has been described as having two stages, it could be implemented in an incremental fashion where the assessment of the first and second stages are redone after each order is scheduled. One skilled in the art would recognize that there are other possible combinations of these stages which still express the same essential algorithm. Figures 8A-8C illustrate a hierarchical data entry mechanism in one embodiment. When collecting information from a user, a Web page typically consists of a long series of data entry fields that may not ah fit onto the display at the same time. Thus, a user needs to scroh through the Web page to enter the information. When the data entry fields do not fit onto the display at the same time, it is difficult for the user to get an overah understanding of the type and organization of the data to be entered. The hierarchical data entry mechanism allows a user to understand the overah organization of the data to be entered even though the ah data entry fields would not fit onto the display at the same time. Figure 8A illustrates an outline format of a sample form to be fihed in. The sample form contains various sections identified by letters A, B, C, and D. When the user selects the start button, then section A expands to include the data entry fields for the customer name and address. Figure 8B illustrates the expansion of section A. Since only section A has been expanded, the user can view the data entry fields of section A and summary information of the other sections at the same time. The user then enters data in the various data entry fields that are displayed. Upon completion, the user selects either the next or previous buttons. The next button causes section A to be cohapsed and section B to be expanded so that financial information may be entered. Figure 8C illustrates the expansion of section B. If the previous button is selected, then section A would collapse and be displayed as shown in Figure 8A. This collapsing and expanding is repeated for each section. At any time during the data entry, if an error is detected, then a Web page is generated with the error message in close proximity (e.g., on the line below) to the data entry field that contains the error. This Web page is then displayed by the chent system to inform the user of the error. In addition, each of the data "entry" fields may not be editable until the user chcks on the data entry field or selects an edit button associated with the data entry field. In this way,^"the user is prevented from inadvertently changing the contents of an edit field. When the user chcks on a data entry field, a new Web page is presented to the user that allows for the editing of the data associated with the field. When editing is complete, the edited data is displayed in the data "entry" field. Because the fields of the form are thus not directly editable, neither "named-suhmit" buttons nor Java are needed. Also, the form is more compact because the various data entry options (e.g., radio button) are displayed only on the new Web page when the field is to be edited.

In other embodiments, a mechanism for giving a gift to an identified recipients) using a single action is provided. When information is displayed describing the item, the system displays an instruction to identify the recipients) and then to select a "give" button to effect the giving of the item to the identified recipients). If the user is giving the gift to only one recipient, then the user enters identifying information, such as the email address, of the recipient. If the user is giving the gift to more than one recipient, the user could enter the identifying information of each recipient, or alternatively, the user could enter a group name that is associated with the identifying information for each member (i.e., recipient) of the group. The system uses the identifying information to identify a delivery address for the gift. As described in more detail below, the system can use various databases to locate information for an identified recipient. Figures 9A-9B illustrate one embodiment of the use of a single- action to give an item as a gift to one or more recipients. Figure 9A illustrates the giving of a gift to one recipient. The sections 101-104 are the same as described for Figure 1A. The gift giving section 901 contains an instruction subsection 901a, an identifying information subsection 901b, and a single-action giving subsection 901c. To effect the giving of the item to a recipient, the user enters the email address of the recipient in the identifying information subsection 90b and then selects the single-action giving subsection 901c. The system receives the email address and uses the email address to locate the dehvery address for the recipient as described below in detail._. The system bills the item to the user based on information stored for that user for single-action ordering and ships the item to the recipient at the dehvery address. As described below, the system can allow many different types of identifying information to be specified by the user. Figure 9B illustrates the giving of a gift to multiple recipients.

The gift giving section 902 contains an instruction subsection 902a, a group name subsection 902b, and a single-action giving subsection 902c. To effect the giving of the item to multiple recipients, the user inputs a name of the group that identifies the recipients into the group name subsection 902b and then selects the single-action giving subsection 902c. The system uses the group name to identify a hst of recipients who are associated with the group name. Figure 10 illustrates a grid for creation of a group and the entry of identifying information for recipients associated with the group (i.e., members). The user enters the group name in group name section 1001 and then enters information relating to the recipients in each row of the member information section 1002. The user can enter as much information about each recipient associated with the group as is known by the user. For example, the user may enter only the email address for some users, while entering the name, email address, and dehvery address of other recipients. When the system is requested to give an item to each recipient associated with a group, the system uses the information stored for each recipient to identify additional information need to effect the dehvery of the gift as described below. The system may also store the identified additional information for each recipient so that when another item is subsequently given to that recipient, the additional information needed to effect the dehvery of the item can be quickly retrieved. Alternatively, a single address book for a user containing the information for ah possible recipients can be maintained. The user specifies a group by indicating some of the recipients whose addresses are in the address book. The use of address books facilitates, the maintaining of multiple groups that have one or more recipients in common. In addition, a user can at any time provide additional information about a recipient to facilitate the retrieval of sufficient information to effect the dehvery of an item.

A computer-based method and system for coordinating the dehvery of gifts by receiving gift orders, collecting additional dehvery information that is not specified in the gift orders, and dehvering gifts based on the additional dehvery information is also provided. In one embodiment, the gift dehvery system receives gift orders via Web pages provided on the WWW. The gift orders specify a gift that is to be dehvered to a recipient. The recipient may be identified by information that does not include the dehvery address of the recipient. For example, the recipient may be only identified by a name and contact information such as an electronic mail address or a telephone number. The gift dehvery system attempts to contact the recipient to obtain sufficient dehvery information. If the contact is not successful, the gift dehvery system searches various databases of information to identify additional contact information. If sufficient dehvery information is obtained, the gift is dehvered to the recipient and the gift giver is notified accordingly. If, however, sufficient dehvery information cannot be obtained, the gift giver is notified that the gift cannot be dehvered. Figure 11 is a flow diagram of an embodiment of the overall flow of the gift dehvery system. In step 1101, the gift dehvery system receives the order for a gift from a gift giver. In one embodiment, the order is received via access through a Web page, but may also be received via other modes of communication, such as a voice telephone call, postal mail, facsimile, or electronic mail. In step 1102, the gift dehvery system attempts to contact the recipient of the gift. The gift order may specify contact information for the recipient, such as an electronic mail address or a telephone number of the recipient. Based on the contact information provided with the gift order, an attempt via electronic mail or an automated voice telephone cah is made to initiahy contact the recipient and gather sufficient dehvery information. Alternatively, a person may attempt to make a voice telephone contact with the recipient. In step 1103, if the initial contact is successful, then the system continues at step 1106, else the system continues at step 1104. In step 1104, the system attempts to cohect additional contact information. The system can obtain the additional contact information through various database sources using the information provided with the gift order. For example, the system can use the recipient's name or the recipient's electronic mail address to access Internet-based database systems. In step 1105, if the system obtains additional contact information from these additional sources, then the system loops to step 1102 to attempt to contact the recipient using the additional contact information, else the system continues at step llll. In step 1106, the system collects dehvery infoπnation from the successful contact. For example, if the successful contact is a phone ca , the operator making the phone call preferably enters the dehvery information. If the successful contact is an electromc mail exchange, the system preferably parses the recipient's reply message to collect the dehvery information. In step 1107, the system verifies that the dehvery information is correct. The system may use various databases, which contain hsts of ah proper street addresses, to verify the address. In step 1108, if the dehvery information is verified, then the system continues at step 1109 to send the gift to the recipient, else the system continues at step llll. In step 1109, the system sends the gift to the recipient. In step 1110, the system sends an electronic mail to the gift giver providing notification that the gift has been sent successfuhy. In step llll, if sufficient dehvery infoπnation could not be gathered or the dehvery information could not be verified, then the system sends a message (e.g., via electronic mail) to the gift giver providing notification that the gift could not be dehvered and is being placed on hold. In an additional embodiment (not shown), if an attempt to contact the recipient is unsuccessful in step 1103, then the system attempts to obtain additional dehvery information for the recipient from sources other than the recipient, such as databases and other sources similar to those discussed below in conjunction with Figure 8. If the system is able to obtain sufficient dehvery infoπnation for the recipient in this manner, the system preferably sends the gift to the recipient using the obtained dehvery information.

Figure 12 is a block diagram illustrating the components of an embodiment of the gift dehvery system. Computer system 1201 contains a central processing unit, memory, and peripheral devices, such as a disk drive and CD-ROM. The gift dehvery system includes an order entry system 1202 and an order delivery system 1203. The order entry system provides a user interface for a gift giver to input a gift order. The order entry system in one embodiment comprises a Web page that accesses a gift database 1204. The gift giver uses the Web page provided to select which gift should be sent to the recipient. In addition, the gift giver provides information describing the recipient. The order entry system then stores the order information in the order database 1205. The gift dehvery system controls the locating of additional dehvery information so that the gift can be successfuhy dehvered to the recipient. The gift dehvery system retrieves information from the order database and attempts to contact the recipient based on the information provided with the gift order. If the recipient cannot be contacted based on that information, then the gift dehvery system accesses other database sources, such as the customer database 1206 and Internet-based databases 1208 to gather additional contact information for the recipient.

Figure 13 is a state diagram i ustrating the various states of a gift order in one embodiment. A gift order can be in one of six states: received, response pending, verifying dehvery information, cohecting additional contact information, on hold, and scheduled for dehvery. Initiahy, when an order is received, the system places the order in the received state

1301. When the system attempts to contact the recipient using the information provided by the gift giver, the gift order changes to a response pending state 1302. The response pending state indicates that the attempt to contact is in progress, but no response has yet been received from the recipient. If a sufficient response is received from the recipient in the allotted time (e.g., 24 hours), then the gift order changes to the verifying delivery information state 1303. In the verifying dehvery infoπnation state, the system attempts to verify that the dehvery information is correct. If the dehvery address is corcect, then the gift order enters the scheduled for dehvery state 1304. If the initial response was insufficient or not received in the allotted time, then the system places the gift order in the cohecting additional contact information state 1305. In the cohecting additional contact information state, the system searches additional sources of information to determine additional contact information about the recipient. If additional contact information can be found, then the system attempts an additional contact, and places the gift order in the response pending state

1302. If, however, additional contact information cannot be found, then the system places the gift order in the on hold state 1306.

In a further preferred embodiment, if the initial response is insufficient, then the system places the gift order in a cohecting additional dehvery information state (not shown). In the cohecting additional dehvery information state, the system searches additional sources of information to obtain additional dehvery information for the recipient. If the system is able to obtain sufficient dehvery information in this manner, then the system places the gift order in the verify dehvery information state 1303. Otherwise, the system places the gift order in the on hold state 1306.

Figure 14 is a flow diagram of an embodiment of a routine that controls the receiving of gift orders. The receive gift order routine controls the interaction with the gift giver to select a gift from the gift database, to receive information on the recipient, to receive the payment, and to store the gift order in a database. This routine processes gift orders received electronicahy. One skilled in the art would appreciate that similar routines could be developed to handle other forms of receiving gift orders. In step 1401, the routine receives a request to send a gift from a gift giver to a recipient electronicahy via a Web page. In step 1402, the routine creates a session with the gift giver. The session is used to track the interaction with the gift giver and the gift dehvery system. In step 1403, the routine receives the gift selection information. The gift selection information may be selected in response to a display of available gifts from the gift database. In step 1404, the routine receives recipient contact information from the gift giver. The recipient contact information may typically include the recipient's name and electronic mail address. In step 1405, the routine receives payment information. The payment information may be in an electronic form, such as a credit card, debit card, or digital cash, or in a conventional form, such as check or money order. If in conventional form, the gift order may be placed in an additional state waiting for receipt of the payment. In step 1406, if the payment is approved, then the routine continues at step 1408, else the routine notifies the gift giver that the payment has been denied. In step 1408, the routine assigns a gift order tracking number to the gift order. The gift order tracking number is used by the system to identify the gift order throughout its processing. In step 1409, the routine stores the gift order information in the gift order database. In step 1410, the routine notifies the gift giver that the gift order has been accepted. In step 1411, the routine ends the session with the gift giver. Figure 15 is a flow diagram of an embodiment of a routine that controls the attempt at first contact of the recipient. The first contact is made with contact information provided by the gift giver, such as electronic mail address and telephone number. If sufficient information is not provided to even attempt to contact the recipient initially, the gift dehvery system searches various, databases to obtain such information based on the recipient's name. In step 1501a, if the recipient's electronic mail address has been provided in the gift order, then the routine continues at step 1501b, else the routine continues at step 1502a. In step 1501b, the routine sends an electronic mail to the electronic mail address provided. The electronic mail contains infoπnation inchoating that a gift is to be sent to the recipient and requests dehvery information for the gift. The electronic mail includes the tracking number assigned by the system so that when a reply mail is received, the gift delivery system can determined to which gift order it coπesponds. In step 1502a, if the recipient's phone number has been provided, then the routine continues at 1502b, else the routine continues various other attempts to contact the recipient. For example, if a facsimile number was provided, a facsimile message is sent to the number. In step 1502b, the routine schedules an initial telephone contact with the recipient. The initial telephone contact could be via an automated voice telephone system in which a message is left with the person answering the phone or with an answering machine. Alternatively, a human operator may make the initial voice contact. After the initial contact is made, the gift order is placed in response pending state.

Figure 16 is a flow diagram of an embodiment of a routine that controls the processing of the initial voice telephone contact. This routine can either display information for a human operator or provide information to an automated operator. In step 1601, if the telephone has been answered, then the routine continues at step 1602, else the routine leaves the gift order still scheduled for initial contact. In step 1602, if a message is left either with a person or a voicemail system, then the routine continues at step 1603, else the routine leaves the gift order still scheduled for initial contact. In step 1603, if a sufficient response has been received, then the routine continues at step 1605, else the routine continues at step 1604. In step 1604, the routine schedules the gift order for searching for additional contact information relating to the recipient. In step 1605, the routine updates the order database with the additional information about the recipient. In step 1606, the routine schedules the gift order to have its dehvery information verified and changes its state to verifying dehvery infoπnation.

Figure 17 is a flow diagram of an embodiment of a routine that controls the processing of the initial response. The initial response can be via electronic mail, voice telephone, or facsimile message. In step 1701, if the tracking number is included in the response, then the routine continues at step 1702, else the routine continues at step 1704. In step 1702, the routine verifies the tracking number using the gift order database. In step 1703, if the tracking number has been verified, then the routine continues at step 1706, else the routine continues at step 1704. Ih step 1704, the routine attempts to find the tracking number based on the information provided in the response. In step 1705, if the tracking number can be found, then the routine continues at step 1706, else the routine continues at step 1707. In step 1706, if the response contains sufficient dehvery information so that the gift order can be dehvered, then the routine continues at step 1708, else the routine continues at step 1707. In step 1707, the routine schedules the order for searching for additional dehvery information. In step 1708, the routine schedules the order to have its dehvery information verified and changes its state to verify dehvery information. Figure 18 is a flow diagram of an embodiment of a routine that controls the cohecting of additional contact information. This routine searches various database sources based on the information provided in the gift order. For example, in step 1801, the routine searches Internet-based telephone and electronic mail directories, such as Switchboard, Fourll, and Accumail. In step 1802, the routine searches various CD-ROM databases of telephone and electronic mail information, such as SelectPhone. In step 1803, the routine searches the local database of customer information. The local database of customer infoπnation contains information of previous recipients and gift givers. In step 1804, the routine searches various Internet- based search engines, such as Digital Equipment's Alta Vista or Ihfoseek's Ultraseek. In step 1805, the routine uses the electronic mail address or telephone number to identify the geographic location of the recipient. In particular, the routine accesses the InterNIC Registration Services of Network Services for the domain name registration of the recipient's electronic mail address. Alternatively, the routine accesses the standard table of area codes and telephone number prefixes to determine the geographic locale of the recipient. The gift dehvery system can use each of these infoπnation sources, a subset of these information source, or additional infoπnation source to locate the additional infoπnation. In step 1806, the routine analyzes the retrieved information to determine the information that most likely coπesponds to the recipients based on geographic or contextual matches. This analysis may be done electronicahy or interactively with a human operator. In step 807, the routine stores the retrieved and analyzed information and the gift order database. In step 808, the routine displays the information to a human operator and requests instructions on further processing. The instructions can either be to place the order on hold because sufficient dehvery infoπnation has not been collected, send an initial contact to the recipient, or proceed with dehvery of the gift. Figure 19 is a flow diagram of an embodiment of a routine that controls the verifying of the dehvery information. The gift dehvery system verifies the dehvery information to ensure that the gift is being sent to a dehverable address. In step 1901, the routine checks the vahdity of the dehvery infoπnation automatically. The routine uses a database of U.S. Postal Service addresses to determine whether the dehvery address is a valid U.S. Postal Service address. In step 1902, if the address is valid, then the routine continues at step 1906, else the routine continues at step 1903. In step 1903, the routine prompts a human operator for manual verification of the address. In step 1904, if the operator has manuahy verified the address, then the routine continues at step 1906, else the routine continues at step 1905. In step 1905, the routine notifies the gift giver that the order cannot be fulfihed and places the order on hold. In step 1906, the routine schedules the gift for dehvery and notifies the gift giver accordingly. Thus, an item can be ordered in a variety of ways. Ordering of items is discussed in U.S. Patent No. 09/151,617, filed September 11, 1998, which is hereby incorporated by reference and which is a continuation-in- part of U.S. Patent No. 09/046,503, filed on March 23, 1998, now abandoned, and U.S. Patent No. 08/928,951, filed on September 12, 1997, Patent No. 5,960,411.

In some embodiments, multi-procurement option ordering of an item is provided in which multiple alternatives for completing the ordering of the item are available. In particular, each user can have multiple defined procurement options, and a selection or indication of one of those procurement options can be sufficient to complete the ordering of the item without further action by the user if that procurement option contains sufficient information. Alternately, a single-action ordering can be used to indicate the ordering of the item without further action by the user, but the information of a currently selected procurement option wih be used to complete the ordering. Each procurement option can have a unique set of purchaser-specific order information (e.g., payment information, dehvery address, dehvery instructions, shipping instructions, wrapping instructions, etc.), can have a unique moniker (e.g., a short name such as "home," partial payment information, partial dehvery address information, recipient name, etc.), and can have a variety of types of recipients (e.g., the user, an individual other than the user, a group of recipients, etc.) to whom an ordered item wih be dehvered. In some embodiments, each user can have one of their procurement options designated as their primary or default procurement option. In addition, in some embodiments a user can perform ordering of an item using a new or a partially specified procurement option. In such embodiments, the user can specify only a minimal amount of information needed to determine a dehvery address (e.g., a name or other identifier for the recipient), and related information can be automatically retrieved (e.g., determining the dehvery address based on a specified recipient identifier) and/or previously specified default infoπnation for the other portions of the procurement option (e.g., default shipping instructions and payment information) can be used to complete the ordering.

Figures 20A-20D illustrate one embodiment of multi- procurement option ordering. Figure 20A illustrates the display of a Web page describing an item that may be ordered. This example Web page was sent from a server system to a chent system when the user requested to review detailed information about the item. The Web page contains a summary description section 2001, a shopping cart section 2002, a multi- procurement option ordering section 2003, and a detailed description section 2004. One skilled in the art wih appreciate that these various sections can be omitted or reaπanged or adapted in various ways. The user need only be aware of the item or items to be ordered and of an action (e.g., a single action) needed to select a procurement option in order to place the order. The summary description and the detailed description sections provide information that identifies and describes the one or more items that may be ordered. The shopping cart section provides a conventional capability to add the described item to the shopping cart. The server system adds the summary description, the detailed description, and the shopping cart sections to each Web page for an item that may be ordered. The server system, however, may add the multi-procurement option ordering section only when multi- procurement option ordering is enabled for that user at that chent system. One skilled in the art wih appreciate that a single Web page on a server system may contain ah these sections, and that the multi-procurement option ordering section can be selectively included or excluded before sending the Web page to the chent system.

When an indication of one or more of the multiple procurement options are displayed, the illustrated multi-procurement option ordering section allows the user to specify one of the procurement options, such as with a single action (e.g., a single chck of the mouse button), to order the described item. Once the user specifies the procurement option, the item is ordered unless the user then takes some other action to modify the order. Those skilled in the art wih appreciate that in other embodiments, other single actions by the user can cause the procurement option to be selected, including moving the cursor over an indication of the procurement option or circling an indication of the procurement option with a pointing device. In the illustrated embodiment, the multi-procurement option ordering section contains a multi-procurement option ordering button 2003 a and a cunent procurement option selection 2003b. The cunent procurement option selection subsection displays enough information so that the user can identify the procurement option that is currently selected, such as a moniker for that procurement option. To reduce the chances of system information being intercepted, the server system sends only enough infoπnation so that the user can uniquely identify the procurement option, but not enough information to be useful to an unscrupulous interceptor or to another user. When the cunent procurement option selection 2003b is selected, the chent system sends a message to the server system requesting that the displayed item be ordered using information for that procurement option. The current procurement option selection can be selected in one of a variety of ways, such as by clicking the mouse when the cursor is over subsection 2003b or by selecting the multi-procurement option ordering button 2003a in a manner indicative of using the cuπently selected procurement option (e.g., a left-click on a multi-button mouse) to complete the ordering of the item. In some embodiments, the initiahy displayed cunent procurement option selection is a procurement option that has been previously designated as a default procurement option for the user.

After the server system receives a message from the chent system to order the item using a specified procurement option, the server system retrieves information about the selected procurement option and uses that retrieved information to order the item. In some embodiments, the procurement option information is stored by the server system and available to the chent system only when the server system provides it to the chent system, while in other embodiments the chent system stores the procurement option information and provides it to the server system. After the ordering of the item by the server system, the server system can provide to the chent system a new Web page (not shown) that confirms receipt of the order.

In some embodiments, the generated Web page wih include the multi-procurement option ordering button 2003a only if at least one of the procurement options for the user is cuπently enabled for ordering (e.g., by being exphcitiy designated as being enabled, or by containing sufficient information to allow the server system to complete the order). If the user has no procurement options that are cuπently enabled for such ordering, the multi-procurement option ordering button 2003a can instead be replaced by a multi-procurement option ordering enable button. If the user selects the multi-procurement option ordering enable button, the server system can provide a Web page to cohect any additional infoπnation that is needed to enable one or more existing procurement options, or to create a new procurement option.

Figure 20B illustrates the display of multiple procurement options 2005 for the cunent user. In the illustrated embodiment, a hst of the available procurement options is displayed after the receipt of a user indication (e.g., a right-click of the mouse while the cursor is over the multi- procurement option ordering button 2003 a or the cunent procurement option selection 2003b). In alternate embodiments, the various procurement options may be added to the Web page when it is initiahy generated and thus displayed without user indication. In addition, available procurement options can be displayed in a manner other than a hst, such as by displaying only a single entry at a time from a hst of available entries and cycling through the entries. The procurement options to be displayed can be determined in a variety of ways. In some embodiments, an address book of previously defined procurement options is maintained by the server system that generates the Web page or by a third-party server. In alternate embodiments, the chent system can provide infoπnation about potential recipients, such as by accessing an online Rolodex database or email address book for the user. In the illustrated example, the cunent user is John Doe and the procurement option with the moniker "John Doe at home" is the default procurement option. The default procurement option can be indicated in a variety of ways, such as by being displayed as the initial cunent procurement option selection 2003b, by being displayed as the first entry 2006 in the hst of available procurement options, or by being displayed in a manner that is distinguishable from the other procurement options (e.g., with a darkened border around it).

As described above, each procurement option may have a unique set of information for completing the order of the item. Other entries in the hst may thus vary from procurement option 2006 in a variety of ways. For example, procurement options 2007 and 2008 each have dehvery addresses at John's workplace rather than his home. While they have the same recipient and the same dehvery address, those two procurement options may vary in other ways, such as by payment information (e.g., a personal credit card versus a company debit account) or by shipping instructions (e.g., a common carrier and speed of dehvery service versus electronic dehvery).

Procurement option 2009 has a recipient other than John Doe, that being Jolene Doe. Procurement option 2009 may be displayed for a variety of reasons, such as Jolene Doe being a frequent recipient of gifts from John Doe. Alternately, John and Jolene may share a single joint account, and thus the procurement options for the account may include options for both users. Yet another alternative is that the chent computer system on which the Web page is being displayed is shared by John and Jolene, but the chent system may supply a single unique chent identifier to the server system to identify the cunent user. If so, the server system may include procurement options appropriate for each of the possible users associated with the chent identifier if it is not possible to determine which user is cuπently using the chent system.

In some embodiments, a procurement option wih be displayed only if it is cuπently enabled and thus available to complete an order for the item. In alternate embodiments, non-enabled procurement options are also displayed. In the illustrated embodiment, procurement option 2011 is a non- enabled procurement option that is displayed in a manner that indicates that the procurement option is not enabled (e.g., displayed in a dimmed manner or with an identifying mark). Procurement options can be non-enabled for a variety of reasons, such as due to a lack of sufficient information necessary to complete the ordering of the item (e.g., payment information or a dehvery address) or based on a previous exphcit user indication to non-enable that procurement option. In some embodiments, non-enabled procurement options can be selected and used to complete the ordering of the item, such as by exphcitiy indicating to enable the procurement option or by supplying additional necessary information. .

In addition to displaying a moniker to represent a procurement option, it is also possible to represent procurement options in other manners (e.g., when no moniker is defined). For example, procurement option 2012 is displayed using partial dehvery address information in which only a portion of the numerical address is displayed. Alternately, portions of other procurement option information can also be displayed, such as payment infoπnation. In some embodiments, a user can perform the ordering of an item by specifying a new procurement option. In the illustrated embodiment, procurement options 2014 and 2016 can be selected to create a new procurement option for the user or for a non-user recipient. After selecting one of the options, the user is prompted to supply enough information to allow the system to purchase and dehver the item. After supplying the information, the order wih be completed in accordance with the newly created procurement option, as described in greater detail with respect to Figures 21A-C and 22.

In some embodiments, the user can select a displayed procurement option in a manner that does not trigger an ordering of the item, such as by right-chcking on the displayed procurement option. In Figure 20C, the user has selected the procurement option with the moniker "Jolene Doe," but has not yet selected a procurement option with which to perform ordering of the item. After the procurement option with the moniker "Jolene Doe" is selected, it is displayed as the cunent procurement option selection 2003b. If the user decides to complete the order using the "Jolene Doe" procurement option, the user can perform an order of the item using the cunent procurement option selection in a variety of ways (e.g., by left- chcking on the multi-procurement option ordering button 2003a or the cunent procurement option selection 2003b). In yet other embodiments, the user may select a procurement option using one display element, but perform the ordering using the selected procurement option using a separate display element. For example, in Figure 20D the multi-procurement option ordering button 2003a has been replaced by a procurement option selection button 2003c and an ordering button 2003 d.

Those skilled in the art wih appreciate that the embodiments shown in Figures 20A-20D are for hlustrative purposes only, and are not intended to limit the scope of the invention. A user can perform a multi- procurement option ordering of one or more items using one of multiple available procurement options in a variety of ways.

Figures 21A-21C illustrate an embodiment of adding an additional customer procurement option. The adding of an additional customer procurement option can occur in a variety of ways, such as by the user exphcitiy entering a mode for that purpose, or by selection of a displayed item such as procurement option 2014 shown in Figure 20B.

In some embodiments, it is necessary to verify the identity of a user before allowing the user to perform certain actions, such as adding new procurement options. User identity verification can be performed in a variety of ways. As shown in Figure 21A, one identity verification process involves the user supplying a user name 2101 and an associated password 2102. After a user's identity has been verified, some embodiments allow a user to specify information that can be later used in a default manner, such as to be included with procurement options that are added at a later time (e.g., during the same shopping trip). In the illustrated embodiment, the user can optionally specify credit card payment information 2103 at the time of user identity verification that will be used for new procurement options that are defined later during the shopping trip. In alternate embodiments, the payment information may be available until a timer expires after a specified occuπence, such as from the time the information was originally provided, from the last time the user performed an action requiring a verified user identity, or from the last time the user performed an action using a secured connection.

After user identity verification has been performed, or if it is not cuπently required, the user can create a new procurement option having themself as the recipient by supplying a variety of procurement option information, such as that shown in Figure 21B. Since the new procurement option is for the user and the user identity is known, the user can be automatically selected as the cunent customer (and thus the name of the recipient is not displayed). If other types of default procurement option information had previously been specified, those defaults could be displayed in a manner that allows optional modification by the user, or those types of information could instead be omitted and the previously specified default information could be automatically used for the new procurement option. The procurement option information to be added includes dehvery address information 2104, phone number contact information 2105, payment infoπnation 2106, shipping instructions 2107, and moniker infoπnation 2108. In the illustrated embodiment, the user can also select box 2109 in order to designate that the new procurement option be the default procurement option for the user. In addition, in some embodiments the user can specify that procurement option information that has been added to the new procurement option be used as default procurement option information for procurement options to be added in the firture. In the illustrated embodiment, the user has selected box 2110 so that the specified payment information as default information for procurement options that are later added. Those skilled in the art wih appreciate that other user-selectable options may be available, such as an option to treat the procurement option as enabled or not. Figure 21C illustrates that when the next new customer procurement option is to be added, the entry area for payment information 2106 is omitted since the previously selected default payment information wih be used for this new procurement option. In a similar manner to that shown in Figure 2 IB, the user can create a new procurement option having someone other than themself as the recipient by supplying si variety of procurement option information such as that shown in Figure 22. The user specifies the name of the recipient 2203 and, if the user has dehvery address information for the recipient, a user can directly specify the address information 2204. However, when designating someone else as the recipient, the user may have only partial or no dehvery address infoπnation for the recipient. In that situation, some embodiments allow the user to specify identifier information that can be used to identify the user, such as a phone number 2201 or an email address 2202. If the identifier information allows the system to contact the recipient, the system can attempt to determine the dehvery address through such contact. Alternately, the identifier information may be sufficient to allow the system to automaticahy identify address information associated with that identifier (e.g. , an address associated with a phone number in a White Pages directory).

In the illustrated embodiment, the previously specified default payment information is displayed as a default selection for payment infoπnation 2206, but only partial information is displayed and the default infoπnation is modifiable by the user. Also, in addition to specifying shipping instructions information 2207 and procurement option moniker information 2208, the illustrated embodiment allows the user to specify gift wrapping option information 2209. Those skilled in the art wih appreciate that a variety of other types of information can also be specified, such as options to automaticahy add a greeting card or a message along with the item, or options to automaticahy provide confirmation to the user when the item is dehvered.

Those skilled in the art wih also appreciate that multiple instances of a type of default information could be specified, such as a first set of default payment information for new customer procurement options and a second set of default payment information for new recipient procurement options. In addition, those skilled in the art wih appreciate that a subset of the information requested for new customer and recipient procurement options may be sufficient for the procurement option to be used to complete the order of an item. For example, moniker and gift wrapping instruction information may not be necessary to complete an item order.

After a new procurement option has been added, that procurement option may be available for the ordering of future items. Figure 23 illustrates that after the new customer procurement option shown on Figure 2 IB has been added, that procurement option is available in the hst 2005 as a new procurement option 2010. In some embodiments, only customer procurement options are displayed for multi-procurement option ordering of an item, while in other embodiments ah available procurement options are displayed.

Figure 24 is a block diagram hlusfrating an embodiment of a system for multi-procurement option ordering. This embodiment supports multi-procurement option ordering over the Internet using the World Wide Web. The server system 2410 includes a server engine 2411, a chent identifier to customer mapping component 2412, various Web pages 2413, an order database 2415, an inventory database 2416, and a procurement information retrieval component 2418. The server system also includes a customer database 2414 which is composed of groups of customer information, such as customer 1 infoπnation group 2440 that contains customer procurement entries 2442 and recipient procurement entries 2444. The other customer information groups similarly contain customer procurement entries and/or recipient procurement entries for those customers.

The server system receives HTTP requests from various chent systems to access Web pages that are identified by URLs, and provides the requested Web pages to the requesting chents. Such HTTP requests may be in response to the user requesting a Web page providing irrformation about an item that may be ordered, or instead may be in response to the user performing a multi-procurement option ordering of an item from such a Web page.

When a chent system requests a Web page providing information about an item that may be ordered, the server system attempts to add user-specific procurement option information to the Web page. If the identity of the user has been determined, the server system retrieves information from the customer database about the procurement entries that are stored for the customer, and provides a moniker or other set of partial procurement option information for each enabled procurement option. Such monikers ahow the procurement option to be uniquely identified while protecting confidential information. If the server system has not yet identified the identity of the user and the chent system supphes a chent identifier that uniquely identifies that system, the server uses the chent identifier to customer mapping component to identify one or more customers that are associated with that chent system, and then provides such monikers for the procurement options stored for those customers.

Alternatively, when an HTTP request indicates in the illustrated embodiment that the user has performed multi-procurement option ordering of an item, the HTTP request includes an indication of a procurement option selected for the user (e.g., a selected moniker) that is to be used to complete the ordering of the item. When the server system receives such an HTTP request, the server system retrieves information from the procurement entry for the customer that is stored in the customer database (e.g., from customer procurement entries 2442 when the user is customer 1 and is ordering an item that is to be dehvered to themself), and uses the retrieved information to complete the ordering of the item for the customer. The inventory database can be checked to confirm that the ordered item is available, and the order database can be updated to reflect the new order. In some instances, an HTTP request indicates that the user has selected to create a new procurement option that is to be used to order the item. If so, the chent and server systems attempt to cohect sufficient infoπnation from the user in order to create a procurement option that is enabled for ordering. When sufficient information has been received, the new procurement option is added to the customer infoπnation group for the user in the customer database, and the information for the new procurement option is used to complete the ordering of the item. If the chent and server systems are not able to cohect sufficient information to enable the new procurement option, the procurement information retrieval component can attempt to use the partiahy specified procurement information to automaticahy determine the other necessary information. For example, if the user has specified an identity of the recipient but has not specified a dehvery address, the retrieval component can attempt to identify the dehvery address in a variety of ways as described above. Alternately, if default information has previously been specified for one or more types of procurement option information, the retrieval component or the server engine can use that default information if the user does not supply alternate infoπnation. Even if sufficient information to complete an order cannot be cuπently identified, a partiahy specified procurement option can be created and added to the customer database.

A chent system such as chent 2420 can communicate with the server system via a communications mechanism 2430 in order to send HTTP requests and receive Web pages from the server. The chent system can use a browser 2421 to send and receive HTTP messages and to display Web pages. As discussed above, a client system can store a unique chent identifier 2422 that can be supphed to the server system. In addition, in some embodiments the chent system can store one or more address books for various users that may use the chent system, such as user 1 address book 2423 and user 2 address book 2424. If such address books exist for the cunent user, information in the address books can be used to assist in determining possible recipients for new procurement options as well as for identifying relevant procurement option information for new procurement options created for such recipients (e.g., dehvery addresses). One skilled in the art wih appreciate that the multi-procurement option ordering techniques can be used in various environments other than the Internet. For example, multi-procurement option ordering can also be used in an electronic mail environment in which an item is described in an electronic mail message along with an indication of a selection of a procurement option that is to be used to complete the ordering of the item. Also, various communication channels may be used, such as a local area network, a wide area network, or a point-to-point dial up connection. In addition, a server system may comprise any combination of hardware or software that can generate orders in response to selection of a procurement option. Similarly, a chent system may comprise any combination of hardware or software that can interact with the server system. These systems may include television-based systems or various other consumer products through which orders may be placed. In addition, while Web pages are often constructed using HTML, other methods can be used to create such pages, such as Java, XML, HDML, WML, CGI scripts, etc. Similarly, communication protocols other than HTTP can be used, such as WAP, TCP DP, or FTP, as weh as a variety of inter-device communication mechanisms, including CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, Mobitex, etc. Both the chent and the server system can also operate on a wide variety of operating system types (e.g, Windows, Linux, Unix, MacOS, BEOS, PalmOS, EPOC, Windows CE, FLEXOS, OS/9, JavaOS, etc.), and need not share the same operating system.

Figure 25 is a flow diagram of an embodiment of the Generate Item Web Page routine 2500. When multi-procurement option ordering is enabled for at least one procurement option for the cunent user, the server system generates a Web page describing an item in a conventional manner and then adds a multi-procurement option ordering section for that user. In one embodiment, the server system adds partial information for each enabled procurement option to the section (e.g., monikers for immediate display), while in an alternate embodiments such partial information is available upon request by the user.

The routine begins at step 2505 where a conventional Web page describing the item is generated. The routine Ihen continues to step 2510 to determine whether to add a shopping cart procurement section to the Web page (e.g., based on previously specified preferences for the user). If so, the routine continues to step 2515 to add a shopping cart procurement section to the Web page. After step 2515, or if it is determined in step 2510 to not add the shopping cart section, the routine continues to step 2520 to determine whether to add a section to the Web page that allows the user to select one of multiple procurement options to order the item. If so, the routine continues to step 2525 to add such a multi-procurement option section to the Web page. After step 2525, or if it was instead determined in step 2520 to not add such a multi-procurement option section, the routine continues to step 2595 and ends. Those skihed in the art wih appreciate that the information for the multi-procurement option section can be generated and displayed in a variety of ways.

Figure 26 is a flow diagram of an embodiment of the Process Selection Of Procurement Option routine 2600. When the user selects a procurement option to complete the ordering of the item (e.g., by performance of a single action), the chent system notifies the server system of the selected procurement option. The server system then retrieves the procurement option information for the selected procurement option and uses that information to complete the ordering of the item. The multi- procurement option order may also be combined with other multi- procurement option orders and/or other conventionahy placed orders to reduce shipping cost. In the illustrated embodiment, the initiahy generated Web page contains a displayed element that, when selected, proceeds to display the various available procurement options. While in some embodiments the information for those procurement options wih have previously been supphed to the chent system, in the illustrated embodiment the chent system retrieves the information to be displayed for those procurement options when the displayed element is selected.

The routine begins at step 2605 where the chent system receives an indication to display the available procurement options. The routine continues to step 2610 to retrieve the various available defined procurement options (e.g., from the server system or from previously received information), and then continues to step 2615 to determine which of the retrieved options have sufficient information in order to enable that option for ordering. Those skihed in the art wih appreciate that in alternate embodiments, one or more of the retrieved options may be exphcitiy identified as being enabled or not enabled, and the explicit identifications are used rather than reviewing the information stored for that procurement option. Also, those skihed in the art wih appreciate that in some embodiments the server system wih determine which of the retrieved options are cuπently enabled and supply that information (e.g., monikers) to the chent system (e.g., with the initial dehvery of the Web page for the item), while in other embodiments the server system may supply some or ah of the procurement option information for the various possible procurement options to the chent system and the chent system wih determine which of the options are cunently enabled.

In step 2620, after the monikers for the available procurement options have been determined, the chent system displays the monikers to the user. The routine then continues to step 2623 to display selections to the user that ahow the user to create a new customer or recipient procurement option. Those skihed in the art wih appreciate that in some embodiments one or more of these selections may not he available. The routine next continues to step 2625 where the chent system receives an indication from the user of a selection of one of the displayed procurement options. The routine then continues to step 2630 to determine if the selected option is to create a new customer procurement option. If so, the routine continues to step 2635 to execute the Create New Customer Procurement Option subroutine. After step 2635, the routine continues to step 2640 to use the newly created customer procurement option information to complete the ordering of the item.

It was instead determined in step 2630 that the selected option is not to create a new customer procurement option, the routine continues to step 2645 to determine if the selected option is to create a new recipient procurement option. If so, the routine continues to step 2650 to execute the Create New Recipient Procurement Option subroutine. The routine then continues to step 2655 to use the newly created recipient procurement option information to complete the ordering of the item.

If it was instead determined in step 2645 that the selected option is not to create a new recipient procurement option, the routine continues to step 2660 to use the procurement option infoπnation for the selected procurement option to complete the ordering of the item. After steps

2640, 2655, or 2660, the routine contains to step 2695 and ends. Those skihed in the art wih appreciate that in some embodiments, some or ah of steps 2635, 2640, 2650, 2655, and 2660 wih be performed by the chent system, while in alternate embodiments those steps wih be performed by the server system. Those skihed in the art wih also appreciate that in some embodiments, the monikers for the available procurement options are initiahy displayed and thus step 2605 wih not need to be executed. In addition, in various embodiments different groups of procurement options are displayed, such as only enabled procurement options, only customer procurement options, ah procurement options for the user, ah procurement options for one or more customers that are possible identities of the cunent user, etc.

Figure 27 is a flow diagram of an embodiment of the Create New Customer Procurement Option subroutine 2635. The subroutine receives information to be used to create a new procurement option, and then adds the new procurement option to the customer database. In the illustrated embodiment, the user is required to specify each of the types of requested ήifoπnation, but in alternate embodiments the user wih be able to choose not to specify requested infoπnation.

The subroutine begins at step 2705 where it is determined if the customer identity has previously been verified during the shopping trip. If not, the subroutine continues to step 2710 to receive and confirm a customer name and password, and then continues to step 2715 to optionally ahow the user to specify payment infoπnation to be used as a default for new procurement options that are added later during the shopping trip.

After step 2715, or if it was instead determined in step 2705 that the customer identity has been verified, the subroutine continues to step 2720 to receive customer delivery address information. In step 2725, customer contact information (e.g., a phone number or email address) is received, and in step 2730 shipping information is received. In step 2735, the subroutine receives a display moniker for the new procurement option. Those skilled in the art wih appreciate that in some embodiments a moniker for the new procurement option can be automaticahy generated rather than supphed by the user.

The subroutine continues to step 2740 to determine if default payment information had aheady been specified (e.g., during user identity verification), and if not, the subroutine continues to step 2745 to receive such payment information. After step 2745, or if it was instead determined in step 2740 that payment information has aheady been specified, the subroutine contains to step 2750 to add the new customer procurement option to the group of information in the customer database information for the user. Since the user has specified ah of the required information, the subroutine in step 2755 then designates the new customer procurement option as being fully specified and thus enabled for ordering. The subroutine continues to step 2760 to determine if the user desires that the new customer procurement option be the default procurement option for the user. If so, the subroutine continues to step 2765 to make that designation. After step 2765, or if it was instead determined in step 2760 that the new procurement option is not to be the default, the subroutine continues to step 2795 and returns.

Those skihed in the art wih appreciate that in some embodiments the user identity wih not be verified or wih be verified before the ability to create a new procurement option is made available to the user. Those skihed in the art wih also appreciate that there are a variety of ways of verifying user identity other than with user names and passwords. Also, in some embodiments, only some of the types of procurement option information wih be sohcited from the user, while in alternate embodiments additional types of procurement option infoπnation wih be sohcited. Similarly, in some embodiments a variety of types of default procurement option information may be available, while in other embodiments no such default infoπnation may be available. If default information is available, in some embodiments such infoπnation wih be displayed but wih be modifiable by the user, while in other embodiments such default information wih be automaticahy used and the step of sohciting that type of information from the user wih not be performed. Those skihed in the art wih also appreciate that in some embodiments the server system wih request the various procurement option information (e.g., by sending a Web page having defined areas in which to add the requested information), while in alternate embodiments the chent system wih cohect the procurement option information and provide the infoπnation to the server system. Figure 28 is a flow diagram of an embodiment of the Create New Recipient Procurement Option subroutine 2650. The subroutine receives information to be used to create a new procurement option, and then adds the new procurement option to the customer database. In the illustrated embodiment, the user is required to specify each of the types of requested information, but in alternate embodiments the user wih be able to choose not to specify requested information.

The subroutine begins at step 2805 where it is determined if the customer identity has already been verified during the shopping trip. If not, the subroutine continues to step 2810 to receive and confirm a customer name and password, and men continues to step 2815 to optionally ahow the user to specify payment information to be used as a default for new procurement options that are added later during the shopping trip.

After step 2815, or if it was instead determined in step 2805 that the customer identity has been verified, the subroutine continues to step 2820 to determine whether the user has available the dehvery address information for the recipient. If not, the subroutine contains to step 2825 to receive a phone number and/or an email address for the recipient, and then continues to step 2830 to determine a dehvery address for the recipient using that infoπnation. Those skihed in the art wih appreciate that there are a variety of ways to determine a dehvery address, and that there are a variety of types of information other than email addresses or phone numbers that can be used to determine such a dehvery address.

If it was instead determined in step 2820 that the user has dehvery address information for the recipient, the subroutine contains to step 2835 to receive the recipient dehvery address information from the user. After step 2830 or 2835, the subroutine contains to step 2840 to receive shipping infoπnation. The subroutine then continues to step 2845 to receive a display moniker for the newly created recipient procurement option. Those skilled in the art wih appreciate that in some embodiments a moniker for the new procurement option can be automaticahy generated rather than supphed by the user. The subroutine next continues to step 2850 to receive information from the user specifying a type of gift wrapping and card to be used for items specified with this procurement option. The subroutine next continues to step 2855 to determine if default payment information had aheady been specified (e.g., during user identity verification), and if not, the subroutine continues to step 2860 to receive such payment information. After step 2860, or if it was instead determined in step 2855 that payment information has already been specified, the subroutine contains to step 2865 to add the new recipient procurement option to the customer database information for the user. After step 2865, the subroutine continues to step 2895 and returns. In the illustrated embodiment, the subroutine does not determine whether the new procurement option is fully specified and thus enabled for ordering at the time of creation as is done for new customer procurement options (e.g., the determination may be dynamically made each time available procurement options for the user are determined, or instead this information may not be necessary because only customer procurement options are displayed to the user). Similarly, in the illustrated embodiment, recipient procurement options are not avahable to be default procurement options, and thus the user is not queried to determine whether the new procurement option should be the default.

Those skihed in the art will appreciate that in some embodiments the user identity wih not be verified or wih be verified before the ability to create a new procurement option is made avahable to the user. Those skilled in the art wih also appreciate that there are a variety of ways of verifying user identity other than with user names and passwords. Also, in some embodiments, only some of the types of procurement option information wih be sohcited from the user, while in alternate embodiments additional types of procurement option information whl be sohcited. Similarly, in some embodiments a variety of types of default procurement option information may be avahable, while in other embodiments no such default infoπnation may be avahable. If default information is avahable, in some embodiments such information wih be displayed but wih be modifiable by the user, while in other embodiments such default information wih be automaticahy used and the step of soliciting that type of information from the user will not be performed. Those skihed in the art wih also appreciate that in some embodiments the server system wih request the various procurement option information (e.g., by sending a Web page having defined areas in which to add the requested information), while in alternate embodiments the chent system wih cohect the procurement option information and provide the information to the server system.

Figures 29A-29B illustrate example results of multi- procurement option ordering in one embodiment. In particular, these figures illustrate the display of a Web page representing five items that have been ordered using different procurement options. Items have been aggregated based first on the procurement option used, and then based on the availabihty of the items. Thus, the order information 2910 for the customer procurement option with the moniker "John Doe at Home" indicates that the items aggregated in order 2916 wih be dehvered in 3 days or fewer, while the item in order 2917 wih be dehvered in one or more weeks. Since the two orders have different availabihty times for shipping, they are not combined into one order. However, items 1 and 2 of order 2916, which were each individuahy ordered using multi-procurement option ordering, have been combined into a single order since they use the same procurement option and thus have the same dehvery information. In one embodiment, the server system may combine orders that are placed within a certain time period (e.g., 90 minutes). Also, the server system may combine or divide orders when the orders are scheduled for shipment based on the then cunent avahabihty of the items ordered. Those skihed in the art wih appreciate that in alternate embodiments, items may not be aggregated together. Alternately, in some embodiments items may be aggregated even when ordered using different procurement options (e.g., if the dehvery address and shipping instructions are the same, or if the procurement options differ only by payment infoπnation).

Figure 30 is a flow diagram of an embodiment of the Generate Order Web Page Summary routine 3000. The Web page produced by the routine (e.g., Figures 29A and 29B) gives the user the opportunity to view and modify short-term and long-term orders before the orders are processed. The routine begins in step 3005 where a default order summary page is generated. The routine then continues to step 3010 to determine if any items whose orders are not yet processed were ordered using a customer procurement option. If so, the routine continues to step 3015 to select the next such customer procurement option, beginning with the first procurement option. The routine then continues to step 3020 to determine if there are any items that have been ordered using the selected procurement option but are not yet processed, and that are scheduled to be dehvered in the short-term. If so, the routine continues to step 3025 to add each such item to the Web page as part of a single group order. After step 3025, or if it was instead determined in step 3020 that there are no such short-term orders, the routine continues to step 3028 to determine if there are any items that have been ordered using the selected procurement option but are not yet processed, and that are scheduled to be dehvered in the long-term. If so, the routine continues to step 3030 to add each such item to the Web page as part of a single group order. After step 3030, or if it was instead determined in step 3028 that there are no such long-term orders, the routine continues to step 3035 to determine if there are other customer procurement options that have been used to order items that are not yet processed. If so, the routine returns to step 3015 to select the next such customer procurement option. Those skihed in the art wih appreciate that items can be grouped in ways other than by short-term and long-term dehvery options.

If it was instead determined in step 3035 that there are no more such customer procurement options or in step 3010 that there were not any such customer procurement options, the routine continues to step 3040 to determine if any items whose orders are not yet processed were ordered using a recipient procurement option. If so, the routine continues to step 3045 to select the next such recipient procurement option, beginning with the first procurement option. The routine then continues to step 3050 to determine if there are any items that have been ordered using the selected procurement option but are not yet processed, and that are scheduled to be dehvered in the short-term. If so, the routine continues to step 3055 to add each such item to the Web page as part of a single group order. After step 3055, or if it was instead determined in step 3050 that there are no such short-term orders, the routine continues to step 3060 to determine if there are any items that have been ordered using the selected procurement option but are not yet processed, and that are scheduled to be dehvered in the long-term. If so, the routine continues to step 3065 to add each such item to the Web page as part of a single group order. After step 3065, or if it was instead determined in step 3060 that there are no such long-term orders, the routine continues to step 3070 to determine if there are other recipient procurement options that have been used to order items that are not yet processed. If so, the routine returns to step 3045 to select the next such recipient procurement option. If it was instead determined in step 3070 that there are no more such recipient procurement options or in step 3040 that there were not any such recipient procurement options, the routine continues to step 3095 and ends.

Figures 31A-31G illustrate an embodiment of multi- procurement option ordering. Figure 31A illustrates the display of a Web page describing an item that may be ordered. This example Web page was sent from a server system to a chent system when the user requested to review detailed information about the item. The Web page contains a summary description section 3101, a shopping cart section 3102, a multi- procurement option ordering section 3103, a wish list addition section 3104, and a detailed description section 3105. One skihed in the art wih appreciate that these various sections can be omitted or rearranged or adapted in various ways. The user need only be aware of the item or items to be ordered and of an action (e.g., a single action) needed to select a procurement option and/or to place a order. The summary description and the detailed description sections provide information that identifies and describes the one or more items that may be ordered. The shopping cart section provides a conventional capability to add the described item to the shopping cart via button 3102a. Similarly, the wish hst addition section provides the capability via button 3104a to add the described item to a wish hst for the user that contains items desired by the user. After an item is added to a wish hst and a shipping/dehvery address for the user is associated with the item, others may typically view the hst and purchase the item for the user as a gift. One skihed in the art wih appreciate that a single Web page on a server system may contain a these sections, and that the multi-procurement option ordering section can be selectively included or excluded before sending the Web page to the chent system.

The illustrated multi-procurement option ordering section ahows the user to specify one of the procurement options to be a cunent procurement option, such as with a single chck of the mouse button over a displayed indication of a procurement option. In addition, the multi- procurement option ordering section ahows the user to order the described item, such as with a single action (e.g., a single chck of the mouse button), using information associated with the cunent procurement option. Once the user specifies the single action to order the item, the item wih be ordered unless the user then takes some other action to modify the order. In the illustrated embodiment, the multi-procurement option ordering section contains a multi-procurement option display 3103a, which includes a cunent procurement option display 3103b and a procurement option selection button 3103c. The multi-procurement option ordering section also contains a single-action ordering button 3103d and a gift indication selection option 3103e. The cunent procurement option display contains enough information so that the user can identify the procurement option that is currently selected, such as a moniker for that procurement option. In the illustrated embodiment, when the Web page is first displayed a default procurement option is selected as the cunent procurement option, and thus the cunent procurement option display contains the information for the default procurement option. As is illustrated, a procurement option with the moniker "John Doe" is the default procurement option. If the single action ordering button is selected after the Web page is displayed (e.g., by clicking the mouse when the cursor is over section 3103d), the chent system sends a message to the server system requesting that the displayed item be ordered using the information associated with the cunent procurement option.

After the server system receives a message from the chent system to order the item using the cunent procurement option, the server system retrieves information about the procurement option and uses that retrieved information to order the item. After the ordering of the item by the server system, the server system can provide to the chent system a new Web page (not shown) that confirms receipt of the order. Figure 3 IB illustrates the display of multiple procurement options avahable for the cunent user. In the ihustrated embodiment, a dropdown hst of the avahable procurement options is displayed after the receipt of a user indication (e.g., a left-click of the mouse while the cursor is over button 3103c). As is shown, the hst includes options 3103d-31031. In addition, as is ihustrated, some of the infoπnation on the Web page may be obscured by the hst of options, such as the wish hst addition section 3104.

The procurement options to be displayed can be determined in a variety of ways, including from an address book for the user of previously defined procurement options maintained by the server system that generates the Web page. In addition, the order and format in which the procurement options are displayed can vary greatly. In the ihustrated embodiment, the hst of procurement options begins with the cuπently selected procurement option fohowed by two other recently selected procurement options. Since the default procurement option is the initial cunent procurement option in the ihustrated embodiment, the first option 3103 d shows the moniker for the default procurement option and is highlighted as the cunent selection. Options 3103e and 3103f follow with two monikers that are automaticahy generated (as explained in greater detail below), and the next option 3103g is an option that ahows the user to specify a new procurement option that wih be added to the user's address book. Alternately, the last option in the hst 31031 ahows the user to indicate a recipient to receive the item, but in the ihustrated embodiment the recipient information wih not be added to the address book. Options 31031, 3103j, and 3103k also illustrate monikers automaticahy generated to be unique, hsted in alphabetical order by the last name of the recipient specified. Option 3103h is a dotted line that separates the display of the recently selected procurement options from the alphabetical procurement options, and in the ihustrated embodiment the dotted line cannot be selected as a cunent procurement option selection. In the ihustrated embodiment, the selection of an indication of a displayed procurement option causes that procurement option to become the cunent procurement option, but does not cause the item to be ordered. Thus, for example, Figure 31C indicates the Web page after hst option 3103k (with moniker "Benjamin F- Fair") is selected, with the moniker for the procurement option displayed as the cunent procurement option selection 3103b. If the user decides to then complete the order by selecting the 3103d button, the infoπnation associated with the Benjamin F- Fair procurement option whl be used to order the item.

If the user instead selects the "add new address" option 3103g, the user may be presented with a Web page for gathering new procurement option information such as is ihustrated in Figure 3 ID. The procurement option information to be added can include a variety of types of information such as name and dehvery address information 3114, phone number contact information 3115, payment information 3116, shipping instructions 3117, and moniker information 3118. Some of the information may also be optional, such as the moniker and the phone number. As indicated previously, in the ihustrated embodiment the new information wih be used to create a new entry in the user's address book. However, in the ihustrated embodiment the user can select whether the new procurement option wih be displayed as an available procurement option when a hst of such options are next displayed, with this selection made via box 3119. In other embodiments additional selections may be available, such as whether to make this new entry the new default entry in the address book.

If the user had selected the "send to e-mail address" option 31031 in Figure 3 IB, the user would instead be presented in the ihustrated embodiment with a Web page such as is ihustrated in Figure 3 IE. The information to be specified is limited here to an e-mail address of the recipient 3130 and shipping instructions 3140. In this embodiment, the system whl attempt to determine the name and dehvery address information for the recipient, and may use previously specified default payment infoπnation. Since a new procurement option wih not be created for this recipient, moniker infoπnation is not needed. Those skihed in the art wih appreciate that a variety of other types of information can also be specified.

As previously mentioned, the ihustrated item Web page also contains a gift indication selection option 3103e. If this gift indication is selected, as is ihustrated in Figure 3 IF, then the system may perform additional processing when the single-action ordering button 3103d is selected. In the ihustrated embodiment, the system gathers information relevant to a gift before an order for the item is placed. As shown in Figure 3 IG, in the ihustrated embodiment the user is presented with options related to how the item is to be supphed to the intended recipient, including whether a gift message wih accompany (or precede) the item and whether the item wih be gift-wrapped. Those skihed in the art wih appreciate that other types of information related to supplying the item could also be specified. In the ihustrated embodiment, the user can enter a text message in box 3150a if they so desire, and can also select one of various types of gift wraps as shown in section 3160. After the user has specified any desired gift message and gift wrapping instructions, the system wih proceed to place the order using that infoπnation in conjunction with the information from the cunent procurement option when ordering button 3103d was selected.

As mentioned previously, in the ihustrated embodiment the address book of the user is used to generate the hst of procurement options displayed in Figure 3 IB. Figures 32A and 32B illustrate an example address book that would exist after the performance of the activities described in Figures 31A-3 IG. In particular, the address book includes 8 addresses 3210- 3280. In addition to the addresses, the address book Web page includes a selectable control 3205 via which the user can enable or disable whether single-action ordering, including the use of the multiple available procurement options, is cuπently avahable for the user. The user can also add new addresses to the address book via selectable control 3207, which may cause an information collection Web page to be displayed similar to that shown in Figure 3 ID.

Each of the 8 cunent addresses includes a variety of dehvery, payment and shipping information, as well as selectable controls to modify various parts of the information. Each address also includes a moniker 32X2 (e.g., 3212, 3222, . . .) and procurement option avahabihty instructions 32X4. The cunent default procurement option 3210 has a default indication message 3216, and is displayed first in the address book in the ihustrated embodiment. In the ihustrated embodiment, the default entry in the address book wih be used as the default procurement option for item-ordering Web pages generated for the user, and the entry in the address book that is the default can be modified from the address book, such as by selecting the control shown in message 3216. In alternate embodiments, each displayed entry may have a control available to make that entry the default entry. The rest of the entries are shown in alphabetical order. When the hst of procurement options was displayed in Figure 3 IB, six existing available procurement options were displayed. They coπespond to addresses 3210, 3230, 3240, 3250, 3260 and 3270. While address 3220 was present in the user's address box when the hst was displayed, the procurement option avahabihty instructions 3224 indicate that the address is not to be shown as an available procurement option. Address 3280 was not present when the hst was displayed, but instead reflects the new procurement option that was created in Figure 3 ID.

As is shown, each address has a unique moniker. Those skihed in the art wih appreciate that moniker names can be manuahy specified or automaticahy generated in a variety of ways, and that in some embodiments monikers may not be required to be unique. In the ihustrated embodiment, the user is allowed to manuahy specify a moniker if they wish, but is not required to do so. If a manuahy specified moniker is valid (e.g., unique, and within length and other constraints), that moniker wih be displayed. Addresses 3210, 3220, and 3280 have manuahy specified monikers. In the illustrated embodiment, monikers wih be automaticahy generated based on recipient name and dehvery information if manually specified monikers are not supphed. In particular, if a user's name (or the portion of the name that fits within the length constraints) is unique, then the name wih be used. If multiple identical names exist but they can be distinguished by the city name (or the part of the city name that fits within the length constraints), then some or ah of the name fohowed by some or ah of the city wih be used. Similarly, if name and city are not unique, the system next checks if name and zip code are unique, and if so uses that combination. Finally, if none of the previous generation schemes produce a unique name, the system wih append numbers to the end of the recipients' names. In the ihustrated embodiment, potentially sensitive information such as a street address or phone number is not used as part of the automatic moniker generation scheme. As an example of the automated moniker generation scheme, addresses 3230, 3240 and 3250 each have identical names (whether for the same person or for different people). Using the next check, the three addresses also have identical city names. Address 3250 has a unique zip code among the three addresses, however, and thus the moniker for address 3250 is composed of a portion of the recipient's name fohowed by the zip code. Since addresses 3230 and 3240 could not be differentiated based on any of the tests above, they each have numbers in brackets appended after a portion of the recipient's name. In a similar manner, addresses 3260 and 3270 have identical names but different city names, and thus the automated monikers for those addresses include a portion of the recipient name fohowed by a portion of the city name.

Figure 33 illustrates an embodiment of multi-procurement option ordering used with items in a user's shopping cart. In particular, the illustrated shopping cart includes three items, those being 3310, 3320, and 3330. While items 3310 and 3320 do not cunently have any procurement information associated with them, item 3330 is indicated as having been added to the shopping cart from Benjamin Franklin's Wish List. Thus, this item has an associated dehvery address from the wish hst entry. In addition to various other quantity and price infoπnation, each item includes a gift indication selection option box 33X2. If this gift indication is selected for one or more of the items when their order is completed, the system may perform additional processing as described previously to gather relevant information such as a gift message and gift wrapping instructions.

One option avahable to the user is to use the Proceed to Checkout button 3307 to purchase one or more of the items. If so, the user wih be prompted to specify the various relevant procurement information (e.g., payment information, shipping instructions, dehvery information, etc.) for each of the items being purchased. In addition, another option avahable for purchasing one or more of the items is the single-action ordering button 3103d in conjunction with the multi-procurement option display 3303. As described previously, the user can choose one of the avahable procurement options to be the cunent procurement option, and then use the single-action ordering button to purchase the items with procurement information from that cunent selection. When one or more of the items in the shopping cart already have some procurement information associated with them (e.g., dehvery address), this existing procurement information can affect the avahabihty of the multi-procurement option ordering in various ways in different embodiments. In some embodiments, multi-procurement option and/or single-action ordering whl not be avahable if any item has existing procurement information, or instead may not be avahable if there are any variations in a particular type of procurement infoπnation among ah of the items. In other embodiments, such as the ihustrated embodiment, the existing procurement infoπnation wih be merged with the procurement information from the cunent procurement option. For example, the payment information and shipping instructions for the "John Doe" procurement option wih be used in purchasing each of the items, but the dehvery address infoπnation for the procurement option wih be used only with items 3310 and 3320 (since item 3330 already has dehvery address information). Those skihed in the art wih appreciate that such use of procurement option information can be altered in a variety of ways.

Figure 34 illustrates an embodiment of single-action ordering from a user's wish hst. In particular, Benjamin Franklin's wish hst is ihustrated with a single item shown in detail. As is shown, in the ihustrated embodiment the user can add the item to the user's shopping cart via selection box 3410, and can then modify the default dehvery address infoπnation that is associated with the item. Alternately, the user can use the single-action ordering button 3425 to purchase the item and send it to the dehvery address of the pre-selected procurement option 3420. In some embodiments the payment information associated with the pre-selected procurement option may be used to purchase the item, while in other embodiments such information may he retrieved from another source (e.g., the default procurement option, from payment information previously associated with the wish hst recipient or the item, etc.). In addition, in some embodiments a threshold may exist such that default payment infoπnation wih be used only if the amount to purchase the item is below the threshold.

In the ihustrated embodiment, other procurement options cannot be selected and used along with the pre-selected dehvery address (e.g., using the payment information and shipping instructions of another procurement option). This ability to use some or ah of the information from procurement options other than the default or pre-selected procurement option may, however, be available in other embodiments. In addition, in some embodiments when a new procurement option is created while ordering an item from a wish hst (e.g., by combining dehvery address information from one procurement option with other procurement information from another procurement option), this new procurement option is added to the user's address book. In other embodiments the user may be queried as to whether to add the new procurement option, or it may not be possible to add the new procurement option to the address book. In addition to purchasing the item, the user can also select link 3405 in order to see a detailed item description Web page. In the ihustrated embodiment, this detailed item description Web page wih have a format similar to that displayed in Figure 31 A. However, in the ihustrated embodiment the cunently selected procurement option shown in the cunent procurement option display 3103b whl be modified to be the pre-selected procurement option rather than the default procurement option. Similarly, the gift indication selection option 3103e whl be selected since items purchased from a wish hst are typically purchased as gifts. Those skihed in the art will appreciate that in other embodiments, the display of the detailed item description Web page could be altered in a variety of ways.

Figure 35 illustrates an embodiment of a post-order summary page from which order options can be modified. In particular, in the ihustrated embodiment a Thank You page is displayed in which a single- action order is confirmed, various aspects of the order and the supplying of the item (e.g., gift wrapping instructions and a gift message) are displayed and can be modified, and various options are presented to ahow the user to continue shopping (e.g., showing items related to the just-purchased item).

Those skihed in the art wih appreciate that the embodiments shown in Figures 31A-3 IG, 32A-32B, and 33-35 are for ihustrative purposes only, and are not intended to limit the scope of the invention. A user can perform a multi-procurement option ordering of one or more items using one of multiple available procurement options in a variety of ways.

Although the present invention has been described in terms of various embodiments, it is not intended that the invention be limited to these embodiments. Modification within the spirit of the invention whl be apparent to those skihed in the art. For example, the server system can map a chent identifier to multiple customers who have recently used the chent system. The server system can then ahow the user to identify themselves by selecting one of the mappings based preferably on a display of partial purchaser-specific order information. Also, various different single actions can be used to effect the placement of an order. For example, a voice command may be spoken by the purchaser, a key may be depressed by the purchaser, a button on a television remote control device may be depressed by the purchaser, or selection using any pomting device may be effected by the purchaser. Although a single action may be preceded by multiple physical movements of the purchaser (e.g., moving a mouse so that a mouse pointer is over a button, displaying a hst of possible procurement options), the single action generally refers to a single event received by a chent system that indicates to place the order. Finahy, the purchaser can be alternately identified by a unique customer identifier that is provided by the customer when the customer initiates access to the server system and sent to the server system with each message. This customer identifier could be also stored persistently on the chent system so that the purchaser does not need to re- enter their customer identifier each time access is initiated. The scope of the present invention is defined by the claims that fohow.

Claims

1. A method for ordering an item using a chent system, the method comprising: displaying information identifying the item; for each of multiple procurement options having information related to ordering, displaying an indication of the procurement option such that selection of the displayed indication represents using the information of the procurement option for ordering of the identified item; and after selection of a displayed indication, sending to a server system a request to order the identified item using the information of the procurement option for the selected indication.

2. The method of claim 1 wherein the multiple procurement options are each associated with a user performing the method, wherein each of the procurement options has a group of predefined order fulfillment information that includes a dehvery address, shipping instructions, and a payment source, and wherein the ordering of the identified item using the information of the procurement option for the selected indication is such that the identified item is to be sent to the dehvery address for that procurement option using the shipping instructions for that procurement option and is to be paid for by the payment source for that procurement option.

3. The method of claim 2 including displaying an indication to add the identified item to a cohection of items for later ordering.

4. The method of claim 2 including: displaying an indication representing order fulfillment information other than for one of the multiple procurement options; and after selection by the user of the displayed indication representing the other order fulfillment information, ordering the identified item by receiving information identifying a dehvery address; and without further user intervention, sending to the server system a request to order the identified item such that the identified item is to be sent to the identified dehvery address.

5. The method of claim 4 wherein the identified dehvery address is for a recipient other than the user, and including receiving a name of the recipient and storing the name and identified dehvery address as part of a new group of order fulfillment infoπnation for a new procurement option.

6. The method of claim 4 wherein the received infoπnation identifying the dehvery address is information indicating an identity other than the user, and including retrieving address information for the identity to be used as the identified dehvery address.

7. The method of claim 4 including receiving payment source information from the user prior to the selection by the user of the displayed indication representing the other order fulfillment information, and wherein the sent request to order the identified item specifies that the item is to be paid for by the received payment source information.

8. The method of claim 2 including: displaying an indication of a single action that is to be performed to order the identified item using the information of a cunent procurement option, wherein the selection of the displayed indication of one of the procurement options selects that procurement option as the cunent procurement option, and wherein the sending of the request to the server system is in response to a received indication of the single action by the user and is without further intervention by the user.

9. The method of claim 2 including, before the displaying of the indications of the procurement options, displaying an element representing order fulfillment instructions for the identified item, and wherein the displaying of the indications is in response to selection of the displayed element by the user.

10. The method of claim 9 wherein the selection by the user of the displayed element includes clicking a mouse button when a cursor is positioned over the displayed element, and wherein the selection by the user of the displayed indication of the one identified group includes positioning the cursor over the displayed indication.

11. The method of claim 1 wherein the procurement option for the selected indication includes payment information, and wherein the sent request is additionahy to purchase the identified item using the payment infoπnation.

12. The method of claim 1 wherein the procurement option for the selected indication includes a delivery address, and wherein the sent request is additionahy to dehver the identified item to the dehvery address.

13. The method of claim 1 wherein the procurement option for the selected indication includes shipping instructions, and wherein the sent request is additionahy to dehver the identified item as specified by the shipping instructions.

14. The method of claim 1 wherein the procurement option for the selected indication includes wrapping instructions for the item, and wherein the sent request is additionally to wrap the identified item as specified by the wrapping instructions.

15. The method of claim 1 wherein the selection of the displayed indication includes clicking a mouse button when a cursor is positioned over the displayed indication.

16. The method of claim 1 including displaying an indication to add the identified item to a cohection of items for later ordering.

17. The method of claim 1 including: displaying an indication representing creation of a new procurement option such that selection of the displayed indication represents an instruction to order the identified item using information to be associated with the new procurement option; and after selection of the displayed indication representing the creation of the new procurement option, ordering the identified item by receiving information identifying a dehvery address for the new procurement option; and sending to the server system a request to order the identified item such that the identified item is to be sent to the identified dehvery address.

18. The method of claim 17 including creating the new procurement option with the identified dehvery address as part of the new procurement option.

19. The method of claim 17 wherein the received information identifying the dehvery address is information indicating an identity other than a user performing the selection of the displayed indication representing the new procurement option, and including retrieving address information for the identity to be used as the identified dehvery address.

20. The method of claim 19 wherein the received information is an electronic mail address for the identity.

21. The method of claim 17 including receiving payment information prior to the selection of the displayed indication representing the creation of the new procurement option, and wherein the sent request to order the identified item specifies that the item is to be paid for by the received payment information.

22. The method of claim 1 wherein after the selection of the displayed indication of the procurement option, the sending of the request is performed without further intervention of a user who performs the selection.

23. The method of claim 1 wherein the information about the multiple procurement options is received from the server system.

24. The method of claim 1 wherein each displayed indication of a procurement option includes partial shipping information of the procurement option supphed by the server system.

25. The method of claim 1 wherein each displayed indication of a procurement option includes partial payment information of the procurement option supphed by the server system.

26. The method of claim 1 wherein each displayed indication of a procurement option includes a moniker identifying the procurement option.

27. The method of claim 1 wherein the chent system stores an identification to be provided to the server system to identify a user of the chent system so that the user does not need to enter identification information when ordering the identified item.

28. The method of claim 27 including, before the displaying of the indications of the procurement options, receiving information from the server system about the procurement options in response to supplying of the stored identification to the server system.

29. The method of claim 1 wherein each of the procurement options coπesponds to a single user of the chent system.

30. The method of claim 1 including, under control of the server system: before the displaying of the information identifying the item, sending to the chent system an indication of the item; and sending to the chent system an indication of the multiple procurement options; and after receiving the sent request from the chent system and without further intervention by the chent system, requesting dehvery of the identified item to a recipient specified by the procurement option for the selected option, the dehvering in a manner specified by that procurement option.

31. The method of claim 30 including: receiving an identifier from the chent system; and when sufficient information to dehver the identified item is not received from the chent system, retrieving previously supplied additional information associated with the identifier that is sufficient to dehver the identified item.

32. The method of claim 30 including, when sufficient information to deliver the identified item is not avahable for the procurement option for the selected indication, obtaining additional information from one or more external information sources that is sufficient to dehver the identified item.

33. The method of claim 1 including: (hsplaying an indication of a single action that is to be performed to order the identified item using the information of a cunent procurement option, wherein the selection of the displayed indication of one of the procurement options selects that procurement option as the cunent procurement option, and wherein the sending of the request to the server system is in response to a received indication of the single action being performed.

34. The method of claim 33 including, before the sending of the request, displaying an indication of an option related to supplying of the item.

35. The method of claim 34 including receiving an indication that the indicated option is selected by a user, and wherein the sent request includes an indication of the selected option.

36. The method of claim 34 including, before the performing of the indicated single action, displaying a selectable indication of whether to specify an option about the supplying of the item, and wherein the displaying of the indication of the option occurs only when the displayed indication of whether to specify an option is selected when the indicated single action is performed.

37. The method of claim 34 wherein the indicated option relates to wrapping instructions according to which the identified item wih be wrapped.

38. The method of claim 34 wherein the indicated option ahows a message to be supphed that wih be dehvered in addition to the identified item.

39. The method of claim 33 including displaying an indication to add the identified item to a cohection of items for later ordering.

40. The method of claim 33 wherein the displayed indication of the single action is selectable by a user to order the item for another user.

41. The method of claim 33 wherein the displayed indication of the single action is selectable by a user in order to specify options about the supplying of the item.

42. The method of claim 33 wherein the displayed indication of the single action is selectable by a user to order the item as a gift.

43. The method of claim 1 wherein the identified item is indicated to be desired by a first user, wherein each of the multiple procurement options are associated with a second user to whom the information identifying the item is displayed, wherein the selection of a displayed indication of one of the procurement options is by the second user, and wherein the sent request is to order the identified item for the first user such that payment information of the procurement option associated with the selected indication wih be used to purchase the identified item and such that dehvery information associated with the first user wih be used to dehver the identified item to the first user.

44. The method of claim 43 wherein the sending of the request is in response to the selection of the displayed indication by the second user.

45. The method of claim 43 wherein the sent request indicates to order the identified item as a gift for the first user.

46. The method of claim 43 wherein the displayed information and the displayed indications are part of a Web page displaying a wish hst of the first user.

47. The method of claim 43 wherein the sent request is additionahy such that shipping instructions of the procurement option associated with the selected indication wih be used to ship the identified item to the first user.

48. The method of claim 43 wherein the sent request is additionahy such that shipping instructions associated with the first user wih be used to ship the identified item to the first user.

49. The method of claim 43 wherein the sent request is additionahy such that wrapping instructions of the procurement option associated with the selected indication wih be used to wrap the identified item before the identified item is dehvered to the first user.

50. The method of claim 43 wherein the sent request is additionahy such that a message supphed by the second user wih be dehvered to the first user in addition to the identified item.

51. The method of claim 43 including displaying an indication to add the identified item to a cohection of items for later ordering.

52. The method of claim 43 including displaying an indication of a single action that is to be performed to order the identified item, and wherein the sending of the request is in response to the indicated single action being performed.

53. The method of claim 52 wherein the selecting of the displayed indication of one of the procurement options designates that procurement option as a cunent procurement option whose ordering information is used for the sent request.

54. The method of claim 43 wherein the payment information of the procurement option associated with the selected indication wih be used to purchase the identified item for the first user only when a cost of the identified item is below a specified threshold.

55. The method of claim 43 including displaying a second indication selectable by the second user, the displayed second indication such that at least one option about supplying of the item is to be displayed before the sending of the request if the displayed second indication is selected when the performing of the indicated single action occurs.

56. A computer-readable medium whose contents cause a computing device to order an item, by: displaying information identifying the item; for each of multiple procurement options having infoπnation related to ordering, displaying an indication of the procurement option such that selection of the displayed indication represents using the information of the procurement option for ordering of the identified item; and after selection of a displayed indication, sending to a server computer a request to order the identified item using the information of the procurement option for the selected indication.

57. The computer-readable medium of claim 56 wherein the multiple procurement options are each associated with a user to whom the infoπnation and the indications are displayed, wherein each of the procurement options has a group of predefined order fulfillment information that includes a dehvery address, shipping instructions, and a payment source, and wherein the ordering of the identified item using the infoπnation of the procurement option for the selected indication is such that the identified item is to be sent to the dehvery address for that procurement option using the shipping instructions for that procurement option and is to be paid for by the payment source for that procurement option.

58. The computer-readable medium of claim 56 wherein the procurement option for the selected indication includes payment information, and wherein the sent request is additionahy to purchase the identified item using the payment information.

59. The computer-readable medium of claim 56 wherein the procurement option for the selected indication includes a dehvery address, and wherein the sent request is additionahy to dehver the identified item to the dehvery address.

60. The computer-readable medium of claim 56 wherein the procurement option for the selected indication includes shipping instructions, and wherein the sent request is additionahy to dehver the identified item, as specified by the shipping instructions.

61. The computer-readable medium of claim 56 wherein the procurement option for the selected indication includes wrapping instructions for the item, and wherein the sent request is additionahy to wrap the identified item as specified by the wrapping instructions.

62. The computer-readable medium of claim 56 wherein the selection of the displayed indication includes chcking a mouse button when a cursor is positioned over the displayed indication.

63. The computer-readable medium of claim 56 wherein the contents further cause the computing device to display an indication to add the identified item to a cohection of items for later ordering.

64. The computer-readable medium of claim 56 wherein the contents further cause the computing device to order the item by: displaying an indication representing creation of a new procurement option; and after selection of the displayed indication representing the creation of the new procurement option, ordering the identified item by receiving information identifying a dehvery address for the new procurement option; and sending to the server computer a request to order the identified item such that the identified item is to be sent to the identified dehvery address.

65. The computer-readable medium of claim 64 wherein the contents further cause the computing device to create the new procurement option with the identified dehvery address as part of the new procurement option.

66. The computer-readable medium of claim 64 wherein the received information identifying the dehvery address is infoπnation indicating an identity other than a user performing the selection of the displayed indication representing the new procurement option, and wherein the contents further cause the computing device to retrieve address information for the identity to be used as the identified dehvery address.

67. The computer-readable medium of claim 66 wherein the received information is an electronic mail address for the identity.

68. The computer-readable medium of claim 64 wherein the contents further cause the computing device to receive payment information prior to the selection of the displayed indication representing the creation of the new procurement option, and wherein the sent request to order the identified item specifies that the item is to be paid for by the received payment information.

69. The computer-readable medium of claim 56 wherein after the selection of the displayed indication of the procurement option, the sending of the request is performed without further intervention of a user who performs the selection.

70. The computer-readable medium of claim 56 wherein the information about the multiple procurement options is received from the server computer.

71. The computer-readable medium of claim 56 wherein each displayed indication of a procurement option includes partial shipping information of the procurement option supphed by the server computer.

72. The computer-readable medium of claim 56 wherein each displayed indication of a procurement option includes partial payment ittfoπnation of the procurement option supphed by the server computer.

73. The computer-readable medium of claim 56 wherein each displayed indication of a procurement option includes a moniker identifying the procurement option.

74. The computer-readable medium of claim 56 wherein the computing device stores an identification to be provided to the server computer to identify a user of the computing device so that the user does not need to enter identification infoπnation when ordering the identified item.

75. The computer-readable medium of claim 56 wherein ah of the procurement options coπespond to a single user of the computing device.

76. The computer-readable medium of claim 56 wherein the contents further cause the computing device to order an item by: displaying an indication of a single action that is to be performed to order the identified item using the information of a cunent procurement option, wherein the selection of the displayed indication of one of the procurement options selects that procurement option as the cunent procurement option, and wherein the sending of the request to the server computer is in response to a received indication of the single action being performed.

77. The computer-readable medium of claim 76 wherein the displayed indication of the single action is selectable by a user to order the item for another user.

78, The computer-readable medium of claim 76 wherein the displayed indication of the single action is selectable by a user in order to specify options about the supplying of the item.

79. The computer-readable medium of claim 76 wherein the displayed indication of the single action is selectable by a user to order the item as a gift.

80. The computer-readable medium of claim 76 wherein the contents further cause the computing device to, before the sending of the request, display an indication of an option related to supplying of the item.

81. The computer-readable medium of claim 80 wherein the contents further cause the computing device to receive an indication that the indicated option is selected by a user, and wherein the sent request includes an indication of the selected option.

82. The computer-readable medium of claim 80 wherein the contents further cause the computing device to, before the performing of the indicated single action, display a selectable indication of whether to specify an option about the supplying of the item, and wherein the displaying of the indication of the option occurs only when the displayed indication of whether to specify an option is selected when the indicated single action is performed.

83. The computer-readable medium of claim 80 wherein the indicated option relates to wrapping instructions according to which the identified item wih be wrapped.

84. The computer-readable medium of claim 80 wherein the indicated option allows a message to be supphed that wih be dehvered in addition to the identified item.

85. The computer-readable medium of claim 76 wherein the displayed infoπnation and the displayed indication of the single action are part of a Web page for ordering the indicated item.

86. The computer-readable medium of claim 76 wherein the displayed information and the displayed indication of the single action are part of a Web page for displaying a shopping cart of a user.

87. The computer-readable medium of claim 56 wherein the identified item is indicated to be desired by a first user, wherein each of the multiple procurement options are associated with a second user to whom the information identifying the item is displayed, wherein the selection of a displayed indication of one of the procurement options is by the second user, and wherein the sent request is to order the identified item for the first user such that payment infoπnation of the procurement option associated with the selected indication wih be used to purchase the identified item and such that dehvery infoπnation associated with the first user wih be used to dehver the identified item to the first user.

88. The computer-readable medium of claim 87 wherein the sent request indicates to order the identified item as a gift for the first user.

89. The computer-readable medium of claim 87 wherein the displayed information and the displayed indications are part of a Web page displaying a wish hst of the first user.

90. The computer-readable medium of claim 87 wherein the sent request is additionahy such that shipping instructions of the procurement option associated with the selected indication wih be used to ship the identified item to the first user.

91. The computer-readable medium of claim 87 wherein the sent request is additionahy such that shipping instructions associated with the first user wih be used to ship the identified item to the first user.

92. The computer-readable medium of claim 87 wherein the sent request is additionahy such that wrapping instructions of the procurement option associated with the selected indication wih be used to wrap the identified item before the identified item is dehvered to the first user.

93. The computer-readable medium of claim 87 wherein the sent request is additionahy such that a message supphed by the second user wih be dehvered to the first user in addition to the identified item.

94. The computer-readable medium of claim 87 wherein the payment infoπnation of the procurement option associated with the selected indication wih be used to purchase the identified item for the first user only when a cost of the identified item is below a specified threshold.

95. The computer-readable medium of claim 87 wherein the contents further cause the computing device to display a second indication selectable by the second user, the displayed second indication such that at least one option about supplying of the item is to be displayed before the sending of the request if the displayed second indication is selected when the performing of the indicated single action occurs.

96. The computer-readable medium of claim 56 wherein the computer-readable medium is a data transmission medium fransnhtting a generated data signal containing the contents.

97. The computer-readable medium of claim 56 wherein the computer-readable medium is a memory of a computer.

98. A computer system for ordering an item comprising: a display component able to display information identifying the item and able to display an indication of multiple procurement options each having sufficient information to complete an order for the identified item, each procurement option such that selection of the procurement option represents using the information of the procurement option for ordering of the identified item; and an item ordering component able to, after a procurement option is selected, send to a server computer a request to order the identified item using the information of the selected procurement option.

99. The chent system of claim 98 wherein the multiple procurement options are ah associated with a user, wherein each of the procurement options has a group of predefined order fulfillment information that includes a dehvery address, shipping instructions, and a payment source, and wherein the ordering of the identified item using the infoπnation of the procurement option for the selected indication is such that the identified item is to be sent to the dehvery address for that procurement option using the shipping instructions for that procurement option and is to be paid for by the payment source for that procurement option.

100. The chent system of claim 98 wherein the procurement option for the selected indication includes payment information, and wherein the sent request is additionahy to purchase the identified item using the payment information.

101. The chent system of claim 98 wherein the procurement option for the selected indication includes a dehvery address, and wherein the sent request is additionahy to dehver the identified item to the dehvery address.

102. The chent system of claim 98 wherein the procurement option for the selected indication includes shipping instructions, and wherein the sent request is additionahy to dehver the identified item as specified by the shipping instructions.

103. The chent system of claim 98 wherein the display component is further able to display an indication to add the identified item to a cohection of items for later ordering.

104. The chent system of claim 98 wherein the display component is further able to display an indication representing creation of a new procurement option, and wherein, after selection of the displayed indication representing the creation of the new procurement option, the ordering of the identified item includes receiving infoπnation identifying a dehvery address for the new procurement option such that the sent request is to order the identified item to be sent to the identified dehvery address.

105. The chent system of claim 104 including creating the new procurement option with the identified dehvery address as part of the new procurement option.

106. The chent system of claim 104 wherein the received information identifying the dehvery address is information indicating an identity other than a user performing the selection of the displayed indication representing the new procurement option, and including retrieving address information for the identity to be used as the identified delivery address.

107. The chent system of claim 106 wherein the received information is an electronic mail address for the identity.

108. The chent system of claim 104 wherein payment infoπnation is received prior to the selection of the displayed indication representing the creation of the new procurement option, and wherein the sent request to order the identified item specifies that the item is to be paid for by the received payment information.

109. The chent system of claim 98 wherein each displayed indication of a procurement option includes partial shipping information of the procurement option.

110. The chent system of claim 98 wherein each displayed indication of a procurement option includes partial payment information of the procurement option.

111. The chent system of claim 98 wherein each displayed indication of a procurement option includes a moniker identifying the procurement option.

112. The chent system of claim 98 wherein the display component is further able to display an indication of a single action that is to be performed to order the identified item using the information of a cunent procurement option, wherein the selection of the displayed indication of one of the procurement options selects that procurement option as the cunent procurement option, and wherein the sending of the request to the server computer is in response to a received indication of the single action being performed.

113. The chent system of claim 98 wherein the display component is further able to, before the sending of the request, display an indication of an option related to supplying of the item.

114. The chent system of claim 113 wherein the display component is further able to, before . performance of the indicated single action, display a selectable indication of whether to specify an option about the supplying of the item, and wherein the displaying of the indication of the option occurs only when the displayed indication of whether to specify an option is selected when the indicated single action is performed.

115. The chent system of claim 98 wherein the displayed information and the displayed indication of the single action are part of a Web page for ordering the indicated item.

116. The chent system of claim 98 wherein the identified item is indicated to be desired by a first user, wherein each of the multiple procurement options are associated with a second user to whom the information identifying the item is displayed, wherein the selection of a displayed indication of one of the procurement options is by the second user, and wherein the. sent request is to order the identified item for the first user such that payment information of the procurement option associated with the selected indication wih be used to purchase the identified item and such that dehvery information associated with the first user wih be used to dehver the identified item to the first user.

117. The chent system of claim 116 wherein the sent request indicates to order the identified item as a gift for the first user.

118. The chent system of claim 116 wherein the displayed information and the displayed indications are part of a Web page displaying a wish hst of the first user.

119. The chent system of claim 98 further comprising: a sending component able to send to the display component an indication of an item that may be ordered and an indication of multiple procurement options each having associated information for completing an order for the identified item; and a receiving component able to receive from the item ordering component an indication that one of the multiple procurement options was selected and able to, after receiving an indication to order the identified item from the item ordering component and without further intervention, dehver the identified item to a recipient specified by the selected procurement option in a manner specified by the selected procurement option.

120. A computer-readable medium containing a data structure for use in ordering an item, the data structure comprising: a plurahty of indications of multiple procurement options each having sufficient information to complete an order for an item, so that a user can perform a selection of the indication of one of the procurement options to indicate to use the information of the procurement option when ordering the item.

121. The computer-readable medium of claim 120 wherein each procurement option includes a dehvery address, shipping instructions, and a payment source.

122. The computer-readable medium of claim 120 wherein each procurement option is a unique combination of dehvery and payment information for a single user.

123. The computer-readable medium of claim 120 wherein the data structure includes an indication of the item.

124. A method for ordering an item using a chent system, the method comprising: displaying information identifying the item and displaying an indication of a single action that is to be performed to order the identified item; and in response to the indicated single action being performed, displaying an indication of an option related to supplying of the item; and sending to a server computer a request to order the identified item.

125. The method of claim 124 including receiving an indication that the indicated option is selected by a user, and wherein the sent request includes an indication of the selected option.

126. The method of claim 124 wherein the displayed indication of the single action is selectable by a user to order the item for another user.

127. The method of claim 124 wherein the displayed indication of the single action is selectable by a user in order to specify options about the supplying of the item.

128. The method of claim 124 wherein the displayed indication of the single action is selectable by a user to order the item as a gift.

129. The method of claim 124 including, before the performing of the indicated single action, displaying a selectable indication of whether to specify an option about the supplying of the item, and wherein the displaying of the indication of the option occurs only when the displayed indication of whether to specify an option is selected when the indicated single action is performed.

130. The method of claim 124 wherein the indicated option relates to payment information with which the identified item whl be purchased.

131. The method of claim 124 wherein the indicated option relates to dehvery information with which the identified item wih be dehvered.

132. The method of claim 124 wherein the indicated option relates to shipping instructions according to which the identified item wih be shipped.

133. The method of claim 124 wherein the indicated option relates to wrapping instmctions according to which the identified item wih be wrapped.

134. The method of claim 124 wherein the indicated option ahows a message to be supphed that wih be dehvered in addition to the identified item.

135. The method of claim 124 including displaying an indication to add the identified item to a cohection of items for later ordering.

136. The method of claim 124 wherein the displayed infoπnation and the displayed indication of the single action are part of a Web page for ordering the indicated item.

137. The method of claim 124 wherein the displayed infoπnation and the displayed indication of the single action are part of a Web page for displaying a shopping cart of a user.

138. A computer-readable medium whose contents cause a computing device to order an item, by: displaying infoπnation identifying the item and displaying an indication of a single action that is to be performed to order the identified item; and in response to the indicated single action being performed, displaying an indication of an option related to supplying of the item; and sending to a server computer a request to order the identified item.

139. A computer system for ordering an item comprising: a display component able to display infoπnation identifying the item and able to display an indication of a single action that is to be performed to order the identified item; and an item ordering component able to, in response to the indicated single action being performed, display an indication of an option related to supplying of the item and send to a server computer a request to order the identified item.

140. A method for ordering an item using a chent system, the method comprising: displaying infoπnation identifying an item indicated to be desired by a first user; displaying an indication of a single action that can be performed by a second user to order the identified item for the first user; and in response to the indicated single action being performed by the second user, sending to a server computer a request to order the identified item for the first user such that payment information associated with the second user wih be used to purchase the identified item and such that dehvery information associated with the first user wih be used to dehver the identified item to the first user.

141. The method of claim 140 wherein the displayed indication of the single action is selectable by the second user to order the identified item as a gift for the first user.

142. The method of claim 140 wherein the displaying information and the displayed indication are part of a Web page displaying a wish hst of the first user.

143. The method of claim 140 wherein the sent request is additionally such that shipping instructions associated with the second user wih be used to ship the identified item to the first user.

144. The method of claim 140 wherein the sent request is additionahy such that shipping instructions associated with the first user wih be used to ship the identified item to the first user.

145. The method of claim 140 wherein the sent request is additionahy such that wrapping instructions associated with the second user wih be used to wrap the identified item before the identified item is dehvered to the first user.

146. The method of claim 140 wherein the sent request is additionahy such that a message supphed by the second user whl be dehvered to the first user in addition to the identified item.

147. The method of claim 140 including displaying an indication to add the identified item to a cohection of items for later ordering.

148. The method of claim 140 wherein the payment information associated with the second user wih be used to purchase the identified item for the first user only when a cost of purchasing the identified item is below a specified threshold.

149. The method of claim 140 including displaying a second indication selectable by the second user, the displayed second indication such that at least one option about supplying of the item is to be displayed before the sending of the request if the displayed second indication is selected when the performing of the indicated single action occurs.

150. A computer-readable medium whose contents cause a computing device to order an item, by: displaying infoπnation identifying an item indicated to be desired by a first user; displaying an indication of a single action that can be performed by a second user to order the identified item for the first user; and in response to the indicated single action being performed by the second user, sending to a server computer a request to order the identified item for the first user such that payment information associated with the second user wih be used to purchase the identified item and such that dehvery information associated with the first user wih be used to dehver the identified item to the first user.

151. A computer system for ordering an item comprising: a display component able to display information identifying an item indicated to be desired by a first user an indication of a single action that can be performed by a second user to order the identified item for the first user; and an item ordering component able to, in response to the indicated single action being performed by the second user, send to a server computer a request to order the identified item for the first user such that payment information associated with the second user wih be used to purchase the identified item and such that dehvery infoπnation associated with the first user wih be used to dehver the identified item to the first user.