WO2001001314A2

WO2001001314A2 - Method and apparatus for e-commerce enabling an object

Info

Publication number: WO2001001314A2
Application number: PCT/US2000/017905
Authority: WO
Inventors: Lee J. Lorenzen; Jordan Zimmerman
Original assignee: Catalog City, Inc.
Priority date: 1999-06-30
Filing date: 2000-06-28
Publication date: 2001-01-04
Also published as: AU6339300A; WO2001001314A8

Abstract

A method and apparatus for e-commerce enabling a target object, wherein the target object might include a product displayed on a web page, in a banner ad, or within an e-mail message. A multi-vendor central server (or system) is provided whereby merchant vendors register with the central server, and provide information thereto. The merchant vendor might supply catalog information for display to a customer. The merchant vendor then provides a description of the target object, and a linking code generator provides code which links that target object back to the central server. The linking code can be copied by the merchant vendor and associated with the target object in a presentation format accessible by a customer. If the customer selects the object, then the customer will be linked back to the central server to facilitate completion of an e-commerce transaction. The target object information might be stored in a database or the like associated with the central server, or associated with the merchant vendor. The amount of information passed back in the linking code will depend upon where the target object information is being stored. If the information is stored with the central server, then a short-form identifier can be passed back, and the central server can use this identifier to retrieve information for the database. More information will need to be linked back if the information is stored (in large part) with the merchant vendor.

Description

added convenience might serve to attract more visitors to investigate and consider buying a certain product.

Entering the world of e-commerce, however, carries with it certain obstacles and costs for a merchant wishing to offer a product. A merchant might first create a website and advertise the URL (uniform resource locator) to the public in order for them to find and peruse what the site has to offer. If a customer wishes to purchase a particular product (or a group of products), the merchant needs to provide a means to gather and compile information about the products to be purchased. This e-commerce device is often referred to as a "shopping cart" wherein a list of selected items can be tracked and viewed.

Information about the customer is collected through electronic forms and the like. Such information includes the customer's name, address, shipping address, credit card number, etc. Such information should ideally be stored in a database in order to prevent repeat users from having to re-enter such information if they visit the merchant's site again.

A payment method must also be invoked by the merchant website. Common methods of payment via e-commerce include credit and debit cards. Transferring such highly sensitive information, however, requires special program layers and related certificates referred to as SSL (secure sockets layer). SSL is a program layer created by Netscape, and supported by all major Internet Browsers, for managing the security of message transmissions in a network. Under SSL, programming for keeping messages confidential is contained in a program layer between an application (such as the web browser, or HTTP) and the Internet's TCP/IP layers. The "socket" term refers to a method of passing data back and forth between a client and a server program in a network or between program layers in the same computer. SSL uses public-and-private key encryption, and requires the merchant to apply for an SSL server certificate in order to complete such transactions.

Additionally, the product information must generally be converted into an invoice and sent back to the merchant, who would then apply steps to verify the order as valid and correct with the particular customer. The invoice might be sent to the merchant via email, fax, or regular mail. Upon verification with the customer, the merchant can then invoke the physical shipping of the product to the customer, once payment has been confirmed.

2 Referring now to Figure 1, a prior art block diagram 100 is shown which depicts certain representative functions or capabilities that might need to be added to a merchant website in order to provide e-commerce transactions. A merchant website 102 is shown which has been contacted by a user or customer 104. The customer 104 has indicated the desire for a purchase 106. The base merchant website, however, has only been set up to display products to the customer. In order to become e-commerce enabled, the merchant website should add at least some of the functions shown below the merchant website as elements 1 10-120, via hardware or software or a combination of both, including: adding product selection capabilities 1 10; adding merchandise checkout capabilities 112; adding invoicing and bill payment capabilities 1 14; adding ship-to capabilities 116; and/or adding gift capabilities 118. This list is not meant to be exhaustive, as shown by the continuation arrow 120. Once the website 102 has been e- commerce enabled, the purchase can be fulfilled electronically, as shown by 122, and the user will receive the product.

These various additions to the merchant website, however, can prove to be expensive and cumbersome to invoke. As a result, a simple and inexpensive method and apparatus for e- commerce enabling a website, webpage, banner, or similar advertisement for a product, is needed. The method and apparatus should be relatively simple to invoke and require minimal effort on the part of the merchant. The method and apparatus should also be applicable to other types of electronic advertisements or presentations, including for instance, graphical objects, or objects or text within an email message.

SUMMARY OF THE INVENTION

The present invention relates to a method and apparatus for enabling e-commerce for a target object. The object typically consists of a product displayed or advertised on a webpage. The object might also include, but is not limited to, text within an email message, a click- through banner advertisement on a webpage, or a graphical object located anywhere within a visual display medium or the like.

The present invention utilizes the underlying structure of a Multi-Vendor Internet Commerce System (MV-ICS) which utilizes a Multi-Vendor Central System (MV-CS) which centralizes certain transactions relating to e-commerce operations. The merchant, however, is only required to provide a specialized link back to the MV-CS from the target object. Certain architecture and methods employed by the MV-CS are described in more detail in the cross- referenced application entitled Multi-Vendor Internet Commerce System For E-Commerce Applications And Methods Therefor, filed at the same time as this application.

According to one aspect of the present invention, an MV-CS server provides a website interface for access by the merchant in order to facilitate e-commerce enablement of the merchant's object. This interface is hence referred to as a Multi-Vendor E-commerce Enabling Interface (MV-EEI). A new merchant is prompted for certain initial information regarding the merchant's electronic store name and other identifying information. An identification (ID) and password is provided for the merchant to log onto the MV-EEI. Various account functionalities are presented to the merchant in order to choose a wide offering of feature sets (e.g. age verification, help desk, privacy settings, and the like). Other example account functionality includes contact/billing information, sales tax settings, and payment methods.

More particularly, a merchant can choose to create a link that can be directly applied to a product offering, and thereby e-commerce enables that product. A merchant is prompted for certain information pertaining to a product which the merchant wants to offer for sale. Such information might include, for instance (but is not limited to), the item code, item name, price, and return URL. This information is then used to create at least one separate short segment of HTML (hypertext mark-up language) code (hence referred to as a "snippet") which links back to the MV-CS with a certain identifier, or SKU (stockkeeping unit), for that product. The link might provide certain functionality to enable the customer to "buy" the product. The link might alternatively provide certain functionality to enable the customers to add the product to their own particular "wishlist" or gift registry. This wishlist can later be accessed by another customer who might wish to purchase that product as a gift for the wishlist creator. Any variety of other functionality might also be provided, as dependent upon any of a variety of input parameters, to form the appropriate HTML link according to such input parameters.

According to the present invention, the merchant can then conveniently copy the snippets of code and integrate them into the HTML of the merchant's webpage or brochure. If a click-through "button" is desired, appropriate code can be added by the merchant to present the resulting link as a graphical button to the customer. The button would likely be closely

4 associated with the graphical (or other) presentation of the product for sale. In the case of a "buy button," the customer would click on the button and be re-directed back to the MV-CS in order to complete the e-commerce transaction. As a result, the merchant's webpage or brochure can be fully e-commerce enabled with the simple addition of the snippet code into the appropriate spots on the page. Similarly, the "gift button" can be encoded to present the user with a click-through button (or appropriate graphic or icon) that causes the product to be added to a gift registry.

According to another aspect of the present invention, other standardized links can also be readily obtained by the merchant and copied for addition to a webpage or the like. Example standardized links might include a "view shopping cart" function. The merchant could then incorporate the link into a webpage with appropriate surrounding code that might depict the link as a graphical shopping cart icon, or the like. A customer of that merchant's webpage would then be able to click-through the cart icon and view (or modify) the contents of their shopping cart.

Yet another example of a standardized link might include a "view my account" function. The merchant can copy and incorporate the relevant HTML code into a webpage, along with surrounding code which might depict the link as a click-through option via an appropriate text or a graphical symbol. A click-through by the customer on this symbol will take the customer to his or her own account which has been earlier created on the MV-CS server. If no customer account exists, then the customer will be prompted to create one. The customer will then be able to edit/adjust/modify various aspects of their account information via a simple click-through operation from that merchant's site.

A variety of operational functions might also be offered to the user from the MV-EEI page (or screen). Such functions might include the generation of reports showing performance for various products and/or timeframes. The merchant might also search for, export to, or e- mail certain customers in the customer database.

These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates a prior art block diagram of representative website, and certain functions or capabilities which need to be added in order to enable the website for e-commerce transactions.

Figure 2 illustrates, according to one aspect of the present invention, a block diagram of the Multi-Vendor Central System (MV-CS) being used to generate HTML snippet links that are copied into target objects to e-commerce enable the object.

Figure 3 a illustrates, according to one aspect of the present invention, a block diagram of certain input parameters being used to generate HTML link code for certain functions.

Figure 3b illustrates, according to one aspect of the present invention, a block diagram of the usage of the HTML link code from figure 3 a with further associated coding.

Figure 4 illustrates, according to one aspect of the present invention, a flowchart of certain representative steps follow by a merchant to enable an object using the MV-EEI.

Figure 5 illustrates, according to one aspect of the present invention, a continuation of the flowchart steps from figure 4.

Figures 6 through 26 illustrates, according to one aspect of the present invention, a representative collection of interface screens and associated functionality which might be employed by the MV-EEI implementation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

An invention is described herein for providing an improved method and apparatus for e-commerce enabling the sale of a product (or service) which is presented to a user via a website, webpage, graphical object, e-mail, or other network accessible medium. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art,

6 that the present invention may be practiced without some or all of these specific details. In other instances, well known structures and/or process steps have not been described in detail, so as to prevent unnecessarily obscuring the present invention.

For ease of discussion, the following detailed description is made with reference to a segment of HTML code which is generated according to certain input parameters to provide a link back to a Multi-Vendor Central System (MV-CS). The MV-CS then provides a variety of e-commerce transaction capabilities via this link. Whereas HTML is used in the following examples to illustrate various aspects of the present invention, any other functionally similar language might also be used. Additionally, the MV-CS is shown as a database symbol, but might similarly be implemented as a server, computer with memory, or other such device.

In accordance with one aspect of the present invention, a centralized system is utilized with databasing capabilities; the system hence referred to as the aforementioned MV-CS. The MV-CS provides an interface to a merchant; the interface hence referred as a Multi- Vendor E- Commerce Enabling Interface (MV-EEI). Through this interface, a merchant is prompted for information regarding products to be added to the merchant's store. The information is translated into a small segment, or snippet, of HTML code that provides a link back to the MV- CS according to some function to be performed in relation to the product. The HTML is thereafter copied by the merchant and incorporated into the merchant's particular e-commerce medium, i.e. a website, webpage, email, or the like. The encoded link is further augmented by the merchant to present a click-through icon, or the like, to a customer viewing the link on the e-commerce medium. By clicking-through on the link icon, the customer is able to perform an e-commerce function on the product, with the most obvious example being to actually purchase the product. While certain functions are shown, including buying a linked product, adding a linked product to a gift registry, viewing a centralized shopping cart, and viewing customer account information, a variety of other functions might also be provided via link-type (or other type of) code snippets.

Referring now to Figure 2, a block diagram 200 is shown of certain representative elements which comprise the present invention. A Multi-Vendor Central System (MV-CS) is shown represented as a database 202. The MV-CS is a software and data storage system (all of which might operate and reside on a server — as further described in the application Multi- Vendor Internet Commerce System For E-Commerce Applications And Methods Therefor)

7 which provides certain e-commerce enabling capabilities via an appropriate link back to the MV-CS. An interface 204 (shown as MV-EEI) is provided for generating, among other things, the appropriate links back to the MV-CS. In the preferred embodiment, this interface will consist of a website which presents multiple webpages, the website being accessed via an appropriate URL. In this instance, the URL is shown as http:// mercharit.cataloRcitv.com/mvStores , wherein "myStores" might be any store name chosen by the merchant. A merchant 206 wishes to e-commerce enable a particular product for sale and therefor contacts the interface 204 via a web browser. If the merchant has already created a store on the MV-CS, then the merchant gains access by entering the appropriate store identification and password when prompted. While any of a variety of user identification methods might be used, one embodiment uses the merchant ID and password to verify whether a merchant user has gained prior access and authority. Client-side software or files (i.e. cookies) might also be used, along with server-side applications. If a merchant is new to the system, then appropriate prompts are provided in order to establish a new account with that new merchant, and store such information in the appropriate MV-CS database.

Several option choices are presented via the MV-EEI to create HTML links. If the merchants selects, for instance, the option to create Buy and/or Gift links, then the merchant is prompted for appropriate information concerning a particular product. Thereafter, the system generates short segments of HTML code which contain identifying information about the product and a link back to the MV-CS system in order to perform the particularized function specified by the original option to create the link. For instance, a "buy" link will provide a link back to the MV-CS which enables a customer to buy the identified product. A "gift" link will provide a link back which enables a customer to add the product to a gift registry so the some other party might purchase the product for them.

The short segment of HTML code, also referred to as a "snippet" of code, is presented to the merchant in a convenient format whereby the merchant can copy the snippet and add it to the merchant's e-commerce medium of choice, as shown by 208. For instance, a banner ad 210 might be presented to the user for a particular product. By associating the copied HTML snippet in a click-through fashion with the graphical representation of the banner ad. a user 230 can invoke e-commerce purchase of the associated product simply by clicking on the banner ad. A return link 21 1 is provided which contains appropriate identifiers of the product (e.g. a

SKU), as well as the e-commerce type function to be performed.

8 A more typical example includes a webpage 212 which displays a particular product. Such webpages might include catalog pages or the like for a merchant. The copied HTML is incoφorated into the HTML of the webpage, and additional HTML code is added to present the link to the user in a desired fashion. A click-through button, or icon, might be presented which is closely associated with a picture and description of the product. By clicking-through on this link, the user 230 is linked back via 213 to the MV-CS with identifiers for the product SKU and e-commerce function.

The present e-commerce enabling system is not limited to webpages, banner ads, or other HTML or web browser type arrangements of information. An email message can also contain a link to a particular URL. As such, the HTML link (or other similar language for providing an corresponding link) can be generated and copied into an appropriate area of an email message 214. The email message might then be used to advertise a product, through mass mailings and the like. If successful, the customer will be enticed to buy the product, or alternatively add it to their gift registry for purchase by another party. By directly embedding the link in an email message, the product is conveniently e-commerce enabled via the link back 215 to the MV-CS. In this instance, the merchant does not necessarily need a website or associated webpages, and as such, this form of e-commerce enablement might provide a wider set opportunities for merchants.

Along similar lines, other devices or displays 216 might be used to provide the link back 217 to the MV-CS 202. For instance, a merchant might even operate without e-mail if a call center were created to receive the enabling information from the merchant and create an appropriate link back via the call center computer. A customer might also use the call center to place an order, with the e-commerce link back invoked by the call center.

Referring now to Figure 3a, a block diagram 300 is shown of the present system wherein the MV-EEI 302 receives a variety of input parameters pertaining to product information, and these parameters are used to generate links to perform certain e-commerce enabling functions. For example purposes, the merchant is prompted for information including, but not limited to. the item code 304, the item name 306, the price 308, and a return URL 310. As shown, other input parameters 312 might also be used. The information is then processed (via the MV-CS) to generate HTML code links back to the MV-CS. Any of a wide variety of links and functionality might be provided. In element 314, HTML code is shown to

9 enable a "buy" link back to the MV-CS. Element 316 shows the generation of HTML code for a "gift" link. Element 318 shows the generation of HTML code for other type e-commerce enabling links.

Referring now to Figure 3b. a block diagram 350 is shown of certain representative steps which might be employed by a merchant to incoφorate and use the generated HTML link from figure 3a. Element 352 shows the HTML code coming from the MV-EEI. As indicated by 353, the HTML code contains a SKU (shopkeeping unit) to the item in the MV-CS database. A SKU is an identification, usually alphanumeric, of a particular product that allows the product to be tracked for inventory puφoses. Typically, a SKU is associated with any purchasable item in a store or catalog. For example, a woman's blouse of a particular style and size might have an SKU of "3726-8", meaning "Style 3726, size 8." The SKU identification for a product may or may not be made visible to a customer. A SKU is generally not the same as a product model or number from a manufacturer, although the model number could form all or part of the SKU. In this case, the SKU is established by the merchant a represents a unique identifier to the particular item which the merchant desires to e-commerce enable.

It should be noted that while a short alphanumeric SKU can be provided by the HTML to identify the product, longer identifiers are also intended to be included within the scope of the invention. For instance, a variety of fields might be included in the link back message to the MV-CS. These fields might include, for instance, the e-commerce function, item identifier, price, quantity, return URL link, item name, merchant identification number, and a short description of the product. For a product such as a T-shirt, the fields might resemble: [shopping cart][T001-XL-B][5][19.99][newstore.com][T-shirt][N001][100% cotton T-shirt with logo], wherein this string represents a shopping cart function for 5 extra-large blue 100% cotton T-shirts with a logo, the price being $19.99, with the T-shirts coming from the merchant newstore.com. These collective fields can be figuratively referred to as a "universal bar code" (UBC) for the product. It should also be noted that the link back message to the MV-CS can also contain merchant login information, graphical objects for display, or an endless variety of other information which can be parsed by the receiving MV-CS to provide e-commerce enablement for the associated product. The length of the link message back to the MV-CS will depend, in large part, upon where the product information is databased or stored. If a series of

SKU identifiers is databased on the MV-CS, then a short SKU identifier can be sent back to pull up this information from the appropriate MV-CS database. If, however, the majority of

10 the product information is databased on the merchant's machine, then more information must be provided to the MV-CS in order to identify and e-commerce enable the product.

For instance, depending on the amount of information already furnished to the Multi- Vendor Internet Commerce System (MV-ICS), the amount of information necessary to uniquely identify the merchandise item selected may vary widely. At one end of the scale, databases centrally implemented at the Multi-Vendor Central System (MV-CS) may allow the vendor to simply send a unique identification code associated with the selected item through the vendor-site I/O module to the Multi-Vendor Central System (MV-CS) and all information pertaining to the vendor profile and the product information can be derived therefrom using the unique identification code as a search key into the centrally implemented databases at the Multi-Vendor Central System (MV-CS). At the other end of the scale, there may be little information at the centrally-implemented Multi-Vendor Central System (MV-CS) and the link may be employed to furnish all textual description, graphics, and price information pertaining to the selected items, along with as much of the vendor profile as necessary for the Multi- Vendor Central System (MV-CS) to perform the checkout process (which includes calculating the cost correctly for the item selected for purchase). The artisan will recognize that there are variations between these two extremes.

Referring again to Figure 3b, element 354 shows that the merchant can add associated code to display the link as a button, text, graphic, or the like. In its link form, the HTML code will generally not provide a viewable object for the user. While a viewable object (i.e. an icon) could easily be generated with the copied HTML code, such objects are generally left up to the merchant to add to their particular e-commerce medium. This provides maximum flexibility when incoφorating the link into a webpage or the like. The link code can thereby be associated with a click-through graphic which resembles a button. Alternatively, a picture of the product itself might serve as a click-through graphic or the like for selecting the e- commerce enabled product.

With many e-commerce enabled products, a variety of sizes, shapes, and colors often exist, and these differences must be delineated in order to present a unique order for a particular product. Decision block 356 shows the situation where multiple choices exist for an item (or function). If multiple choices exist, then additional code can be added by the merchant, as shown in step 358, to prompt the user for such differentiating choices between the

11 items. Pop-up and pull-down menus and the like can be provided in order to collect information such as size, color, etc. Once the customer navigates through such associated choices to thereby identify a specific product, the link is presented (or displayed) 360 to the customer in some fashion. As described above, the SKU or product identifier can take on many forms. A SKU will often consists of a block of data which has been reserved for variations of a particular product. Element 362 shows the creation of a SKU block including items 1-10. Step 364 describes the generalized process of modifying or mapping the SKU to match the customer's choices. Mapping can be achieved via a table lookup, string translation, or other similar process. As such, element 366 shows SKU iteml mapping to a "green" version of the product, and SKU item2 mapping to a "blue" version, and so forth. Once an appropriate SKU has been created, the customer can be directed back to the MV-CS via step 368 in order to complete the e-commerce transaction or function.

Referring now to Figures 4a and 4b, a flowchart 400 is shown of certain representative steps which might be used by a merchant to interact with the MV-EEI of the present invention. After the start terminator 402, the merchant contacts the MV-EEI 404 via a web browser or the like. The merchant is presented with store creation and sign-on options. Decision block 406 queries whether the merchant is new to the system or not, based upon merchant ID and password identifiers. If the merchant is new, step 408 shows the merchant being prompted for store identification and password information. If the merchant has completed this process, the merchant is able to enter the main menu 410 by entering the ID and password for the merchant's store. The main menu presents a variety of information, including the ability for the merchant to edit and/or modify the merchant's account information as shown in step 412. The merchant is also given the option to select certain operational functions in step 414, including for instance report generation and the like.

In step 416, the merchant selects one of a variety of functions to invoke generation of

HTML code with links back to the MV-CS. Step 418 shows the selection of Buy/Gift buttons (or links). Step 420 shows the selection of standard links. Referring now to figure 4b, a continuation of the flowchart from connector points A and B is shown. In step 422, the interface prompts the merchant for item identification information. This information is thereafter used to generate Buy or Gift HTML links in step 424 which link that particular item back to the MV-CS. In step 426, the merchant copies the Buy/Gift HTML code and incoφorates it into an appropriate e-commerce medium, such as a webpage. Step 428 shows

12 the user invoking the link invoke the e-commerce enabling function presented by the button or graphic associated with the link. In this example, the invokes a purchase of the item through the MV-CS. In step 436, the user is thereafter returned to the merchant site for subsequent purchases on that site. The customer might also navigate onward to other sites and URLs.

Step 430 shows the generation of standardized HTML links which provide e-commerce enabling functions via a link back to the MV-CS. Such functions might include viewing the customer's shopping cart, or viewing/modifying the customer's account information. Given that such operations or functions are "standardized," they don't generally require any further prompts for information from the merchant. Step 432 shows the merchant copying the standardized HTML code and incoφorating the code into the merchant's particular e- commerce medium. In step 434, the user invokes the link to activate the associated function. As above, the user is thereafter returned to the merchant site in step 436 for subsequent purchases or continued navigation.

The aforementioned gift registry services can be invoked via a "g" being sent in the appropriate field of the link return message to the MV-CS (as opposed to an "s" for a sale). The registry also provides the ability for a plurality of gifts to be selected from different merchants who are registered on the MV-CS. The gift recipient is therefore able construct their own personal list of desired gifts, rather than relying on pre-packaged aggregates of related goods. The customer then buys one (or many) of these potential gifts for gift recipient. If gifts are purchased off the registry, then the registry is appropriately decremented to reflect the fulfillment of those gift requests. Certain other features will be revealed in the discussion of the sample MV-EEI pages below.

Referring now to figure 6, the introductory page 600 of the MV-EEI website is shown. For the ongoing examples, the merchant interface is entitled "myStores," yet it might be any other convenient marketing name or pneumonic. A click-through area 602 allows a merchant to become a member of the centralized network, or database (i.e. MV-CS). If the merchant is already a member, click-through area 604 allows the merchant to edit a store already created. Click-through area 606 shows a sample pop-up product demonstration, as similar to the above described banner ad. A separate window is generated which shows the offered product and description. If the customer clicks on the appropriate link, the customer is directed back the MV-CS for purchase of the shown product. Hence, by placing a banner ad on the website of

13 another party, a merchant can become e-commerce enabled without necessarily having to maintain their own website.

Figure 7 shows the sign-in page which results from clicking on area 602 in figure 6. A store name, ID, password, and email address are requested from the merchant, with a URL being assigned as the website for that online store.

Figure 8 shows a confirmation page after a store has been created, with a click-through 802 to an introduction process.

Figure 9 shows a login page which requires the store ID and password to enter the store account.

Figure 10a shows a first version of the myStores main menu for the example store

"newstore", along with the features which are accessible by the merchant account holder to e- commerce enable a product.

Figure 10b shows an alternative version of the myStores main menu for the example store "World of Clothes." This menu includes additional myStores hosted features, including "add a product," "edit a product," "remove product," etc. Such additional features, while generally applicable to any store, are more common to stores which utilize myStores to host store and product data. This is in contrast to the menu of figure 10a, wherein a merchant simply e-commerce enables a product with a link to the MV-CS via the copied HTML link code.

Figure 1 1 shows a list of features which can be activated via toggling the flag next the item shown. For instance, age verification would provide an added level of inquiry regarding the age of a customer purchasing an e-commerce enabled product through the myStores system.

Figure 12 shows a page which allows the merchant to edit the contacts associated with billing, customer service, order processing, and web information. In this example, the orders are delivered to the merchant via Fax. Field 1202 additionally allows the merchant to select when such Fax orders will be received, according to that merchant's preference. If "immediately" is chosen, then the orders will be sent immediately upon being received and prcoessed.÷

14 Figures 13a and 13b show pages which allow the merchant to edit the sales tax settings for each state, with the default being no tax for Internet- type transactions. Upon making the setting for each state, the sales tax is computed automatically based upon the location of the customer purchasing the item.

Figure 14 shows a page which facilitates changing the password for the store.

Figure 15 shows a page which facilitates editing the payment methods allowed by the merchant.

Figure 16 shows the page which results from the merchant clicking on the option "Get HTML for Buy/Gift Buttons" from Figure 10a. On this page, the merchant is prompted for certain information pertaining to the product, including the item code, item name, price, and return URL. Upon entering the information in these fields, the merchant thereafter clicks on area 1602 entitled "Get HTML."

Figure 17 shows the resulting page after area 1602 is invoked in figure 16. A first snippet of HTML code 1702 is provided for a "buy" URL link referred to as "myBuy." A clickthrough area 1704 is provided to try the result produced by clicking on the myBuy button. In this example, the HTML returns a command of "s" (cmd=s) and a shorten sku=newstorel23. A second snippet of HTML code 1706 is provided for a "gift" URL link referred to as "myGift." A clickthrough area 1708 is provided to try the result produced by clicking on the myGift button. In this case, cmd=g, and sku=newstorel23. The HTML can be copied from each window 1702 and 1706 in order to construct links on the merchant's e-commerce platform. The product identification fields are reiterated below as 1710 in order to enter new products and create further HTML links.

Figure 18 shows the result of clicking on the "Get HTML for standardized links" from figure 10a. The relevant HTML to link to the function "view shopping cart" is shown in box 1802. The click-through area 1804 allows the merchant to try the result produced by clicking on the merchant created and associated shopping cart button or icon. The relevant HTML to link to the function "my Account" is shown in box 1806. The click-through area 1808 allows the merchant to try the result produced by clicking on the merchant created and associated customer account button or icon.

15 Figure 19 shows the result of trying the myBuy button from figure 17, and clicking on the area 1704. As shown, this pulls up a shopping cart for the user, with the linked item added to the customers cart. The customer is given a click-through option 1902 to go back to the source and view the "Great item." The customer can further change the item via click-through 1904, or remove the item via click-through 1906. Click-through area 1908 allows the customer to continue shopping, via returning the customer to the original merchant's site. Click-through area 1910 allows the customer to checkout via secure options. Typically, the last merchant visited will have their logo displayed at 1912, so that the shopping cart might appear to belong to that merchant. Other methods might also be used to prioritize selection of the shopping cart logo. For instance, if 3 items are in the shopping cart, and one item is more expensive, then that merchant's logo might prevail. Additionally, the merchant with the largest quantity of items might prevail.

Figure 20 shows a gift registry screen which results from trying the myGift button 1708 in figure 17. The gift registry provides user options including "edit this registry," "find someone else's registry," and "create a new registry." Options similar to 1902, 1906, and 1908 are provided for the registry listed product.

Figure 21 shows the page resulting from choosing the "create new registry" option of figure 20. The registry is capable of tracking multiple events, and provides convenient pulldown menus for common field entries.

Figure 22 shows the page resulting from choosing the "find a registry" option from figure 20.

Figure 23a shows the various options available to a customer in editing and tracking their account on the MV-CS. Figure 23b shows an example of one such feature which lets the user edit their address book.

Figure 24 shows the result of clicking on the Reports option from figure 10a. Click- through area 2402 provides a user guide for such reports. Figures 25a-251 show the example pages from this user guide.

Figure 26 shows the results of clicking on the "send e-mail" option of figure 10a. The myStores site will then receive feedback from the customer.

16

Claims

What is claimed is:

1. A method for e-commerce enabling target objects as supplied by a plurality of merchant vendors that interact with a multi-vendor central server, the method comprising: registering each merchant vendor with the multi-vendor central server; querying each merchant vendor for target object identifier information; and generating linking code for the target object which provides a link back to the multi- vendor central server, whereby the merchant vendor copies the linking code and associates the linking code with a target object, a customer thereafter selecting the target object and invoking the link back to the multi-vendor central server.

2. The method of Claim 1, wherein the multi-vendor central server provides e- commerce related functions.

3. The method of Claim 2, wherein the e-commerce related functions relate to the target object.

4. The method of Claim 2, wherein the e-commerce related functions relate to a customer account.

5. The method of Claim 1 , wherein the target object is part of a catalog that has been stored on the central server.

6. The method of Claim 1, wherein the target object includes an item displayed on a web page.

7. The method of Claim 1 , wherein the target object includes a banner advertisement on a web page.

17

8. The method of Claim 1 , wherein the target object includes an email message.

9. The method of Claim 1 , wherein the linking code is HTML.

10. The method of Claim 9, wherein the HTML linking code is copied into an HTML document.

11. The method of Claim 1 , wherein the target object identifier information is stored in a storage means associated with the central server.

12. The method of Claim 1 1, wherein the storage means includes a database and the target object identifier information is mapped to an identifier into the database.

13. The method of Claim 12, wherein the identifier into the database includes at least a merchant identifier parameter and a target object identifier parameter.

14. The method of Claim 13. wherein the target object identifier parameter includes a shopkeeping unit (SKU).

15. The method of Claim 12, wherein the linking code includes the identifier into the database for use by the central server to identify the target object.

16. The method of Claim 1. wherein at least a portion of the target object identifier information is stored in a storage means associated with the merchant vendor.

18

17. The method of Claim 13, wherein the target object identifier information includes a plurality of fields.

18. The method of Claim 17, wherein the linking code includes at least some of the fields for use by the central server to identify the target object.

19. An apparatus for e-commerce enabling target objects, the apparatus comprising: an multi-vendor central server; a plurality of merchant vendors that register and interact with the multi-vendor central server; a linking code generator, whereby a merchant vendor supplies information about the target object and the linking code generator supplies code for linking the target object back to the multi-vendor central server; and a target object presentation means, whereby the linking code is copied and associated with the target object, and whereby selection of the target object by a customer through the presentation means will link the customer back to the multi-vendor central server.

20. The method of Claim 19, wherein the multi-vendor central server provides e- commerce related functions.

21. The method of Claim 20, wherein the e-commerce related functions relate to the target object.

22. The method of Claim 20, wherein the e-commerce related functions relate to a customer account.

23. The apparatus of Claim 19, wherein the information about the target object is part of a catalog for the merchant vendor.

19

24. The apparatus of Claim 19, wherein the information about the target object is stored in a storage means associated with the central server.

25. The apparatus of Claim 24, wherein the storage means includes a database which maps the target object information to a database identifier.

26. The apparatus of Claim 25, wherein the code for linking the target object back to the multi-vendor central server includes at least the database identifier.

27. The apparatus of Claim 19, wherein the information about the target object is stored in a storage means associated with the merchant vendor.

28. The apparatus of Claim 27, wherein the information about the target object includes a plurality of fields.

29. The apparatus of Claim 28, wherein the code for linking the target object back to the multi-vendor central server includes at least some of these fields.

20