WO2000060502A1

WO2000060502A1 - Method of constructing a buyer-specific vendor list

Info

Publication number: WO2000060502A1
Application number: PCT/US2000/009086
Authority: WO
Inventors: Martin E. Anenberg; Robert K. Sanborn
Original assignee: Cynaptec, Inc.
Priority date: 1999-04-06
Filing date: 2000-04-06
Publication date: 2000-10-12
Also published as: WO2000060502A9; AU4202000A

Abstract

A file identifying preferred vendor information is received from a buyer. The preferred vendor information includes names of the preferred vendors. The preferred vendor information is added to an HTML page to produce the preferred vendor list (252). The preferred vendor list can be linked to other on-line purchasing tools used by the buyer. The preferred vendor information can be removed from the file by checking the accuracy of the preferred vendor information through a comparison of the preferred vendor information to vendor information stored in a database (260) and substituting the stored vendor information for the preferred vendor information if it is determined that the preferred vendor information is inaccurate. Competitive vendor data for the preferred vendor information can be generated and associated with the preferred vendor list (266).

Description

METHOD OF CONSTRUCTING A BUYER-SPECIFIC VENDOR LIST

BACKGROUND OF THE INVENTION

The present invention relates to electronic commerce. Since the Internet has been open to commercial use, its popularity has grown as businesses recognized its potential impact to business-to-consumer transactions. Also driving Internet usage are business-to-business transactions. For example, businesses use the World Wide Web to locate information about products and services.

Today there are many one-to-one marketing systems catering to this market. These types of systems allow a user such as a procurement specialist to find a particular product from a vendor in that vendor's on-line catalog. Many companies with on-line catalogs utilize Web transaction servers coupled to their on-line catalogs to communicate with a user's Web browser and their own internal applications to provide such functions as a virtual shopping cart, order entry, order tracking and payment. Others satisfy the demand by collecting and scanning publicly available catalogs to produce CD-ROM catalogs. The added value in this approach is in the product categorization and parametric search functionality. Another technique is the use of an on-line directory publisher. An on-line directory publisher such as Thomas Register or Cahner's produces and manages on-line catalogs . Additionally, such program developers as

PurchasePro and Industry. Net provide on-line services that target a specific industry segment and allow buyers and vendors, both limited in number, to exchange information and conduct transactions on-line. SUMMARY

According to an aspect of the invention, a method of constructing a preferred vendor list for use by buyers engaging m on-line purchasing communications with vendors includes receiving a file identifying preferred vendor information from a buyer, the preferred vendor information including names of the preferred vendors, and adding the preferred vendor information to an HTML page to produce the preferred vendor list. The preferred vendor list may be linked to other on-line purchasing tools used by the buyer.

The preferred vendor information may be removed from the file by checking the accuracy of the preferred vendor information by comparing the preferred vendor information to vendor information stored in a database and substituting the stored vendor information for the preferred vendor information if it is determined that the preferred vendor information is inaccurate. The method further can include generating competitive vendor data for the preferred vendor information and associating the generated competitive vendor data with the preferred vendor list. The associating may include adding the generated competitive vendor data to the HTML page. Alternatively, the preferred vendor list can include a heading that is a hypertext link and associating can include linking the generated competitive vendor data to the preferred vendor list via the heading. The competitive vendor data can be generated by: accepting vendor information from individual users; classifying the accepted vendor information by category; storing m a database m association with the classification the accepted information; searching the database based on the category classification and retrieving the accepted information associated with category classification in response to a user request for the preferred vendor list; and providing the information corresponding to the category classification to the preferred vendor list for use as competitor vendor information.

The method can also include receiving a search request for a product category from a user, returning a list of vendors to the user and enabling the user to select vendors from the list of vendors to be added to the preferred vendor list.

One or more of the following advantages may be provided from aspects of the invention.

The preferred vendor page mechanism of the invention provides individual users within a company or organization with a tool by which they can obtain preferred sourcing information without having to contact their purchasing department. The preferred vendor page may be linked to other on-line purchasing tools, and can be easily updated with select information from other vendors lists produced in response to a user (or buyer) search request.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic view of a networked system for facilitating communications between buyers and sellers. FIG. 2 is a block diagram illustrating software processes employed by the server during a buyer-vendor communication process.

FIGS. 3A through 3K are exemplary screen displays from a Web browser used in rendering pages at the client computer during the buyer-vendor communication process. FIGS. 4A-B are flow diagrams of a server process used in the buyer-vendor communication process.

FIGS. 5A-B are representations of data structures used in the database of the networked system of FIG 1. FIG. 6 is a flow diagram of a "last ditch" advertising process.

FIG. 7 is an exemplary screen shot of a last ditch advertising page.

FIG. 8 is a flow diagram depicting a process of constructing a preferred vendor directory.

FIG. 9 is a flow diagram illustrating a vendor response management portion of the buyer-vendor communication process.

DESCRIPTION

Referring now to FIG. 1, a networked system 10 includes a client system 12 connected to a server 14 and a plurality of vendor systems 16a-lβm via a network 18. The networked system 10 is implemented as a Web-style system that is used to facilitate communications between buyers at client computers such as client system 12 and vendors at the vendor systems 16a-16m over the network 18. In a Web implementation, the network 18 can be the "Internet" and the server 14 a Web server. Private networks can also be used. More particularly, client system 12 receives input from a user (in this case, a potential buyer) via a Web browser 20, which communicates with the server 14 over the network 18. The Web browser 20 renders display output in the form of hypertext markup language (HTML) pages. The Web browser 20 may be any commercially available browser, such as Microsoft Internet Explorer or Netscape Navigator. The vendor computer systems 16 are servers operated and controlled by vendor companies ("vendors") . Also coupled to server 14 is a back-end resource shown here as a database 22 for storing vendor information.

Referring to FIG. 2, the processes that run on the server 14 are shown. The server 14 includes a server computer that executes a server process 30. The server 14 stores information organized into distributed pages 32.

The pages are stored as information encoded into HTML. The manner in which the HTML pages are produced is well known and therefore not discussed herein. In addition to static pages where content does not change, server 14 provides a mechanism for including dynamic information (e.g., from such sources as the database) in pages. The server 14 uses a standard interface called the Common Gateway Interface (CGI) to execute a separate program that obtains the dynamic information, formats it into HTML and forwards it to the server 14. The server 14 also employs the Hypertext Transfer Protocol (HTTP) in transferring pages to and receiving page data from the Web browser 20 via the Internet 18 (from FIG. 1). The server process 20 therefore includes an HTTP server process 33 augmented with CGI-based applications 34. Other protocols of course could be used.

The server process 30 further includes a database search engine 36 that is responsible for storing data m and retrieving data from the database 22 (FIG. 1) m response to queries. The queries are produced by the server 14 based on user-specified data that is received from the client system 12. Collectively, the database search engine 36 and the database 22 may be viewed as a "database system" 38. Although the database search engine is depicted as part of the server process 30, it will be understood that the components of the database system 38 may be integrated, as m a database management system, or include a separate back-end server. Additionally, the server 14 runs an e-mail application 39, used to send e-mail messages to vendors via the Internet, as will be described. Hereinafter, the server 14 and server process 30 will be referred to as the "buyer-vendor communication system" (or, simply, "the system") and the "buyer-vendor communication process (or, simply, "the process") , respectively.

In order to convey the manner in which the buyer- vendor communication system is used, various screen displays of the browser's graphical user interface will now be described with reference to FIGS. 3A-K.

Referring now to FIG. 3A, a sign-on/registration page 40 allows an already registered user to log onto the system by entering appropriate information in an e-mail address field 42 and an password field 44 and clicking the "enter" button 46. The sign-on/registration page 40 also allows a user who has not previously registered with the system to do so by clicking the "click to register" button 48, which brings the user to a purchaser account application page 50, shown in FIG. 3B.

Referring to FIG. 3B, the purchaser account application page 50 has several fields for accepting personal user data. The fields include a name field 52, an e-mail address field 54, phone number fields 56, a fax number field 58 and a password field 60. Additional fields are possible. The information is saved to establish a user account. The user account information is maintained by and stored on the server 14. When the user returns to the site, the user's account information is restored upon successfully entering a user name and password.

Referring to FIG. 3C, a search page 70 sent by the server 14 to the Web browser 20 in response to the earlier-described log-in procedure (FIG. 3A) is shown. The search page 70 allows the user to enter a keyword or keywords in a search field 72 for an item about which the user is seeking information. For example, the user enters as a keyword the word "phone" and hits a "search" button 74.

The search page also includes a "Bid Addendum" button 75, which will be discussed later. With reference now to FIGS. 3D and 3E, the server

14 will return to the user a matching categories page 76. The matching categories page includes a matching categories list 80 generated by the system.

As can be see in FIG. 3D, the server 14 returns all of the categories that it could relate to the word

"phone". Provided in the left hand corner of the page is a matching categories number 82 corresponding to the number of categories that match a particular query. In this example, there are 26 categories that match "phone". Also provided is the total number of suppliers in the matching categories 84, in this case 1,752. The page also provides a total displayed number 86. In the illustrated embodiment, only twenty-five categories per page are displayed. The categories are listed in table format, with matching category names 88 in the left column under a heading "matching categories" and the number of matching vendors 90, that is, the number of vendors that match that category, in the right column under a heading "Number of Vendors in Database". Continuing to use the "phone" example, a user interested in cellular telephone service and repair would scroll down to the "Cellular Telephones-Service & Repair" category (shown in FIG. 3E) . Next to each category name is listed the number of matching vendors in the database 22 that are categorized under that category name. Thus, in the example shown, a number four (4) indicates that the system has four vendors in the category of interest. The user selects a category 88 from the list of matching categories 80 by clicking on the particular category. The category, e.g., "Cellular Telephones-Service & Repair", is provided as a hyperlink that is sent back to the server to set up another database query.

Referring to FIG. 3F, the server 14 returns to the browser 20 a vendor matching page 100 which includes the vendors contained in the database that match the selected category. The vendors are listed in some order, such as alphabetically, or in no order, i.e., random, and in a table format. One column corresponds to a matching vendor name 102. Next to and associated each vendor name is a check box 104 that allows the user to add the vendor with which the check box is associated to a list of vendors that the user wishes to send information to or receive information from. The page can include banner ads linked to vendor listings. There are various subscription types available to the vendor which allow the vendor to have a banner display associated with the vendor's other information (e.g., name, address). Thus, the page can include a check box 104, company (vendor) name, banner or logo (or some combination thereof) 102, information (e.g., on-line catalog) availability 106, status (e.g., minority certification) 108, as well as other information. If the user wishes to request information from or communicate with one or more of the listed vendors, the user checks the names of the desired vendors by selecting the check box 104 next to the vendor's name. Also included in the vendor matching page 100 is an "Add selected vendors to my page" button 110, which will be discussed later with reference to FIG. 8.

In addition to selecting the vendors to make up the list of recipients, the user can select a communication option from one or more communication option selection devices. In the illustrated embodiment, a first communication option selection device 114 is a drop-down communication options menu which includes communication options for requesting vendor response: "request for quotation" 114a, "request for information only" 114b, "request for proposal" 114c or "request for status" 114d (e.g., minority-owned or small business). Other options could be provided. Once the user has made a communication option selection from the menu 114 and clicks on a continue button 116, the server 14 returns a request options page 120, shown in FIG. 3G. Referring now to FIG. 3G, the request options page 120 includes second communication option selection devices 122, which allows the user to fill in a document (form) that the system provides on-line 122a (i.e., a form corresponding to the vendor activity request in drop-down menu 114), attach one of the user's own documents or files 122b or both. For example, if the user would like to send a specification along with an RFQ, the user attaches to the RFQ form the specification or a file. The RFQ and specification (or file) are sent via a single e-mail message to the list of vendors, as determined by the user. As indicated above, the user can choose to fill in an on-line form. The form that the user receives will depend on the option selected in the communication options menu (of FIG. 3F) . Again, the completed form will be sent to the selected vendors on the vendor list.

Still referring to FIG. 3G, the request options page 120 allows the user to set parameters for the request. The parameters include e-mail address change 124 if the user would like to receive vendor responses at an e-mail address other than the default address (i.e., the one to which the cookie preference has been set) . Other options include delivery and expiration dates. A delivery date field 126 specifies the date for receiving the requested information. For example, if the user wishes to receive all of the responses at once, the server 14 can hold them until a pre-set date. Alternatively, the delivery date preference may be set for various intervals such as daily or weekly. One or more expiration date fields 128 specify the "cut-off" date for submissions. The server can have a default, e.g., 40 days, if the user does not enter a date. Additionally, there is a "short e-mail description" field 130 for the entry of a short description. The short description, if entered, will appear in the header (subject line) of the e-mail message the vendors receive. There is also a comments field 132 that allows the user to type in additional comments, free form, similar to a cover letter. The server also has the capability to store transaction history for a fixed period of time (e.g., 6 months) . When that fixed time period expires, the history is provided to the user in some form (e.g., text, MIME or HTML) . Referring back to FIGS. 3F-3G, if the user selects as the communication option an RFQ 114a (FIG. 3F) and chooses a second communication option 122a to fill in an online form (FIG. 3G) , the server 14 returns in response an RFQ page 140 that mimics an RFQ form, as shown in FIG. 3H. The server 14 will carry forward the name and address, add a date and allow the user to enter an RFQ number in an RFQ number field 142. The form has option boxes for delivery requirements 144, terms and conditions 146 and freight-on-board 148. It also has fields in which the user can enter quantity 150 and description 152. Once the user has entered in all of the information for the RFQ, the user clicks on a "submit" button 154.

When the user hits the submit button 154, the server forwards the completed form results to e-mail addresses of each of the selected recipient vendors using the e-mail application 39 (shown in FIG. 2) . The e-mail application utilizes a standard ASCII text format, but could be adapted to use other formats, such as MIME. Alternately, the system may notify a vendor that a bid is waiting for that vendor. In this option, the e-mail notification provides such a vendor with a Web address where the vendor can view the file in HTML format through a browser .

Referring now to FIG. 31, an auditing page 160 is shown. The server 14 provides a printable page listing all of the bid recipients that were selected (i.e., "checked off") earlier. The server 14 assigns the user a reference number 161 that will allow that user to track and subsequently amend the communication if desired. At the bottom is a "new search" button 162, which allows the user to return to the search page 70 (from FIG. 3C) to initiate a search for a new item as described earlier, or modify an existing document.

Referring again to FIG. 3C, to change an existing submission or modify parameter settings, the user clicks on the "Bid Addendum" 75. In response, the server 14 returns a My Transactions page 163, shown in FIG. 3J. The My Transactions page 163 includes a transaction description 164, which corresponds to a selected category for a particular request, and the assigned reference number 161 (as also shown in FIG. 31) . The page also includes a status 165 of that particular request (how many bids sent and received) and an expiration date override 166 that the user can use to override the preset or expiration date, or change (extend) the expiration date. To change the recipients list or send an addendum to all of the vendors currently selected, the user selects either the transaction description 164 or reference number 161. In response, the server returns a Bid Addendum page 165, shown in FIG. 3K. Referring to FIG. 3K, the Bid Addendum page 167 allows the user to choose via vendor selection boxes 168 those of the already selected vendors to receive the addendum. It also allows the user to attach a bid addendum through a bid addendum field and attachment button 169 or type a bid addendum online via a bid addendum online field 170. The user transmits the bid addendum by clicking on the "send bid addendum" button 171.

A server process that handles a purchasing- related communications exchange between buyers and vendors 175 will now be described with reference to FIGS. 4A-B.

Referring to FIG. 4A, upon detection that a user has logged on 176, the server 14 sends to the user a search page 177. The server 14 receives from the browser a search request based on a search string entered in the search page by the user 178. In response, a "matching categories" list is generated 179. The server receives a selected category from the list of matching categories from the browser 180 and returns a matching vendors list 182. Next, the server receives from the user the selected vendors from the list of matching vendors (vendors contained in the "vendor matching" page) and communication option (e.g., RFQ) 184. The server returns a request options form to the user 186 and receives back from the user the request options data and selections (i.e., parameters, along with selected second communication option or options) 188. The server sends a form corresponding to the selected communication options (e.g., online RFQ) to the user as appropriate 190 and receives back the completed document, along with any attached files 192. The server sends the completed document, along with any attachments, or a document contained in a file provided by the user to each of the selected vendors via a single e-mail transmission 194.

To generate the matching categories list 179, the system performs a number of operations, as illustrated m FIG. 4B. One of the CGI-based applications or scripts (CGI applications 34 from FIG. 2) is invoked by the server 192. The invoked script parses the string contents to receive the data and processes the data 194. That is, the script converts the data from web format into a format that is usable by the database search engine 38 (from FIG. 2) . The script 34 strips off any special characters and processes the data string through fuzzy artificial intelligence software. The script also enforces rules according to the needs of the database system. For instance, the database system might require that its input contain only word roots or have stop words (i.e., words that have no or little meaning to a query) removed. Additionally, slang words are converted into standard format that is accepted in the database and plural words are converted to the singular, unless stored in the database in plural form. Once the string is processed into a format that the database system accepts, it is passed on to the database system (specifically, the database search engine) to service the form's request 196. The database search engine accesses the database and tries to match the search string that it receives from the script with entries in the database 198. Once the database search engine obtains a match, it returns the matching categories to the script 200. The script, in turn, formats the information into HTML 202 and returns the formatted information to the browser in the form of a "matching categories" page 204.

Although not illustrated in detail in FIGS. 4A- B, the system that generates a matching vendors list is performed in a similar manner. The system sends the data received from the browser to the CGI script for processing. The CGI script provides the processed data to the database search engine, which accesses the database and returns a list (in this case, a list of vendors corresponding to the selected category) to the script for formatting. The resulting HTML ("vender matching") page is returned to the browser .

An exemplary implementation of the database 22 (from FIG 2) will be described now with reference to FIGS. 5A and 5B. As can be seen in FIG. 5A, the database has a category table 210 for each category or heading. Each category table 210 stores a pointer 212 for each vendor related to that category. The detailed vendor information is stored in a flat file 214 having a vendor record 216 corresponding to each vendor. Because the category table 210 stores only a pointer to the flat file that has all of the vendor information, searches are very fast.

Also contained in the database 22, and shown in FIG. 5B, is a user request table 220 having a request record/entry 222 for each user request. Data is gathered over a series of pages using the same user entry. If the user disconnects, the server 14 saves the user request record. When the user logs on again, the server gives the user the opportunity to resume work on the saved (but incomplete) request.

Referring now to FIG. 6, a target advertising mechanism 230 is illustrated. Conventionally, websites display banners and the owner of the banner will pay the web page owner some fee when the banner is clicked on. Because the networked system 10 is geared towards the needs of buyers, there is a high probability that the user of the system is interested in purchasing or getting information about a particular product or service. Therefore, the most valuable time for an advertiser to "get in front of" a potential purchaser is when that buyer indicates on-line that the buyer is actively looking to purchase such product or service. The target advertising mechanism, also referred to as a "last ditch advertising" option allows the advertiser (advertising vendor) to virtually stand behind the purchasing agent during the purchasing decision-making process .

Thus, and with reference to FIG. 6, the server 14 returns a list of vendors that match a buyer's search request 232. When the server receives from the user/buyer the list with certain ones of the vendors selected (i.e.. "checked off") as recipients of a user document or communication 234, the server detects that one or more of the vendors have not been selected 236. It should be noted that the server 14 keeps track of the selected category all the way through the process. If the server 14 detects nonselected vendors for that category with the "last ditch advertising" option enabled prior to sending the options request page, the server checks 14 for pre-determined selection criteria 237 and selects one or more of the detected vendors using the pre-determined selection criteria (e.g., according to subscription information) if it exists 238. Otherwise, they are selected at random 240.

The server 14 already has the category/heading to which the vendor or vendors belong, therefore the server 14 retrieves from the database and presents to the user any one or more of the nonselected vendors. The server presents vendor information (such as a banner ad or company name/address) for one or more of the detected, nonselected vendors to the user 242 and allows the user the option of adding the one or more of those vendors to the list of recipients prior to the transmission of the document or communication to the selected vendors 244.

In this embodiment, the information is presented in the form of a page via the browser, as shown in FIG. 7. Referring to FIG. 7, a last ditch advertising page 245 includes nonselected vendor information 246. The nonselected vendor information 246 can be "clicked on" via a corresponding hyperlink 247, thereby adding the vendors associated with such information to the recipients list. The buyer is also given the opportunity to modify previously set request options parameters 248.

In this manner, the last ditch advertising option provides the nonselected vendor a chance to make one last pitch to the user in order that the vendor may be considered during a potential sourcing or purchasing decision. The user has the option of adding that company (by simply clicking on a banner ad) to the user's existing "basket" of recipients prior to submitting the communications document (e.g., RFQ) for transmission to the vendors on the list of recipients. Vendors added, and all options are stored in a unique file on the server. That file is loaded and verified every time a change is made. Having such information stored in a file allows the user to return and complete an RFQ at a later time. It is also used by the server to determine which "last ditch" supplier to show.

Although the target advertising mechanism has been described with reference to and within the context of the illustrated buyer-vendor communication process 14, it need not be so limited. It will be appreciated that such a technique could be used in other purchasing environments, such as web-based shopping applications, in which a buyer chooses to buy an item by adding the chosen item to the buyer's "virtual shopping cart". That is, the addition of an item from a particular source to the basket (as opposed to the detecting of a nonselected vendor as described above) could trigger the advertising of an alternative source of the chosen item or source of a competitive item.

Another feature of the purchasing communications system is the ability to construct and utilize a user- specific vendor directory or list.

Referring now to FIG. 8, a process to produce a preferred vendor list or directory 250 is shown. In this embodiment, the list will take the form of an HTML page. The website administrator for the Web server and associated applications receives from a user (e.g., purchasing department or agent) a file including preferred vendor information 252. The system can accept the preferred vendor information in any format. The system detects the format in which the information is stored 254. The system opens the file and determines if the file is commented, fixed field, etc., or stored in some format like Excel, Access or Word. Once the system determines how the information is stored, it removes the data from the encapsulated form in which it is received 256 and applies an Artificial Intelligence "filtering" operation to the data 258. The Al program automatically corrects any out-of-date names/numbers, and provides the formal legal names of listed vendor companies as needed. It also strips off any apostrophes and dashes to get the "raw" name. Once the Al filtering is complete, the system performs a fuzzy logic matching to match the data with records already residing in the database 260. Once all the data has been matched (or achieves a certain level of correctness) and an account has been set up for the user 262, the server populates a "My Vendor" page with the preferred vendors from the preferred vendor information and makes the page available to the user when the user signs on 264. Once the list is available for use by the user, the server automatically e-mails/faxes or mails a letter from the user to all of the vendors on the "My Vendor" page indicating that the user has an account with and will be utilizing the purchasing communications system in future procurement activities 266.

Alternatively, the buyer/user can run a search on a category and check off all of the vendors that the user's particular purchasing department procures from and could create a running list in that manner.

The "My Vendor" page also includes competitive vendor data. The competitive vendor data is generated by pooling together the preferred supplier information from a group of similar users (e.g., a group of universities) . The server runs each user's list through the database "filter" as described above and categorizes the information. Referring back to the vendor matching page shown in FIG. 3F, the check box also allows the user to add to "My Vendor" page by simply checking the box corresponding to a particular company name and clicking on the "Add selected vendors to my page" button 110. In response, the user will get a screen confirming that he has added the selected vendors to his personal page.

There is an administrative account (set by the purchasing agents) which controls how the vendor page is updated or changed. It also controls access to the rest of the system. The system provides parameters that allow purchasing agents to specify different levels of access, e.g., vendor page only, search page, or up through post search where the user has a list of recipients. The administrator has the ability to block the user from sending to suppliers other than those included on the "My Vendor" page.

Referring now to FIG. 9, a vendor response management portion of the buyer-vendor communication process is shown. The system (system 14 from FIG. 1) receives a response from a vendor 272 and sorts that response based on reference number 274. In order to determine how to proceed with the processing of the response, the system consults the request options parameters specified by the user prior to transmission 276. It accomplishes this task by reading the user request entry data corresponding to the reference number in the request data table of FIG. 5B. Specifically, the system 14 will determine if the submissions period has expired 278. If the submissions period has not expired, the system will check the delivery field to determine if the delivery date parameter is met. If not, the system will hold the response for delivery on the appropriate delivery date 282.

If the submissions period has expired (at 278), the response will be deemed late and discarded 284. If the delivery date parameter has been met 280, the response will be sent to the user 286. Other Embodiments It is to be understood that while the invention has been described in conjunction with the detailed description thereof, the foregoing description is intended to illustrate and not limit the scope of the invention, which is defined by the scope of the appended claims. Other aspects, advantages, and modifications are within the scope of the following claims.

What is claimed is:

Claims

1. A method of constructing a preferred vendor list for use by buyers engaging in on-line purchasing communications with vendors, the method comprising: receiving a file identifying preferred vendor information from a buyer, the preferred vendor information including names of the preferred vendors; and adding the preferred vendor information to an

HTML page to produce the preferred vendor list.

2. The method of claim 1 further comprising: linking the preferred vendor list to other on- line purchasing tools used by the buyer.

3. The method of claim 1, wherein removing the preferred vendor information from the file comprises: checking the accuracy of the preferred vendor information by comparing the preferred vendor information to vendor information stored in a database; and substituting the stored vendor information for the preferred vendor information if it is determined that the preferred vendor information is inaccurate.

4. The method of claim 1, further comprising: generating competitive vendor data for the preferred vendor information; and associating the generated competitive vendor data with the preferred vendor list.

5. The method of claim 4, wherein associating comprises : adding the generated competitive vendor data to the HTML page.

6. The method of claim 4, wherein the preferred vendor list includes a heading that is a hypertext link and wherein the step of associating comprises: linking the generated competitive vendor data to the preferred vendor list via the heading.

7. The method of claim 4, wherein generating competitive vendor data comprises: accepting vendor information from individual users; classifying the accepted vendor information by category; storing in a database in association with the classification the accepted information; searching the database based on the category classification and retrieving the accepted information associated with category classification in response to a user request for the preferred vendor list; and providing the information corresponding to the category classification to the preferred vendor list for use as competitor vendor information.

8. The method of claim 1, further comprising: receiving a search request for a product category from a user; returning a list of vendors to the user; and enabling the user to select vendors from the list of vendors to be added to the preferred vendor list.

9. A computer program product residing on a computer readable medium for constructing a preferred vendor list for use by buyers engaging in on-line purchasing communications with vendors, comprising instructions for causing a computer to: receive a file identifying preferred vendor information from a buyer, the preferred vendor information including names of the preferred vendors; and add the preferred vendor information to an HTML page to produce the preferred vendor list.