WO2002003165A2

WO2002003165A2 - System and method for web-based electronic buying system

Info

Publication number: WO2002003165A2
Application number: PCT/US2001/020653
Authority: WO
Inventors: Douglas Momyer; Duane K. Talhouk
Original assignee: Fisher Scientific Company, L.L.C.
Priority date: 2000-07-03
Filing date: 2001-06-28
Publication date: 2002-01-10
Also published as: WO2002003164A2; AU2001288216A1; WO2002003165A3; WO2002003164A3; AU2001271585A1

Abstract

A buying system including an integrator computer system in communication with one or more supplier computer systems. The integrator computer system may maintain customer profile information in the form of both company and requisitioner profiles. The integrator computer system may accept a customer requisition for a desired product that a customer creates using a variety of methodologies. The system uses the customer profile information to obtain, from a supplier computer system, real-time product information responsive to the customer requisition. The real-time product information preferably includes product pricing, availability, promise date, expiration date, and/or inventory lot number. The customer requisition methodologies may include a rapid order form, a template, a hot list, a catalog browsing feature, a catalog search feature, or a web requisition form ('WebReq') that allows a requisitioner to input a non-catalog product request in free-form (Figures 1-3).

Description

SYSTEM AND METHOD FOR WEB-BASED ELECTRONIC BUYING SYSTEM

FIELD OF THE INVENTION

The present invention generally relates to systems and methods for electronic buying and more specifically relates to systems and methods for buying products from a variety of suppliers via a central web site.

BACKGROUND OF THE INVENTION

Goods across various topical areas have been sold in a traditional fashion. Traditionally, a manufacturer of a good would post a price and sell a good to a consumer via the telephone or in person. As some companies began to specialize in manufacturing, other companies, called distributors, would gather together various products from different vendors and sell these goods to the public. Collectively, these manufacturers and distributors are known as suppliers.

As the complexity of business grew, and the number of customers and available products increased, computers and associated databases began to be used to keep track of certain business information. These host computers (which were traditionally mainframes) could be accessed by various other computers and supplier personnel to identify customers, determine pricing and/or availability, or perform other data-intensive tasks. Some suppliers even used other specialized computer equipment to perform targeted acts, such as hosting the content for a product catalog on a database or catalog server. With the advent of widespread use of the Internet, the landscape of commerce has changed again. Now, many suppliers (and other entities) have sold their wares via web pages over the Internet. Many suppliers now use separate web servers to store program code for these new web sites, and these web servers may also be able to connect to and communicate with the traditional company host computers.

Therefore, a complete supplier system may have a traditional selling site, a host computer, a database server, and/or a web server.

These supplier web sites focus on offering for sale and providing information about the goods that are manufactured or distributed by that particular supplier. They replace the telephone order process with a World Wide Web-based ordering mechanism.

Additionally, one or more entities (aggregators) may combine and list the products from the catalogs (inventory) of several different suppliers. These , aggregators may have their own host computers and/or web servers that communicate with the computer systems of various distributors or manufacturers. Heretofore, these entities have been little more than catalog content aggregators, and without real-time linkage or interaction with the supplier computer systems. The catalog aggregator sites merely present the various catalog items to the user in a way that may be more efficient than having the user browse through all of these catalogs separately. Catalog aggregator sites typically did not provide dynamic pricing or availability check. SUMMARY OF THE INVENTION

The present invention contemplates, in at least one presently preferred embodiment, a web-based buying system including an integrator computer system. The integrator computer system may maintain customer profile information and business logic rules. The integrator computer system may receive a product requisition for a desired product from a customer and obtain real-time product information provide by a supplier relating to the desired product. The supplier computer system may be located in a geographically or otherwise remote location from the supplier computer system.

The integrator system preferably exists as either a completely separate entity from its one or more suppliers, or the system may be part or all of one "preferred " supplier 's computer system. The real-time product information obtained from the supplier may include product pricing information, availability status, promise date (expected delivery date), expiration date, inventory lot number, or some other information.

The customer may preferably create a requisition for a desired product using a web-based interface to the integrator system. The requisition methodologies may include a rapid order form, a template, a hot list, a catalog browsing feature, a catalog search feature, or a web-based requisition builder form (e.g., "WebReq™") that allows a user to input a non-catalog product request in free-form. A WebReq request may be satisfied by a human operator (customer service representative) of the integrator system. The web-based requisition builder forms preferably prompt the customer to provide order header information about a supplier and order line item information describing one or more desired items from that supplier. The items requested via the requisition builder maybe placed in a virtual shopping cart with items requested via other purchasing methodologies, or the requisition builder items may be placed in a separate virtual shopping cart. If more than one virtual shopping cart exist, the customer is preferably able to check-out the items in each cart separately.

The present invention may also include a variety of other features and devices for use with the web-based buying system. These and other details, objects, and advantages of the present invention will be more readily apparent from the following description of the presently preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention and its presently preferred embodiments will be better understood by reference to the detailed disclosure hereinafter and to the accompanying drawings, wherein:

Figure 1 is a schematic diagram of an electronic buying system in which the integrator computer system is separate from the supplier computer systems;

Figure 2 is a schematic diagram of an electronic buying system in which the integrator system is at least partially hosted by a supplier computer system; Figure 3 is a schematic diagram of an electronic buying system in which the integrator is affiliated with one of its suppliers;

Figure 4 shows a web page site map for an integrator-based buying system;

Figure 5 shows a sample table of integrator system registration information;

Figure 6 shows a rapid order form for use with the present invention;

Figure 7 shows an order template for use with the present invention;

Figure 8 shows a hot list for use with the present invention;

Figure 9 shows sample search results for a "Class A Volumetric

Flask" search;

Figure 10 shows sample catalog drill down results with a preferred supplier's products shown first;

Figure 11 shows a partially full virtual shopping cart for use with the present invention; and

Figure 12 shows a sample web requisition form for entering initial supplier information;

Figure 13 shows a sample web requisition form for entering line item information about desired items; and Figure 14 shows a sample virtual shopping cart web page including two virtual shopping carts.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The integrator system of the present invention can be used in any industry where a variety of manufacturers and/or distributors provide related products (e.g., a common genre of products). The following detailed description provides various embodiments of an integrator system used to provide scientific products (e.g., beakers, flasks, chemicals, etc.). Nothing in the following description should limit the scope of this patent to any group of products or any particular industry. The scientific product references are provided by way of example only.

The beginning of this portion of the specification gives a general outline of the structure and computer hardware of several preferred embodiments of an integrator-based buying system according to the present invention. The focus is on the interaction between the integrator and the supplier computers during a customer requisition. This discussion is followed by a more detailed description of these interactions coupled with the specific web functionality used in at least one presently preferred embodiment of the invention. This portion of the specification concludes with several examples of the integrator-based buying system in practice to aid in clarity.

FIG. 1 is a schematic diagram of an electronic buying system according to a presently preferred embodiment of the invention. FIG. 1 shows an integrator I_A associated with two primary manufacturers M_B and M_c, two primary distributors D_F and D_G, and several third party manufacturers M_κ, M_L, and M_M. The integrator performs a more interactive service with its primary suppliers than aggregators have performed with their suppliers in the past. The integrator may combine and integrate some or all of the products available from one or more suppliers into single or multiple catalogs of products to be sold to consumers. An integrator may be a content integrator or a purchase integrator. While a supplier (manufacturer or distributor) or aggregator web site may focus its content on the products that it supplies, the integrator site, will preferably treat all of the suppliers on a more equal basis and will provide all suppliers with similar opportunities to take advantage of the site.

Preferably, integrator I_A has a close buying and data-transfer relationship with each of the four primary suppliers M_B, M_c, D_F, and D_G. This close relationship may allow the integrator to gather content information about the primary suppliers ' products and may allow the integrator access to "real-time" product information (including product pricing, availability, promise dates, product expiration dates, lot numbers, etc.) from the primary supplier sites ' host computers and/or database servers. The primary distributors, in turn, may have close buying and data- transfer relationships with one or more additional manufacturers (illustrated as vendors V_x, V_γ, and V_z).

For the purposes of this specification and the claims, the terms "realtime interaction" or "real-time access " are characterized by a short period of time between a request for information and the corresponding response to that request. Real-time does not necessarily mean "instantaneously" or "simultaneously. " Rather, a real-time response (or real-time information) is distinguished from a system that sends information according to some predefined time frame or schedule (rather than responding to a recently received request). A regular communication or dumping of predefined information will be referred to herein as a "batch" or "batching" that information. A batch (as used herein) does not occur in direct response to a "real- time " request for information.

Other third party suppliers M_κ, M_L, M_M are suppliers that have a "looser" or less interactive relationship with integrator I_A. This relationship may include a regular buying or data-transfer relationship between the integrator and these third party suppliers. This relationship preferably exists to the extent necessary so that when a customer of the integrator's system makes a requisition for a product manufactured by a third party, the integrator is able to contact that particular third party and obtain the requested product for its customer. The requisition builder ordering methodology may be particularly useful for customers dealing with these third party suppliers.

As shown in FIG. 1, the integrator site and each of the four primary suppliers preferably have a web server WS_A, WS_B, WS_C, WS_F, WS_G (or an information server connected to the integrator's server, or some combination) for communicating with other entities over the Internet. Additional web servers may be added at sites to increase capacity and load handling. Dedicated lines for Internet protocol communications (e.g., Virtual Private Networks) may also be used. Also, the integrator and each of the primary suppliers preferably include a host computer HC_A, HC_B, HC_C, HC_F, HC_G containing certain account and/or product information and a database server DS_A, DS_B, DS_C, DS_F, DS_G containing catalog content (product information) and customer profile information. The third party manufacturers M_κ, M_L, M_M and the vendors V_x, V_γ, V_z preferably include a host computer HC_K, HC_L, HC_M, HC_X, HC_Y, HC₂ but may or may not include a database server, or a web server allowing these sites to directly connect to the Internet.

More specifically, the host computer (for any of these entities) preferably includes the financial and account-based information about its customers.

' This account information may include billing and/or shipping addresses, pricing logic to determine a specific customer 's price for each product, and an order history that allows a customer to view all orders charged against a chosen account.

The database server preferably includes catalog content that describes the available products in great detail. There may be a link to an image of the product, each associated with a web server. A supplier database server preferably includes detailed information about the products that it supplies, and the integrator database server preferably contains detailed information about products supplied by all suppliers to the integrator site.

The database server, DS_A, may also include various customer profile information. The integrator system may keep both a "company profile " that determines high-level decisions about the customer, institution, or other buying entity and various requisitioner profiles that include information controlling each requisitioner 's use of the integrator buying system. These profiles are preferably linked to the account information on the host computer. Specifically, a company (or university, organization, etc.) may have one or more accounts with one or more suppliers (of the integrator), and each requisitioner for the company may be assigned certain usage rights for one or more of these accounts. The database server may also contain a set of business logic or business rules that define various aspects or limitations about a requisitioner 's use of the system as described below. This logic may utilize both account information (typically stored on the host computer) and profile information (typically stored on the database server) to determine these aspects or limitations.

The web server, WS_A, may preferably perform most other tasks that are performed by the system. For example, the web server may contain the web pages utilized by the system, images of the products available for order, static web page content, and all of the underlying web functionality (e.g., Java scripts, XML, etc.).

Registering with the integrator system typically entails creating both a company profile and usually one or more requisitioner (user) profiles. These profiles are used by the system, in combination with certain business logic, to determine how the integrator system will interact with each specific company and/or requisitioner. The company profile typically involves inputting administrative, billing, and other addresses and information into the system via various data fields.

The company profile also allows the addition or modification of these fields as "customer-specific data. " Customer-specific data is a way for a company (or subsets of that company) to tailor the use of the integrator system to their particular needs. For example, assume that the "company" is a university with both a biology and a chemistry department. This university 's accounting system may prefer to use sequential purchase order (PO) numbers, but a repetitive departmental charge number for each purchase. Even though the integrator system may use a PO number field to track different purchases internally, the deployment of the integrator's system for the university would define the additional field to track the departmental charge number. The customer-specific data may also be used to limit certain requisitioners to the use of a particular account or credit card, to certain spending limits or approval requirements, and/or to the viewing of certain catalogs. Typically, the various account numbers that the company maintains with the integrator system and with the various suppliers are input into the company profile, and these accounts are linked or assigned or available to different requisitioners. When a requisitioner attempts to order a product, the integrator system will follow the company profile and integrator system business logic to ask the requisitioner to enter an account number (or select from a list provided by the system). This customer-specific data not only allows the company to track more information and control its requisitioners, but the integrator system may also validate the information input by a requisitioner against the allowable choices as found in the company profile.

Each user of the integrator system from or supporting a certain company preferably also has his or her own requisitioner profile. This requisitioner profile preferably includes information about that specific user and provides acceptable data choices for some or all of the company-defined customer-specific data fields. For example, if the university defined a "grant number" customer-specific data field, a particular requisitioner 's profile may list the two grant numbers under which the requisitioner (perhaps a graduate student) is currently working. If this requisitioner tried to input a different grant number when making a requisition, the integrator system will preferably not allow the request to go forward (data validation). The use of the data found in the company or requisitioner profile is governed by the business logic found preferably on the database server DS_A. The grant number customer-specific data field could also be used by a university employee to track all of the requisitions and orders placed for each grant number to make sure that the grant funds were not exceeded. The integrator business logic may even be used to prevent such spending automatically if the integrator system controls or receives data on the balance of each grant.

In one presently preferred embodiment of the invention, the integrator site exists completely separate from all of its underlying suppliers (as shown in FIG.

1). The integrator site preferably includes a web server WS_A that is capable of transmitting information over the Internet. This "web-based" communication may occur over the publicly accessed Internet, a private internet or intranet, or some combination of public and/or private web-based communication channels. Generally speaking, various requisitioners (Rj to R_n) preferably access the integrator system from a remote location through a personal computer or some other web-capable device (e.g., a handheld or palmtop computer, personal digital assistant, or web- capable pager). The customer (requisitioner) typically enters the integrator web site 's Uniform Resource Locator (URL) into the customer 's web browser. The integrator site may provide catalog content and functionality across all relevant suppliers. The integrator may also provide the "real-time" functionality to communicate with the supplier computer systems to get updated information about product availability, pricing, and other information.

Generally speaking, when customers use the integrator site, they log onto the site and access their requisitioner profile information. If the customer is given access to more than one account number, he/she may select which account number to use at this time. The customer may later change to a different account.

If the requisitioner desires a particular product, a search (or some other requisitioning methodology) may be initiated against all or selected catalog content files in the integrator database server DS_A. The relevant product information may be assembled at the integrator web server WS_A from various information residing in the integrator's host computer HC_A. To the extent that additional information may be required about a located item, or to the extent it becomes necessary to extend the search to other suppliers, the integrator web server WS_A may communicate (via

XML, OBI, frames, hyperlinking, EDI, etc.) over the Internet or some other electronic communication link with one or more of its closely-linked suppliers. Data about a vendor product (e.g., V_x's product), for example, may be assembled by the distributor 's web server WS_F from information contained in the distributor 's database server DS_F, host computer HC_F, and/or the distributor's interface with the vendor's host computer HC_X.

At various stages in the selection of products and the building and approval of orders, information may be "pulled " from the relevant source computer about price, availability, etc. Depending upon the integrator I_A account number selected by (and available to) the requisitioner R, price for the buying company may be based entirely upon information stored in the integrator's host computer HC_A. This may be the list price or integrator cost, or some calculated price based on this information in the host computer, HC_A. These or other pricing may be batched to the integrator site at regular intervals from the supplier 's computer. For some customers, however, the business arrangement may be such that the integrator I_A passes on the pricing which the customer has negotiated with a major supplier M_B, D_F, D_G or M_c or even a third party supplier M_κ, M_L or M_M. The business logic resident in the integrator's host computer HC_A or database server DS_A may recognize such relationships and preferably would then pass to the relevant source (e.g., manufacturer

43- host computer HC_B via web servers WS_A and WS_B or directly via EDI) a request for quote on the desired item.

In order that the manufacturer host computer (e.g., HC_B) may correctly price the item, integrator I_A preferably should have a table that associates a particular supplier M_B account number for that customer with an integrator I_A account number for that customer. This association table may reside either on host computer HC_A, database server DS_A (as part of the company profile), web server WS_A, or elsewhere. The integrator account number may be found in the requisitioner R 's profile stored on the integrator database server (and selected by requisitioner R, if he/she is authorized to use multiple account numbers).

If the integrator business logic indicates that the product price may be provided real-time by the supplier, the integrator may "query" the supplier host computer and request the correct contract pricing (as well as updated availability status and/or promise dates). This integrator request is preferably accompanied with the customer's supplier account number so that the supplier host computer will be able to look up the correct pricing algorithm or table for this customer. Once the price is calculated, this pricing information is preferably sent back to the integrator site (via the web server WS_A by XML, EDI, OBI, etc.) where the customer can now view the pricing information. As described herein, such a price inquiry may be a background query, not obvious to the requisitioner.

Real-time communication occurs between the integrator computer system and one or more supplier computer systems in several ways, including EDI between host computers and various XML or OBI transmissions between web computers. There are two types of communications used to collect information at the integrator computer system from various supplier computer systems, involving communications between their respective web computers, which can be described as queries and responses to queries. The first type is a "foreground query" (often called "punch-out"); the second type is a "background query. " Typically, the integrator computer system and one or more supplier computer systems are coordinated to communicate and exchange information in a variety of forms of foreground queries, background queries and other one-way and two-way communication formats. Both foreground and background queries may be enabled with the use of XML or OBI scripts or some other form of electronic interaction.

When the integrator computer system initiates a foreground query or punches-out, it communicates with a supplier computer system, and the requisitioner is presented with the web presentation, navigation, and some functionality of that supplier site. Session information or border presentation (as with framing technologies) from the integrator computer remains in effect and (usually) visible to the requisitioner. The requisitioner, however, will typically also be presented with a

"sub-screen" or window to the supplier's site. With such a foreground query, the requisitioner typically is aware that he or she is at the supplier 's site (albeit through the integrator computer). Supplier sites may have their own "look and feel. " In preferred forms of the invention, a session is initiated on the supplier 's site using information transmitted from the integrator web computer, including various identifying data.

Alternatively, and for other data transfers, the integrator computer system "background query" requests and obtains information from a supplier computer system "in the background, " i.e., where the customer remains on the integrator computer and the access to the supplier computer typically is not obvious. With the background query, the integrator computer system (typically the integrator web server) retrieves the relevant data from the supplier site and presents it to the requisitioner on the integrator computer. As a result, the "look and feel" does not change for the requisitioner. In addition, the integrator computer system may format or reformat the retrieved data as desired, e.g., to adapt the data retrieved from one or more supplier sites to the look and feel presented by the integrator web server.

One example of a punch-out may occur if a requisitioner wishes to search a supplier site for a specific product. Upon request, the integrator computer preferably opens a frame (based on common HTML coding practices), an overlay, or some other web page device to show the requisitioner a second web page without "leaving " the integrator system. The integrator computer preferably communicates with the selected supplier computer system (via XML, OBI, EDI, etc.) and passes to the supplier a request for information, information identifying the current session on the integrator computer, and relevant account details (account number, ship-to zip code, etc.) which are derived directly or indirectly from the requisitioner 's individual profile or from the overall company profile. Navigating the supplier site, the requisitioner may modify the request or seek other information before selecting an item and requesting it be added to his or her shopping cart or carts. The supplier computer then processes the request and sends real-time product information (or other data) back to the integrator system. If the requistioner selects that supplier 's product for inclusion in the shopping cart, it is used to build an order line (specifying the desired quantity and unit of measure) on the integrator 's site which can subsequently be accepted by the requistioner and (after any required other approvals) turned into an order from the requisitioner 's company to the integrator and an order from the integrator to the respective supplier(s).

Product availability information may also be determined from information stored in integrator I_A 's host computer HC_A (typically updated in a batch fashion from host computers HC_B, HC_F, HC_G and HC_C, and possibly from HC_K,

HC_L and HC_M or by linking to these computers). This batched availability information may be sent to the integrator 's host computer HC_A daily or at some other regular interval (or on some other basis, i.e., special updates, etc.), and may include updated availability information as of the time of the batch. Such immediately accessible information about product availability may suffice during the product selection and requisition stages, but this periodically updated information may not be sufficiently current for the final determination of a delivery date at the time of ordering.

Before final order approval, the integrator site will preferably make a background query to the supplier host computer (directly or through the respective web server) for current availability status and promise date information. If manufacturers M_B and M_c ship nationally from one site, the background queries to host computers HC_B and HC_C may preferably be conducted under the integrator I_A 's account number (associated with the respective supplier). If distributors D_F and D_G maintain inventory at multiple sites, either the ship-to zip code or some other identifier (e.g., the distributor's special account number for sales through integrator I_A for that customer) could be passed to host computers HC_F and HC_G, respectively, in order to tap into the distributors ' sourcing logic and determine availability of the requested product in the requested quantity at a selected warehouse, for example. The data returned to the integrator web server WS_A may then include quantity available, location, and promised delivery date for one or more products.

This same "communicative" approach may be extended to products shipped directly from one of the distributor's vendors (e.g., V_x) or one of the integrator's third party suppliers (e.g., M^, at least with respect to availability information (including promise dates). Distributor host computer HC_F should preferably have current information as to products maintained in distributor D_F's inventory (e.g. , from V_γ and V_z) and may also have reasonably current information about restocking shipments expected from the vendors V_γ and V_z for those items that are currently out of stock. This real-time availability and re-stocking information may provide the integrator site the ability to calculate a reasonably accurate promise date for future shipment of the selected product. Information about product lot numbers and expiration dates may be queried and retrieved in a similar fashion.

The integrator-based buying system of the present invention does not have to exist as a completely separate site from all of the primary and third party suppliers. In another presently preferred embodiment of the present invention shown in FIG. 2, the integrator site I_A may include one or more integrator web servers WS_A (and an integrator database server, DS_A), but the integrator may not have its own host computer. Instead, the integrator site I_A may preferably be hosted (share space) on one or more host computers HC_AF, perhaps owned by one of its distributors (e.g., distributor D_F). Therefore, integrator I_A and distributor D_F, for example, may each have one or more web servers WS_A, WS_F (respectively) and an integrator database server (DS_A, DS_F, respectively) but share space on a single host computer HC_AF. The integrator's interaction with distributor D_F's products/pricing/availability may be simplified because of this setup (no need to send queries over the Internet for realtime information). In most other respects (including interfaces with suppliers M_B, D_G and M_c and third party manufacturers M_κ, M_L and M_M), this scenario will be similar to the embodiment described above, except that the distributor host computer HC_AF will preferably now perform both pricing and availability on distributor D_F.'s products.

With respect to the web functionality (as further described below) of this embodiment, the integrator site may also "prefer" the products of its host distributor D_F. For example, the results of requisitioner searches for products may list the host distributor's D_F's products at the top of the search results, ahead of other suppliers ' products. On the other hand, the integrator system may still maintain its logical independence from the distributor D_F and not favor that distributor's products at all, or peπnit different preferences based on the company profile, as discussed below.

In another presently preferred embodiment of the invention (shown schematically in FIG. 3), the integrator web system may actually be little more than a supplier web site with third party interaction, WS_AF. The integrator web server may be linked to the supplier host computer (or mainframe) HC_AF and may have direct access to that system. However, this integrator site may be different than a conventional supplier web site because it also offers third party products. Information about the third party products may be assembled by punching-out for information from the third party's host computer (via XML, frames, hyperlink, EDI, etc.). This linked embodiment will preferably favor the linked supplier's products by giving these products a more prominent placement on the site and/or a fuller description. The above examples generally describe the interaction between an integrator site and the integrator site's primary and secondary suppliers. The customers (requisitioners) preferably access the integrator site via the World Wide Web (the "web ") portion of the Internet or Virtual Private Networks. As such, much of the functionality of the buying system stems from the web-based interface and scripting at the integrator site. Therefore, various embodiments of the present invention will now be described with respect to this web functionality. For the purposes of this discussion, it is assumed that a product requisitioner has accessed the integrator 's web site through a web browser on a computer or other Internet-capable device that resides remote from the computers of the integrator computer system.

Upon accessing the integrator 's I_A 's web site via a web browser, the customer may preferably be presented with a home page or other initial web page that generally allows access to the various features of the integrator-based buying system. A presently preferred embodiment of a site map showing the interaction of the various web pages of the integrator-based buying system is presented in FIG. 4. The home page of the system may provide a way for registered users to login and access the buying system and a way for unregistered users to browse the various features of the scientific product purchasing system to determine whether or not they wish to become a full registered user of the site.

A distinction should be made at this point between having an

"account" and being "registered" with the integrator buying system. An account is set up (typically by a company) as a way to facilitate billing and to contract for pricing. Accounts may preferably be set up at the supplier level, the vendor level, the integrator level, or any combination thereof. Registration with the integrator site, on the other hand, entails creating company and requisitioner profiles on the integrator site, and identifying which supplier and integrator accounts can be used by which requisitioners.

In a preferred embodiment of the present invention, the integrator may want most customers to have an account with the integrator for pricing purposes. If no account exists, the system may access or set up a list price account for the user.

In a preferable revenue model, the integrator system determines price at the buying company (retail price) in the majority of cases. If a customer does not have any supplier accounts associated with his/her registration (e.g., no contract pricing with individual suppliers), and no overall discount arrangement with the integrator, the customer will typically be charged list price by the integrator system. Some suppliers may give the customer product availability information without an account, but no supplier-side discount pricing would be calculated.

Setting up a requisitioner profile is an individual process that may occur on-line. There may also be a batch registration that allows many requisitioners from or associated with the same company to be registered at one time. With batch registration, a spreadsheet or other data entry form is created and then uploaded to the integrator web server. The web server WS_A or database server DS_A parses this information and creates the new profiles.

The registration information will preferably remain on the integrator 's database server DS_A as part of the company and requisitioner profiles. At least one of the registration data fields lists the various account numbers to which the user has access. Whenever a request is made by the integrator web server to any supplier or other computer on behalf of a particular requisitioner, one of the requisitioner 's account numbers will preferably be transferred along with the request. The account number often serves the added function of identifying where the order is to be shipped. The system suppliers may use the account numbers (or other destination indicator) to determine not only pricing, but also warehouse availability based on the account 's ship-to location.

When registering on-line, the requisitioner is preferably presented with a registration web page that asks for information, such as the sample in FIG. 5. Preferably, there is an off-line registration process for both the company (creating a company profile) and an on-line requisition for each requisitioner (creating the various requisitioner profiles). The company profile information generally sets out high level account specifications and each requisitioner profile selects from the applicable choices (e.g., which accounts each requisitioner may use, how much each requisitioner may requisition or approve, etc.).

This registration information is preferably used by the system to create a profile of the customer (company or requisitioner). After the customer profile is created, selected information in the profile can be changed by the requisitioner, and selected other information may only be edited by an administrator of the integrator site or an authorized representative of the customer (such as spending limits). For a small company, the profile may be used for informational purposes only (no decentralized control of spending). For a large company, certain customer-specific data may be configured in the company profile. This customer-specific data allows the integrator system to be tailored to each customer. A company may set up specific order approval rules (certain individuals can only approve expenditures up to a defined limit) or may require the entry of non-standard information (a release number instead of PO or a department number instead of charge number). This "unique" information is carried through the site as customer-specific data.

Customer-specific data may include additional registration information or product purchasing input fields (or changed fields) for a particular company.

These additional fields may be optional or mandatory. For example, the integrator system may have a field where a PO number is input for each order, typically as a mandatory field. However, a certain company may have one PO number for all purchases made on the integrator system, but the company may distinguish each particular order with a release number to be input by the requisitioner. Here, a common example of customer-specific data may be to add a release number field to the company profile so that all requisitioners will have to input a release date (to accompany the pre-assigned PO number) upon requesting a product (if the release number was mandatory). Determining what fields are presented, who can edit these fields, and whether a particular field is required is a company-based decision reflected in the company profile that is then implemented for each requisitioner associated with that company profile.

After a requisitioner has registered with the system (and at any future visit to the site), the requisitioner may preferably be able to log into the integrator- based buying system and take full advantage of the features of the site. By clicking with a mouse pointer or otherwise selecting to log into the system, the requisitioner is preferably presented with a login page. To log into the system, the requisitioner preferably need only enter the username and password that the requisitioner selected as part of the registration process (part of their requisitioner profile). After logging in, the customer's or requisitioner 's profile preferably identifies the integrator account number and/or supplier account numbers that may be used to determine pricing/availability and other product information.

The company and requisitioner profiles on the integrator-based buying system are preferably hierarchical in nature. Each company register on the buying system may have registered one or more account administrators and approvers, and multiple requisitioners. The administrators may have the ability to control many aspects of the company/integrator relationship including the management of various requisitioners and their payment options. The approvers generally approve the requests for products made by the requisitioners, and the requisitioners (the lowest members of the hierarchy) preferably just request products. With this hierarchical structure, a department head or ordering manager may be able to control the purchases of many various employees (different scientists, faculty members, and/or students) while spending a reduced amount of time and energy in doing so. As used herein, a customer (as opposed to a supplier) of the integrator may be a requisitioner, an approver, an administrator, or any other entity on the buy-side of the system. Most customers are only requisitioners, but an approver or administrator may also be set up as a requisitioner.

Generally speaking, a requisitioner requests products, an approver approves the requisition for ordering, and an administrator manages the company account. Through management of the customer-specific data, an account administrator may place limits or guidelines on each specific requisitioner 's account access. For example, a requisitioner may only be able to order certain products, order from a certain supplier, or use a certain credit card when ordering. Also, there may be spending limits for each requisitioner for a particular order, for a particular account, or during a particular timeframe. Specifically, a certain requisitioner may only be allowed to create orders up to, for example, $500, or the requisitioner may be able to create a request for products for any amount of money but can only approve an order for up to $1000. For requests above $1000, for example, the next approver up the hierarchical chain must approve the request before it will become an order. This approver may also have an administrator-defined spending limit, and may need to get larger requests for products approved by his/her approver or an account administrator. In practice, using the university example, the requisitioner may be a graduate research student, the approver may be his/her professor, and the further approver may be the department head or purchasing manager for the university. The administrator may be a designated employee in the university purchasing department or an authorized integrator employee implementing the system for the university.

The integrator system may also preferably allow an administrator to utilize rules for customer credit card use according to the present invention. Here, the administrator can give a particular requisitioner no credit card privileges, privileges to only use one particular credit card, privileges to select from a group of credit cards when a purchase is made, or no restrictions on the editing and use of credit card information. This credit card information page may also display the current credit card and use privileges for the current requisitioner.

The integrator system home page may also include one or more direct links to various other major sections of the web-based scientific product purchasing system. For example, the FIG. 4 site map shows links to sections encompassing Products & Services, Ordering, Become a Customer, About Us, What 's New, Support, and a Site Map of the buying system. By clicking on one or more of these links, the requisitioner is preferably presented with a web page containing relevant information and/or functionality.

On the home page or some other integrator system web page, there may also be a descriptive section drawing the requisitioner 's attention to some specific type of information. This section may describe new suppliers that have just joined the integrator system. Alternatively or additionally, the site may present the requisitioner with various descriptive information about new or special products, may present warning signs or other notices to the requisitioners or other users of the system, or may provide any other information that is preferably of a general interest to all customers or specifically to all new customers of the web-based integrator buying system. There may also be a list of the current suppliers that supply the integrator system. This list may include hyperlinks to the suppliers ' own web sites for more information about the suppliers.

The integrator-based buying system may also allow a customer

(company or requisitioner) to create a personal home page on the system. Rather than presenting "teasers " or other general information as on the more general home page described above, the personal home page preferably contains information tailored to the specific customer logged into the system. The customer may select and arrange the various order request methodologies and some other information on the requisitioner 's company's home page.

The above description describes registering, logging onto, and administering accounts on the present buying system. Once the requisitioner or other user has properly logged into the system and is content with the account administration options, the requisitioner may preferably locate, request, or purchase one or more items from the system. There may preferably be at least six ways for a requisitioner to identify a product for eventual purchase. These methodologies preferably provide the requisitioner with various ways to fill his/her virtual shopping cart or carts until the requisition is approved into an order.

In FIG. 4, the exemplary site map identifies a "rapid order" feature to be used if certain information about the product is already known to the requisitioner; a "hot lists" feature that allows a requisitioner who is a registered user to select from a saved list of products added to his or her shopping cart; a "templates " feature that allows a requisitioner to add to the shopping cart a previously saved list of products; and a "catalogs " feature which allows the requisitioner to browse through a list of one or more online catalogs of products from various suppliers. There may additionally be a "search " or "advanced search " feature that allows a requisitioner to search all or a subset of the integrator's catalog content (inventory) to identify a product for purchase. The requisition builder, or "WebReq" feature utilizes a web- based requisition form to create a request for a product. Requisition builder is generally made available only to the requisitioners associated with certain companies and is described in more detail below.

By selecting one of the various "rapid order" links, the requisitioner is preferably presented with the rapid order form, example shown in FIG. 6. The rapid order form is for requisitioners who know certain information about the product they wish to purchase on the web-based scientific product purchasing system. With rapid order, the requisitioner merely needs to enter a catalog number, quantity, and unit of measure of a product to select that product for purchase. The catalog number that the requisitioner enters can be (1) a manufacturer part number, (2) a distributor catalog number, or (3) a customer-specific number for the product (e.g., a stock room number). As long as the integrator makes a cross-reference to the customer-specific number, then this number may be used in rapid order. By allowing the requisitioner to enter whatever catalog number they are familiar with, the present invention may provide an increased amount of flexibility over other web-based ordering systems. There may also be an error correction screen (confirmation) to correct unit or measure and selection of duplicate products (e.g. , products with the same part number from different suppliers).

Once the catalog number, quantity, and unit of measure for an item or list of items is complete, the requisitioner may add the item or items to their virtual shopping cart. Because a requisitioner may only be able to rapid order some of their needed scientific products, the present invention includes one or more digital shopping carts that allow the requisitioner to "hold" these previously ordered items in the shopping carts while the requisitioner uses the various other ordering methodologies (templates, catalogs, etc.) to add other products to the same or a separate shopping cart prior to making any final buying decision.

The requisitioner may also request a product using a predefined product template. As seen in FIG. 7, a template is a list of products that a requisitioner saves as part of his or her profile so that a similar request may be placed in the future. The template is typically a list of items. The quantities and sizes of the items (or other features) may preferably be customizable after the contents of the template are added to the shopping cart. The template may be suited for placing a recurring order, either by adding the order to the shopping cart on a regular basis or by loading the template as part of a regular batch process. The products in a template may also be added, as a whole, to a partially-filled shopping cart.

A template may have been created from an order page (for example from an earlier shopping cart), where the system presents the requisitioner with a template creation button or other selectable device. There may also be a template creation page where a requisitioner can define the contents of a template without actually purchasing the contents at that particular time. After the template contents are added to the requisitioner 's current shopping cart, the editing, checkout, and purchase of the template items proceed in the same way as described with respect to the other buying methodologies.

Similar to the templates of FIG. 7 are the hot lists of FIG. 8. A hot list is a quick requisitioning technique where the requisitioner is presented with a list of previously-identified products that can be individually adjusted or edited before being added, usually individually, to the requisitioner 's shopping cart. The hot lists of the example shown in FIG. 8 present the requisitioner with an order for acetone, an

RIA kit, SOD phosphate, and a thermometer. The catalog numbers for these items are displayed and the requisitioner can select a quantity and unit for each of the items on the list (including leaving the setting at none). Once completed, the products on the hot list for which a non-zero quantity was selected can be added to the shopping cart and later purchased in the same way as any other item in the system. One or more hot lists may be saved to either the requisitioner s profile (to be used by that requisitioner in the future) or to the company profile (to be used globally by any company requisitioner), on-line or in a batch load to the database server. Individual items may also be added to a selected hot list from the current shopping cart. The requisitioner may also place a requisition for a product by browsing through one or more on-line supplier catalogs. As previously described, each of the suppliers may have a regular paper catalog that is used to advertise and sell its products in the off-line world. The integrator-based buying system may have one or more on-line catalogs for each of its suppliers. From the FIG. 1 example, the integrator buying system may include three catalogs from distributor D_F, one catalog each from primary suppliers D_G, M_A, and M_c, and one other catalog that collects all of the third party suppliers M_κ, M_L, M_M together (because each individual third party supplier may not have enough catalog items on the integrator system to create their own catalog). These catalogs can also be accessed from catalog name hypertext links preferably found on many of the integrator system 's web pages.

In many instances, each requisitioner associated with a company may view all of the available catalogs on the system. However, a supplier or an account administrator for a company may be able to prevent one or more requisitioners from either seeing a certain catalog or from allowing the requisitioner to request items from a particular catalog. This "pre-selection" may be used to allow each requisitioner to be presented with a personal list of available catalogs or catalog content.

More commonly, either a supplier or a company may prevent one or more (or all) requisitioners for a company from viewing content or requesting products from certain supplier catalogs. For example, a supplier may interact with the business logic of the integrator system and say that its catalog should not be shown to hospitals. When a requisitioner using a hospital account (identified in part of the company or requisitioner profile) selects to view available catalogs, the business logic will preferably prevent the hospital requisitioner from viewing this particular supplier's catalog(s). On the flip side, a supplier could also inform the integrator system that it wishes to only publish its catalog (or a portion of its catalog) to one or more distinct companies or requisitioners. In this way, a supplier may only offer one or more products to selected customers, rather than all of the customers of the buying system.

The account administrator may also prevent requisitioner catalog access to implement the company's business rules. The administrator may prevent either viewing access or product request access for a supplier or a portion of a supplier's catalog. The administrator may block viewing access to a catalog or product by one or more requisitioners. Likewise, the administrator could allow full viewing access to a catalog or product but may restrict a requisitioner 's ability to request those products. Finally, the integrator system, as controlled at the company profile level, may "steer" one or more requisitioners either toward or away from a selected product or supplier by manipulating the order in which catalog or catalog search results appear on the requisitioner 's screen.

When the requisitioner decides to look at the contents of a certain catalog, the requisitioner need only select the appropriate catalog hyperlink. For example, after selecting a distributor D_F catalog hyperlink, the requisitioner is preferably presented with an index or other selectable content classification scheme (such as a hypertext version of the alphabet). The requisitioner may then "drill down " through the index tree until one or more products satisfy the requisitioner 's criteria requirement has been identified and selected.

This catalog entry selection preferably generally corresponds to the products that exist in the paper version of the same catalog. In some embodiments of the present invention, third party or other small suppliers may not have sufficient content to support an entire catalog. In some of these situations, the integrator site may incorporate the third party product descriptions into one or more supplier catalogs rather than separate third party catalogs. For example, if a distributor D_F catalog contains a long list of flasks, and a third party supplier has only one or two, the third party's flasks may be "virtually" incorporated into the relevant sections of the distributor D_F catalog. In an extreme case, in an embodiment where the integrator site treats all but one supplier as a third party supplier (see FIG. 3), all of these third party products may be virtually incorporated into the supplier D_F catalog.

Rather than drill down through the various catalog index trees, the requisitioner may also use a search engine (e.g., on database serve DS_A) to browse the contents of the product catalogs. This search preferably runs across all of the available catalogs. Again, a supplier or an account administrator may use the company/requisitioner profile to implement supplier or company business logic to prevent certain supplier catalogs from being viewable (searchable) or to prevent the catalog 's products from being selected to be added to the shopping cart. The search engine may allow the requisitioner to search for a single keyword, multiple keywords using Boolean connecting expressions (e.g., and, or, not, etc.), and/or the search engine may allow the requisitioner to perform a parametric search on various catalog content fields.

There may also be one or more advanced search pages that present the requisitioner with more options that can be selected when using the search engine. The advanced search page may preferably allow the requisitioner to perform a general search on one or more keywords, a supplier or user-defined catalog number, the product vendor or supplier name, and/or the vendor or supplier part number. These searches may be initiated by entering one or more words into text boxes next to each search heading and selecting a search button or other selectable device.

There may also be an advanced search area that allows the requisitioner to search based on the characteristics of a chemical that the requisitioner intends to request. For example, the chemical search may allow the requisitioner to search the relevant chemical catalogs by catalog number, chemical name, CAS#, and/or molecular formula. There may also be a link to a structure/substructure search engine that allows the requisitioner to search based on a full or partial chemical name, a full chemical structure, a partial (substructure) chemical structure, and/or the chemical formula of the product. The structure/substructure search page may provide the requisitioner with a drawing palette of various chemical substructures and symbols to draw the chemical structure or substructure. For example, a browser plug- in (such as CAMBRIDGESOFT CHEMDRAW) may be used to draw the structure. After the name, structure, or formula is complete, a selectable search button can be utilized to return the appropriate results of the search.

The advanced search page may also have a link to the various supplier catalogs available as part of the integrator-based buying system. There may be a selectable list of available catalogs by topic, or the page may present the requisitioner with a preferred list of featured catalogs. For example, a hypertext list of one supplier's catalogs or catalog segments may be presented to the customer as part of the buying system.

The search results page (or the final drill down page from the catalog browsing options) are preferably customizable based on the company or requisitioner profiles as well as the business logic that preferably resides on the integrator database server, DS_A. For example, assume that the integrator system is a completely separate entity from all of its underlying suppliers as shown in FIG. 1. The search results page for a sample search on this system for a [Class A volumetric flask] [TAQ??] is shown in FIG. 9.

FIG. 9 shows that the search results are broken up into groups based on the catalog from which the search "hit" was located. Either arbitrarily or by virtue of a requisitioner profile setting, the catalogs results in this example begin with the primary supplier D_F and continue through the rest of the primary suppliers and on through the third party suppliers M_L, M_κ, M_M collected in one third party catalog.

The indentation of the search results in FIG. 9 expand out to the right as subcategories of the distributor D_F on-line catalog are opened. Notice that TAQ products may be located at different subheadings in the various different catalogs. Also, there is more than one manufacturer of TAQ products found in both of the distributor catalogs D_F, D_G. Because these two suppliers are distributors (not manufacturers), their catalogs contain multiple vendor names.

The final grouping shown are the third party catalogs. It may be preferred to show these catalogs last because the content of these catalogs may be sparse compared to the content of the primary supplier catalogs. Because the integrator has an active data-sharing relationship with its primary suppliers, and because these suppliers preferably actually have a printed version of their catalog, the on-line content of the primary suppliers may be rich.

The manufacturer names and product designations in the list of TAQ products are preferably hyperlinked to more detailed information about each item, just as a full and complete description of the product is available from database server DS_A and web server WS_A. There may be an image of the product from one or more angles, and there may be one or more tables that describe the different available features of the present item as well as operating limits, safety precautions (such as hyperlinks to on-line Material Safety Data Sheets), and other information. While some or all of these data may reside on the integrator computer system, other portions may be retrieved via background queries to suppliers. This product information page may also contain a selectable screen button or other device to present the requisitioner with even more detailed information about the selected item. This detail page may contain even more information about the selected item. In either of these two pages, there is preferably a button or other selectable device to add one or more of these items to the requisitioner 's electronic shopping cart or carts as with the other requisition methodologies.

The description pages may also contain a requisition table for all of the different models of TAQ items (or any item) that the catalog offers to customers. In this way, the requisitioner merely needs to enter a quantity and choose to add the item to his or her shopping cart. These pages also allow the requisitioner to add the presently selected item to one or more of the requisitioner 's or company 's hot lists.

The catalog drill down and search results may alternatively "prefer" one or more suppliers. For example, if the integrator site coexists with a distributor

D_F site (as in FIG. 2 or FIG. 3), the search results may favor products that come from the distributor D_F catalog (e.g., place these products at the top of the page). Also, the content of the catalog descriptions may not be as uniform as with other embodiments of the present invention. For example, the favored distributor D_F may have authored detailed descriptions for certain vendor products, and may not have for others. The vendors themselves may have authored detailed descriptions (although possibly not as complete as the D_F content) for some other products. Some of the vendor products may not have detailed authored content at all. Likewise, the third party manufacturers may have authored detailed descriptions for the integrator site (even though these third party products are not part of the distributor 's D_F 's catalog).

For another search (e.g., breakers) FIG. 10 illustrates search results presented in an order to prefer the host distributor D_F. The search results may be given in the following order: distributor D_F authored catalog content; vendor-authored catalog content; third party authored catalog content; distributor D_F short descriptions; vendor short descriptions; and third party short descriptions. Alternatively, the company or requisitioner profiles may be set up by an administrator (or by the integrator by default) to display the results in a different order. Alternatively, on a company-specific basis, integrator I_A may implement a priority scheme in which the search results are ordered in a way that is specified in the company's profile. These search results are preferably hyperlinked to one or more detailed description pages as described above, and the requisitioner can add these products to his/her shopping cart in the same way as with the other requisition methodologies. If the detailed descriptions of selected products do not reside on the integrator system (e.g., third party products), then the integrator system will preferably background query to the supplier's third party's host computer, web server, database server, or some other third party computer to receive this information without having the requisitioner leave the integrator web site. After adding products to the shopping cart by the various requisition methodologies, the contents of the shopping cart may be viewed and requested. A partially full shopping cart is shown in FIG. 11 (accessed by selecting to "view shopping cart" from any page). The shopping cart preferably includes a description of the product, a catalog number (e.g., the integrator system catalog number), a quantity, a price per item, a warehouse (or geographic location) from which the item will be sent, the availability or promise date for the item, and the subtotal for that item. The price, availability status, warehouse, and/or promise date were preferably updated in real-time based on a background query from the integrator site to each applicable supplier computer system to locate this information as described above.

The total price including sales tax and shipping may also be included in the shopping cart. This page may allow the requisitioner to edit the contents of the shopping cart, transfer contents of the shopping cart to a hot list or into a new order template, or complete (checkout) a final order. The system preferably allows the requisitioner to utilize only one shopping cart at a time, or the system may allow multiple shopping carts to be used simultaneously.

Along with the shopping cart, the system web pages may also utilize a "cartlet. " The cartlet preferably contains the items that the requisitioner has selected for purchase as part of the present session on the integrator-based buying system. The cartlet serves the same function as the full shopping cart, except that the cartlet will typically be visible as part of the presently viewed web page. The cartlet may have a less detailed description of the chosen items than the shopping cart, but the cartlet 's visibility may be desired by some requisitioners. The cartlet may have a "checkout" feature that functions identically to the same feature on the full- view shopping cart, or the cartlet may be just for viewing. Although the cart and cartlet seem straightforward, the actual function of the carts may be quite complex in a multi-tiered purchasing system. For example, if a requisitioner requests a product, the information necessary to complete that order request may reside on more than one computer. The integrator web server, host computer, and/or database server may contain profile information about the customer and descriptive information about the product to be ordered, but the supplier system host computer (web server and/or database server) may preferably include the more detailed information about the product, the product availability or promise date, and/or the warehouse from which the product will come. Likewise, certain financial information about the customer's account with that supplier (including contract price or discount) may also reside on the supplier host computer (or other supplier computer). Therefore, when a request is made, the customer's personal computer (the requisitioner) interacts with the buying system 's web server WS_A (the server), which interacts (preferably in real-time) with the supplier's computer system. Then, this pricing and availability information is passed back to the integrator system web server

(and parsed into a completed order item) to be transferred to the requisitioner. From the requisitioner side of the transaction (the user 's computer), this multi-tiered data transaction appears seamless.

The pricing algorithm or discount is preferably agreed upon between the customer and the integrator or the customer and the supplier prior to account setup. The mathematical algorithms or conversion tables used may be virtually limitless in number and/or complexity. However, there may basically be a list price for the good, some adjustment made to this list price (e.g., subtract 15% from list price), and a resulting net contract price returned to the customer. The availability or promise date information may also reside on either an integrator or supplier host computer, database server, or web server. The integrator may receive some availability information on a daily or some other predetermined basis as part of a batch process with the supplier. To get more timely information, the integrator web server may preferably request real-time product availability status and/or a product delivery promise date by background query to a supplier host computer or other server. The query is preferably sent to the supplier along with the customer's account number (either with the integrator or the supplier). The supplier may then use this account number (or some other geographic identifying information such as a zip code) to determine where the closest supplier warehouse to the customer is located. The supplier 's inventory and warehouse records may then be searched to determine an appropriate availability status (e.g., in stock, on backorder, etc.) and/or delivery promise date.

To illustrate a range of possibilities in the web-based integrator system, an example is provided. In this example, the requisitioner uses the buying system of the present invention to select different products, from different suppliers, using different requisitioning methodologies, and adds the resulting three order lines to a pending requisition which is later converted into a single order from the requisitioner 's company to the integrator.

The requisitioner is a scientist who has developed a quality control test involving mixing samples with three chemicals in a particular proportion, measuring the pH of the reaction mixture, filtering the reaction mixture after heating it to 150 degrees for one hour, and then weighing the recovered solids. The scientist works at the central research facilities of Company A and, as a result of the development efforts, has made repeat orders for the three chemicals in 500 ml bottles. The scientist plans to visit three of Company A 's manufacturing sites in three different states to evaluate his test method on samples of the in-process materials at each manufacturing site.

In preparing for the trip to the first manufacturing site, he realizes that the site lacks an appropriate pH electrode to measure the reaction mixture. Accordingly, he logs into the integrator computer system, provides his registration number and password and is presented with a choice of account numbers (from a pulldown menu listing integrator account numbers for the central research facility and five manufacturing sites). He selects the account number for the first site, and also (in a customer-specific data field defined for Company A), designates the Project Number for quality control methods development. He is now ready to start selecting items for a future order to be delivered to that first manufacturing site.

In this example, the first product is a pH electrode requested by way of a "catalog search. " In a catalog search, one or more keywords for a desired product

(product A) are entered by the requisitioner, e.g., "pH" and "solid state". The integrator computer system searches, based in part from information stored on the integrator database server, to identify the "hits", i.e., matching products provided from various suppliers. Assume that the pH meter used at the first manufacturing site is of older type and requires a different connector than the one he uses at central research. Under these circumstances, assume that all of the pH electrodes (solid state) that he finds are of the wrong connector type. But two of the brands represented by distributor F would otherwise meet his requirements. If the matching products are not exact matches, the requisitioner may wish to view more products from the supplier of a "close " match. The requisitioner selects the closest matching product from a particular supplier, for example, D_F. In this example, the integrator computer system will "punch-out" to supplier D_F's computer, based upon a prearranged protocol. In punching out, the integrator computer system will take the requisitioner product query information and relevant information from the customer profile (such as the requisitioner 's D_F account number, if present, as well as the login name and password for the supplier computer system). The integrator computer system sends a message in, for example, XML format, to the supplier D_F computer. Because of pre-arranged coordination with the integrator computer system, the supplier computer system identifies the request and uses the embedded supplier system login information (or other customer-specific data) to access the supplier system.

After this punch-out login, the requisitioner is preferably presented with a frame, a window, an overlay, or some other web device that allows the requisitioner to view the contents of the supplier web site without leaving the requisitioner 's current session on the integrator system. Preferably, the supplier site is shown within a frame of the integrator site, so that the requisitioner will still see the border and URL of the integrator site.

In the supplier frame or window, the requisitioner is shown a web page that enables the requisitioner to browse the content of the supplier 's catalogs and/or perform a further search on the content of these catalogs. For example, the first web page shows solid state pH electrodes available from distributor D_F of a first brand, in several different models with different style connectors. The web page is being communicated to the requisitioner from the supplier site through the integrator web session. The "look and feel " of the supplier window will primarily be determined by the supplier site.

The requisitioner will perform a search or drill down through the supplier catalog to find a more exact match to his or her desired product. Thus, if the connector style of interest is not on that first page, a Boolean search on distributor D_F's site with "pH", "solid state" and a designation of the desired connector style may produce a hit list from which the requisitioner can view appropriate electrodes of two different brands, each available through distributor D_F. Preferably, there is a "local" shopping cart or other device that holds each product (electrode) that the requisitioner 's selects (on the supplier D_F's site) until the requisitioner is finished selecting products. For now, assume that the requisitioner selects two electrodes, one of each brand. As the requisitioner selects items for the shopping cart, supplier D_F 's site will also typically look up price, availability, promise date, or other real-time product information about each selected product using the information communicated to the supplier site from the integrator site. Once finished, the supplier site window or the integrator site outer frame will preferably present the requisitioner with a web page button or other selectable device that acts as a local "checkout " for the products in the local shopping cart.

After selecting "checkout, " the supplier site typically transfers all necessary real-time product information (e.g., on both selected electrodes) back to the integrator computer (via XML, EDI, OBI, etc.) and closes the local session (supplier side) with the requisitioner. The integrator site may then close the window, frame, overlay, or other web device that contained the supplier site session. Preferably, the products that were "checked out" on the supplier site have been transferred into the requisitioner 's integrator site shopping cart (added to whatever other products may have been in the shopping cart before the punch-out). Thus, the shopping cart on the integrator site will now show two electrodes of different brands, which is available for immediate shipment to the first manufacturing site and the price that the integrator will charge Company A for each electrode.

In this example, the requisitioner also desires a second product (product B), perhaps one of the three chemicals (e.g., acetone) in a 100 ml size. The requisitioner may browse on the integrator web site through on-line catalogs and find a product that appears to be sufficient for his/her needs. The integrator computer system then "queries " the identified supplier computer system in the background, i.e., without changing the screen viewed by the requisitioner, for product availability for shipment to the first manufacturing site and price.

For example, the requisitioner may select product B from the catalog of supplier M_c. The integrator computer system obtains real-time price, availability, and/or promise date information. Because the computer systems of both the integrator and the supplier have been coordinated to communicate this information (via XML, OBI, EDI, etc.), the integrator can query the supplier computer (preferably in the background of the requisitioner 's session with the integrator), to obtain this real-time information.

Preferably, the requisitioner 's session remains controlled by the integrator computer system. The request made by the integrator system to the supplier may include the requisitioner 's supplier account number, product query, or any other relevant information that will assist the supplier computer in providing the requested data. In this example, the supplier computer may need only the requisitioner 's account number to determine contract pricing, warehouse availability, and promise date for the selected product.

The supplier computer will use the identifying product number for a

100 ml bottle of the first chemical and a transferred account number (or other information) to generate the requested real-time product information. This real-time product information will be sent to the integrator computer and incorporated, along with the requisitioner product query and certain customer profile information, into an order line item, showing product availability (as provided by the supplier system) and price (perhaps derived from the price quoted by the supplier system to the integrator system by applying a percentage mark-up or fee, which is coded by the integrator host computer for Company A's pricing on items obtained by the integrator from the particular supplier). This product, a 100 ml bottle of a chemical, will be added to the shopping cart along with product A.

In an alternate form of querying a supplier computer, a requisitioner 's keyword or other search could be used to trigger a catalog search on one or more supplier computers. In this example, supplier computers provide a catalog search engine that accepts a string of characters (e.g., keywords) to initiate a catalog search. When a requisitioner inputs a keyword or other search into the integrator computer

(for example the name or CAS number of the chemical and the quantity "100 ml"), the integrator computer converts this search query into a string of characters (a search string) that a supplier computer may use to process a search. The results of this supplier search are then sent back to the integrator computer and displayed for the requisitioner. This requisitioner 's search query can be simultaneously converted into proper search strings for several different supplier computers (because different suppliers may require the search string to be formatted differently) and sent to search all of these supplier computers.

In this example, the requisitioner also desires a third product (product

C). Perhaps the requisitioner wants a container to collect the solid materials after filtration at the first manufacturing site and bring it back to the central research facility for further testing. The requisitioner may browse through the third party catalog on the integrator web site and see a small description of a third party product that may suit his or her needs. Before requesting to purchase the product, the requisitioner may wish to view a more detailed description of product C. As with product B, the integrator site may have a communicative relationship with a supplier of product C that allows the integrator computer system to query the supplier computer system, in real-time, for product information. In this case, the integrator computer system may request, for example, a fuller description of product B. In response to this query request, the supplier system will preferably pass the requested description back to the integrator system. Because this information was requested in a background query rather than a foreground query, the requisitioner typically is not aware of this information transfer between the integrator and the supplier. The requisitioner may then add this item to his or her shopping cart and a third order line item is preferably created.

If the requisitioner is satisfied that the three products in the shopping cart (the three order line items) are his or her complete order, the requisitioner will preferably select to "check-out " and create a proposed order (a requisition) for these three items. At checkout, a requisition header is constructed based on the requisitioner 's relevant customer profile information and selections made by the requisitioner initially (e.g., the Project Number). Based on the availability information on the three products, the requisitioner may choose to modify the request at this point (e.g., request express delivery of the third item to assure that it will be at the first manufacturing site when needed). This header information is combined with the three order lines (including item descriptions, quantity and price) and the requisitioner "accepts " the order. If the total cost of the proposed order is within the requisitioner 's approval limits (as defined by his requisitioner profile), the order will then be created between the integrator and Company A and three orders will be sent to distributor F and the other two suppliers to deliver each one 's respective item to the first manufacturing site. After shipments are made, invoices are generate by the three host computers to the integrator and from the integrator to Company A.

Assume, however, that before accepting the order, the scientist realizes that he may need the same materials, plus filters, at the second manufacturing site and the third manufacturing site. The requisitioner already has, based on his orders for the central research facility, a "hot list" including the three chemicals in 500 ml bottles, the filters he uses and the standard pH electrode he uses. To facilitate future orders under the central research account number, he already has an order template for one bottle each of the three chemicals and one pack of the filters. On the check-out screen, he can designate the 100 ml size of the first chemical and both pH electrodes (with special connectors) to be added to that personal hot list. For the pending order (for the first manufacturing site) he selects one of the two pH electrodes (by deleting the order line identifying the second one); if both are available, he may select the cheaper one. In later creating an order for shipment to a second manufacturing site (under a different account number, but the same Project Number), he may choose the other special pH electrode (based on availability). Alternatively, he may leave both electrodes on the current order, intending to try both and later order only the one that performs the best (or, if both perform equally, to select whichever is available or cheaper).

On order acceptance by the requisitioner, if the order size exceeds his approval limits in his profile, the integrator computer system sends an e-mail to the requisitioner/approver identified in his profile. That requisitioner/approver logs into the system, goes to requisition review, sees the status of pending proposed orders

(requisitions) and selects this particular order for review. After looking at the five order lines, the requisitioner/approver may approve and the order proceeds. Alternatively, the requisitioner/approver may see that two different pH electrodes have been selected and decide (based on personal knowledge, brand identity or otherwise) that the cheaper of the two is at least as good and delete from the order the more expensive pH electrode. The requisitioner/approver then approves the requisition and it is converted into an order from Company A to the integrator and purchase orders from the integrator to the three respective suppliers.

At the conclusion of testing at the three manufacturing sites, if the development effort is successful, the researcher may have his company administrator add the appropriate products (chemicals, filters, pH electrodes) either to individual hot lists for other requisitioners at the respective manufacturing sites or to a Company A hot list available to all requisitioners. Alternatively, he may work with requisitioners at each site to develop order templates for repetitive orders by each plant (using, for example, the appropriate bottle size of the three chemicals based on each one 's planned usage).

After filling the shopping cart and viewing the real-time price and/or availability information, the requisitioner may then decide to purchase some or all of the contents of the shopping cart. This process (like in a supermarket) is known as checking out. If the customer has an account with the integrator or a supplier, then the system preferably already knows the shipping information, billing information, and/or any other necessary information to bill the customer and ship the products to the customer. If the customer does not have an account with either the integrator or the supplier who will provide the product to the customer, the customer may preferably be presented with a checkout form to provide the system with cash account billing information. In such a situation, because the relevant billing and shipping information has not previously been collected by the web-based integrator buying system, the system preferably requires the requisitioner to input such information before a purchase order of any kind is created.

Because the requisitioner has accessed and is dealing with the web- based integrator buying system (and not each of the suppliers individually), the present invention may satisfy multiple supplier purchase orders with a single company purchase order (from a single requisitioner shopping cart). This single PO may simplify the buying process from the requisitioner 's point of view. For example, if the requisitioner accepts to purchase items from supplier M_A and supplier D_F, there is preferably a single purchase order created reflecting the sale of these items from the integrator system to the requisitioner. At least two additional purchase orders are created reflecting the sale of these same items from each of the suppliers M_A, D_F to the integrator system I_A. In this way, from the requisitioner 's point of view, the product was purchased from the web site. Preferably, each product is still shipped directly to the customer from the stocking manufacturer or distributor.

For some desired products, there may not be a supplier or third party catalog item identified that satisfies the inquiry. For these special circumstances, the integrator-based buying system may allow requisitioners from certain companies to fill out a web-based product requisition form (requisition builder or "WebReq ") to request that the integrator I_A locate the product from somewhere. Requisition builder is an electronic form that the requisitioner can use to source items not found by any of the conventional cart-building means: rapid order, hot list, template, word search or browsing. It is preferably accessed from an area of the Integrator website from which a requisitioner can select the other ordering methodologies, such as from an "ordering" tab or web page. The requisition builder creates a form into which "header" info (e.g., account number, PO number, department charge, ship-to address and attention line, etc.) is copied from the customer's profile and/or from the current order. The requisitioner may type free form info about the requested product(s) into the requisition builder form, so that an integrator system employee (customer service representative) can look for the item (usually from a designated supplier) off-line, build a catalog entry for the new third party product (if required), and then create an order for that product or provide price and availability to the requisitioner or approver who makes the purchasing decision.

When the requisition builder ordering methodology is selected, the requisitioner is preferably presented with an electronic form or other data entry option into which the requisitioner can input available information about a desired product. FIG. 12 shows one example of a web-based requisition form for supplier information. As seen in FIG. 12, the requisition builder may prompt the requisitioner to identify a supplier (typically a manufacturer or known distributor) of the desired product. The identification information may include the supplier 's name, phone number, address, and/or fax number, if known. Alternatively, there may be a pull-down menu or other selection device that allows the requisitioner to select a supplier from a predefined list of suppliers. This predefined list preferably comes from the profile information (either company or requisitioner profile) based on a requistioner 's preferences or past purchasing history. Having a selectable list of predefined suppliers may be useful in limiting requisitioner misspellings or typographical errors. After entering the supplier information or selecting from the predefined list, and providing other available descriptive information, the requisitioner preferably completes this electronic order "header" information form with some electronic signal, e.g., by clicking an "OK" button with a mouse.

A second requisition builder electronic form is then preferably sent to the requisitioner to gather more detailed information about the desired product. FIG. 13 shows one example of such a second requisition builder form. This additional information can be used by the customer service representative to create line item information about the desired product or products from the chosen supplier. This line item information may include a product name, part number, description, units, retail price, quantity and/or comments for the supplier. This second requisition builder electronic form also preferably prompts the user to set a requested (estimated unit) price for the desired goods. This price may affect how the approval process is undertaken. This line item information may be filled out for each desired item, and both the header and line item information is preferably sent electronically to a customer service representative associated with the Integrator I_A when the line item form is complete.

The customer service representative receives the supplier (header) and line item information in an electronic format, typically sorted by supplier name.

Initially, the customer service representative uses the line item information to confirm that the desired item does not currently exist on the Integrator catalog server CS_A or on the Integrator host computer HC_A. If the representative finds the desired item on one of the Integrator computers, the representative will preferably send a message back to the requisitioner informing him/her of the item's availability.

Alternatively, the representative may transfer the desired item directly into the requisitioner 's current shopping cart. If the desired item is not found on the catalog servers, the customer service representative will use the electronic line item information to locate the item.

The customer service representative may use the supplier-specific information to locate a telephone number, email address, or other contact information for a supplier. Once the customer service representative identifies the appropriate supplier or suppliers of the desired product, the representative preferably contacts that supplier for more detailed information about the desired product, its price, and/or availability. The representative may contact the supplier by telephone, by email, through the Internet, or by some direct computer-to-computer connection.

The representative can then use the line item information as well as any other product or pricing information from the supplier to build a part or record for the item in the Integrator system. The customer service representative may build the part with both mandatory fields (describing the product) and special fields (such as pricing rules). The customer service representative may also use various comment fields to insert customer or supplier-specific information such as a direction regarding the shipment of the goods or a direction to provide goods from one specific item lot. With requisition builder, the customer service representative preferably builds the part before the customer actually commits to buying the good. The customer service representative may preferably use a graphical user interface (GUI) that is Web-based rather than a traditional mainframe (text only) interface to build the part.

As the part is being logically built in the Integrator computer, the customer service representative typically determines a price to charge the customer for the item. The supplier location and price determination may take up to approximately two days to complete. The pricing process may be further complicated because of various pricing methodologies and discounts given by different suppliers to different customers.

Because the requisition builder methodology is most often used when a requisitioner orders products from third parties with whom the Integrator does not have a significant business relationship, the line item creation may be further complicated by various contract pricing rules. For example, a typical third party product may have a list price for selling the good generally. The Integrator system may have an Integrator cost price associated with that good that is somewhat less than the list price. This Integrator cost determines how much the Integrator charges typical requisitioners using the web-based buying system. Additionally, a particular customer may have a contract or other buying relationship, outside of the Integrator system, in which they have negotiated with a supplier for a certain price or discount for goods. If this customer-negotiated price is below the Integrator cost for the product, the requisition builder system preferably is capable of creating a "ship part record" that uses the cheaper customer contract price rather than the more expensive Integrator cost as the price of the desired goods.

Traditionally, a customer service representative would have to telephone or email enormous amounts of information back and forth with the supplier and the requisitioner to determine the appropriate pricing methodology for a requisitioner and supplier. With the requisition builder buying methodology, it is possible to build this special pricing information directly into the comment line of the requisition. Additionally, after a pricing rule is set up or identified, that rule may be inserted into the customer 's company or requisitioner profile so that the same pricing discount may be used for future purchases of the same good or of goods from the same supplier. Therefore, the next time requisition builder is used to purchase goods from a supplier with which a customer has a discount, the requisition builder software can automatically recognize this pricing relationship from the customer profile information and make the supplier aware of the relationship prior to or at the time of sourcing the good. This is known as a ship part record. Because it is set in the customer profile, the ship part cost will follow the same customer for future purchases.

As the line item information is being used to build the desired part, the requisition builder system preferably assigns a requisition builder identification number to the part so the Integrator system can track the part before checkout. After the desired item is actually purchased (during checkout), the item will be given an Integrator system order number.

To view the status of the desired items, the requisitioner may go to the shopping cart page. As described above, the shopping cart details line item information about the goods that have been selected by the requisitioner. The shopping cart may also provide information about the status of the goods, e.g., waiting for approval, item delivered, etc.

The shopping cart described above held all of the requisitioners regular Integrator system items in a single shopping cart (e.g., goods requested by rapid order, template, hot list, catalog search, and catalog browsing). If a requisitioner uses the requisition builder to specify additional products, a second shopping cart for the requisition builder items is preferably created. This dual (or more) shopping cart system may be preferable to a single cart system because the items procured using the requisition builder may have different approval levels and/or other features than the general Integrator catalog item orders. An example of a dual shopping cart web page is shown in FIG. 14. A first virtual shopping cart, labeled "Fisher Cart, " contains a methanol item selected by a non-requisition builder purchasing methodology (i.e., hot list, template, rapid order, catalog search, catalog browser), and a second virtual shopping cart, labeled "WebReq Cart, " contains glasses selected using the requisition builder purchasing methodology.

During checkout with the multiple shopping carts, the Integrator system preferably creates two different records. Because there may be different circumstances related to the catalog items versus the requisition builder items, the two shopping carts may be treated differently. Both of the records obtain infbπnation from the customer profile.

Typically, the requisition builder records are built on a supplier-by- supplier basis, i.e., one requisition builder per supplier. Therefore, the Integrator system may allow a requisitioner to request products using requisition builder from only one supplier during each purchasing session. Some Integrator systems may not allow more than two shopping carts during a single purchasing session. More specifically, if a requisitioner has at least one line item built from a supplier using requisition builder, the requisitioner may add additional items from that same supplier to the second shopping cart during the purchasing session, but the requisitioner typically may not request items using requisition builder from a second supplier.

Alternatively, some Integrator systems may allow three or more separate shopping carts during one purchasing session. The first shopping cart would include the catalog products selected using the conventional purchasing methods. The second shopping cart may include requisition builder items from one single supplier. The third shopping cart may include those items that were requested through a direct "punch-out" to a supplier. Additional shopping carts could be created in some circumstances to hold items requested from other suppliers using the requisition builder system. Each of these shopping carts will preferably include a separate record and will go separately through the approval process. These different carts may even have different approval levels from each other as defined in the customer profile. The requisition builder shopping cart or carts may also provide information about the status of a particular line item. Initially, the line item will preferably indicate the item is "being sourced. " After a price is found by the customer service representative, the item status may change to "awaiting approval. " At this point in time, the requisitioner can decide whether or not to actually purchase the desired part (checkout). If the requisition builder shopping cart is "checked out," the Integrator system preferably automatically checks the requisitioner 's customer profile to determine if the proper approval level is met (i.e., if the customer is allowed to approve items in the amount of the approval price). The customer profile may have a different approval level for requisition builder items, as compared to conventional catalog items.

When the requisitioner first described the desired goods in the requisition builder form, the requisitioner preferably included a desired price to pay for the good or goods. During checkout, if the actual price of the desired goods is below the requested price for the goods and within the requisitioner 's approval level, the Integrator system will preferably automatically send a purchase order to the supplier. If the price of the desired goods is above the requisitioner 's request price, the system will preferably prompt the requisitioner to confirm whether or not the actual price is acceptable. If the actual price is accepted but above the requisitioner 's approval level, the Integrator system preferably will send an electronic message or other indicator to the appropriate approval entity (as determined by the customer profile) to await approval of the order. Once that approval is given, the order will be directed to the supplier. The requisition builder system may be flexible in the way that different customers, either companies or requisitioners within each company, are treated by the Integrator system when requisition builder is used. For example, there may be a set of overall Integrator system rules (site rules) that define in what circumstances an item is added to a second shopping cart or when a certain requisitioner is billed directly by a third party supplier. In addition, there may be customer specific rules, for example residing in each company or requisitioner profile, which can modify or override the default Integrator site rules.

One example of the interaction between these two sets of rules concerns the use of a second shopping cart. The Integrator system may have default site rules that state that goods requested from distributor D_F and manufacturer M_B, with whom the Integrator has a close relationship, should always go into the first (general) shopping cart. A second site rule may state that goods requested from M_κ, with whom the Integrator does not have a close working relationship, should go into a separate shopping cart. If a requisitioner 's profile has no information to the contrary, these rules are preferably followed.

However, a particular requisitioner may have one or more customer specific rules in their profile that changes the default site rules. For examples, a requisitioner may have a rule that products request from M_κ should go into the first (general) shopping cart rather than a separate shopping cart. There may also be customer specific rules that require requests for D_F 's products to be segregated into a separate shopping cart for all requisitioners of a certain company. These customer specific rules only alter the default site rules for the requisitioners to which the customer rules apply. The Integrator site rules and customer specific rules may also alter the billing relationship between the parties. For example, the Integrator site rule may provide that all requests for products from any supplier result in two purchase orders being made: one from the requisitioner to the Integrator and one from the Integrator to the requested supplier. However, because of a special relationship, a certain requisitioner may have customer specific rules that provide that all products requested from manufacturer M_κ will be billed and shipped directly from manufacturer M_κ to the requisitioner. Preferably, the Integrator system will satisfy the customer specific rules by embedding or attaching a comment or other notification to the request for the product made to the manufacturer M_F. In this way, the Integrator site may act merely as a portal to finding goods in certain special situations, rather than also being a billing clearinghouse.

Many variations can be made to the overall Integrator site rules and the customer specific rules. The rules may deal with pricing, delivery, billing, or any other subject matter. They may be requisitioner specific, or the rules may affect a group of requisitioners or an entire company. The general purpose of allowing customers to alter general site rules in certain situations is to better adapt and personalize the Integrator site to each user.

After a part has been built during the requisition builder process, a customer can use the part number in a future rapid order. The part may not be effectively searchable by other users (because there is little product descriptive content), but the rapid order system will be able to match the product number to the appropriate product. At some future time; the third party supplier or some other entity may create a complete catalog description of the requisition builder product and make this product generally available with a full description as part of the Integrator catalog system.

The use of the requisition builder feature is preferably selectably available on a company-wide or requisitioner-specific basis. Hence, an administrator or other company official may turn the requisition builder feature "on" or "off" for the entire company or for one or more particular requisitioners by setting the company or user profile accordingly.

At this point, the shopping cart has been reviewed and the contents have been found acceptable, or a requisition builder form (WebReq) was filled out and a satisfying product has been found. The requisitioner now must approve the order (if his requisitioner profile allows such action) or await approval from an authorized approver or account administrator. This effectively ends the request and order of a product as part of the integrator site, but there are preferably some "housekeeping " functions that may be useful in using the integrator buying system. In FIG. 4, two of these pages give the functionality to review recent requisitions made by the requisitioner or by an approver of same or all of his/her requisitions (to view order status) and to view the accepted orders for the cuπent account number from the host computer (to see what other activity occurs with your account).

When a requisitioner requests to see the requisition history, the requisitioner is presented with a page that shows recent requisitions made by that requisitioner. Depending on whether the current requisitioner is an administrator (or approver) or a lower level requisitioner, the requisitioner may be presented with different web page options. A requisitioner may preferably only see the requisitions that he or she has recently placed. An approver may see a list of all requisitions that he or she is authorized to approve. The requisition page preferably displays a list of the order dates, PO number, account number, total purchase price, and requisitioner. An approver may be given the choice to either approve, deny, or postpone each requisition. In this way, the account administrator or approver may have more control over not only whether or not a requisition is allowed, but also when a requisition is allowed to go through (by postponing the requisition for a period of time).

A lower-level requisitioner (user) is preferably not given the choice of whether to approve or disapprove an item for purchase (unless the requisitioner 's profile allows such approval). Instead, the requisitioner may be given an update as to the status of the various requisitions that that particular requisitioner has requested recently. The most recent requisitions may still be waiting at the integrator's customer service. There may also be a "view details " selectable button that provides the requisitioner with more detailed information about where in the purchasing chain the requisitioned product cureently resides. Toward the end of the list of requisitions, there may preferably be requisitions that have already been approved (and/or processed). With these processed items, there may preferably be a tracking number or other shipping code provided for the order with a hypertext link to the web site of the shipping company (where more information about the current state of delivery may be found).

An order history or order review page may preferably present the customer with a list of all prior requisitions that have resulted in successful orders for a given account number. An order history or order review may preferably go back to the host computer for a user 's account and display a list of all the orders from all sources for a particular account. When using the integrator system, the order review may be useful to see what "other" users of the same account have been purchasing to prevent overlap or overspending.

As a further example of using the web-based buying system with requisition builder capabilities, assume an end user desires to build and equip a laboratory to practice real-time PCR exactly as shown in an article or other scientific publication. This end user works for a company that has an account with the Integrator and has a company profile, requisitioner profile, and hot lists associated with this account. To equip the PCR laboratory, the end user needs to obtain various materials, chemicals, and equipment as shown in the TABLE 1 list of products.

TABLE 1

To equip the PCR laboratory, the end user may first request several common laboratory products that may or may not be specific to PCR. For example, TABLE 1 lists powder free gloves, gel loading tips, microcentrifuge tubes, a pipette, and ART pipette tips. Because these products are used for many different laboratory purposes, the end user 's company has preferably created a hot list that contains one or more of these items. To request these products, the end user need only log onto the Integrator site and select the appropriate company or requisitioner hot list that contains these items. These hot list items are then preferably added to a first (general) virtual shopping cart.

A second group of products that the end user may obtain to equip the PCR laboratory are laboratory items not, in this example, previously included in a company or requisitioner hot list for the end user. The end user preferably uses one of the buying methodologies (i.e., rapid orders, templates, catalog search, catalog browsing, etc.) to locate and request these products. For example, to locate the appropriate bacterial and human DNA for the laboratory, the end user may type in a catalog keyword search for "DNA. " The end user can then drill down through the results of the search and locate the appropriate human and bacterial DNA. These and other appropriate items, e.g., reaction tubes and PCR buffer, are then found (e.g., by searching under the keywords "PCR" with "buffer" or "tubes") and added to the first shopping cart, for later addition to hot lists and ordering.

The end user may use the catalog browsing feature to locate several other products from this second group for the laboratory on the Integrator site. For example, to locate an oligo probe and a Molecular Beacons probe, the end user may select the letter "p " and then the word "probe" from the catalog browser drill down menus. The end user may locate an appropriate probe or probes from a supplier and adds those items to the shopping cart, or the end user may need to further customize these goods (see below). A similar catalog browsing procedure may be used to obtain the SmartCycler starter system. The SmartCycler system, a capital equipment item costing over $25,000, may be found in the Distributor F catalog in the Life Science catalog using categories or via the keyword "thermocycler" or "SmartCycler".

To complete the laboratory, the end user may desire several products from a third group that the end user could not find in the authored catalog content on the Integrator site. The Integrator system may need to punch-out or gather additional product, price, and/or delivery information from the supplier web server for these products. For example, as shown in TABLE 1, the end user may search for a particular brand of Taq DNA Polymerase. The end user may search for this item by using "taq" or the brand name as search terms in a catalog search. Assume that the results of this search do not include an appropriate product for the end user. The end user may then try to drill down or browse through the on-line catalog or use various other buying methodologies to locate the product. If the end user can not locate the desired brand of Taq Polymerase by the above buying methodologies, the end user will preferably use the requisition builder ("WebReq") to locate the appropriate products.

After selecting the requisition builder form, the end user is presented with a first form to input header information about the supplier (e.g., LTI) of the taq polymerase. The end user enters the supplier information and is presented with a second form for inputting line item or product-specific information about the taq polymerase. Because the MgCl₂ and DNTPs are also LTI products, the end user preferably adds additional line item information about these products. The customer service representative associated with the Integrator preferably uses this information to search the Integrator site for the products. In such instances, the customer service representative finds the products in the Integrator site database (the end user just missed them).

However, assume that these three LTI products do not have full, authored descriptions on the Integrator website. Therefore, the Integrator system uses the available product information to perform a "background punch-out" to the LTI product information server to obtain updated product description, pricing, and/or availability information for the desired products. During this background punch-out to obtain product, price and delivery information about the taq polymerase and the other products, the end user preferably does not see any activity other than perhaps a status of the end user's request.

When the customer service representative locates the appropriate information, he or she presents the end user with the opportunity to electronically request the item. When the end user requests the item, the Integrator site preferably examines the company and requisitioner profile for the end user to determine the appropriate shopping cart and billing/approval options for this product. For example, the company profile may include a rule that these background punch-out items be placed in a separate shopping cart from the first (general) Integrator site virtual shopping cart. Also, the company profile may have a general rule that items requested using requisition builder and the background punch-out should be shipped and invoiced directly from this particular supplier (e.g., LTI), rather than through the Integrator site.

Either of these company level rules may be changed by a requisitioner- specific rule that differs from it. For example, even though a company rule states that a particular item should be put in a separate shopping cart, a requisitioner rule may override that company rule for this particular requisitioner requesting products from this particular supplier. In either case, the product is preferably put into a virtual shopping cart for later check-out.

A similar requisition builder session may be used to request other non- catalog products such as the Tween 20 and BSA from Sigma. After failing to locate these products using the catalog-based buying methodologies, the end user may again use requisition builder to request the BSA and Tween 20. As in the above example, the end user preferably fills out web-based information forms and the customer service representative searches the Integrator database for the Tween 20 and BSA products. In this case, the customer service representative does not find the requested items in the Integrator database, and the representative uses the supplier header information to locate the appropriate supplier. After the appropriate products are found, the Integrator system may perform a background punch-out to the supplier site for updated description, price, and/or delivery information.

Once the necessary information is obtained to build the parts, the customer service representative preferably sends the complete product information back to the end user to determine if the goods are to be placed in the end user 's shopping cart(s). These products maybe added to the original (general) shopping, to the second "requisition builder" shopping cart, or to a separate, supplier-specific shopping cart. As in the above example, the billing and shipping options are preferably determined by the company and requisitioner profile rules.

Now that some common products have been requested using hot lists, some catalog products have been requested using one or more buying methodologies, and some non-catalog products have been requested using requisition builder and background punch-out, the end user preferably needs only four final items to complete his or her PCR laboratory: dye oligonucleotides; GAPDH primers; Oligo probes; and a Molecular Beacons Probe. The end user may locate these products using the above buying methodologies, but more information may be needed from the end user before product selection is complete.

Because of the specialized nature of these products, or because of some special relationship between the Integrator and this particular supplier, the end user may be presented with a "foreground punch-out" or "window punch-out" of the supplier's website rather than having the Integrator site or the customer service representative obtain the pricing/product/delivery information through background punch-out. With a foreground punch-out, a web page from the supplier's website is preferably framed, windowed, or otherwise presented to the end user via his or her web browser. The Integrator site session is still running on the user 's computer, but the user is presented with the "look and feel" of the supplier's website.

Presented with the framed page, the end user can navigate through the supplier site to find the appropriate product. In this case, the end user may need to provide the exact base sequence of DNA oligonucleotide required by the end user for the PCR laboratory. Through navigating the supplier web pages, the end user preferably selects or builds a description of the appropriate product or products for purchase. An identifier of these products is preferably sent back to the Integrator computer after product selection, and the supplier window or frame is preferably closed.

In a similar manner, the customer could use a foreground punch-out to customize the desired oligo and Molecular Beacons probes or to select the appropriate

GAPDH primer. If more than one desired customized product comes from the same supplier, both of these products may be requested during the same foreground punch- out. If the products come from more than one supplier, the end user preferably has to perform two separate foreground punch-out sessions.

Depending on the company and requisitioner profiles at the Integrator site, these foreground punch-out items may be added to the first (general) virtual shopping cart, a third or fourth separate shopping cart, or any other previously described shopping cart. Also according to the company and/or requisitioner profile rules, these items may be shipped and billed directly from the supplier to the end user, or they may be passed through the Integrator site and made part of the Integrator invoice to the end user.

At this point in the example Integrator session, the end user has preferably requested all of the necessary products from TABLE 1 for the PCR laboratory and has one or more shopping carts containing those items. As the end user "checks-out" each shopping cart (or individual item from a shopping cart), the

Integrator system preferably looks at the business logic and rules from the company and requisitioner profiles to determine if the end user has exceeded the dollar value of items for which he or she is authorized to approve. Each shopping cart may have a different approval limit based on the supplier, the type of product, or any other criteria. During this checkout procedure, or at any time when an item is in a shopping cart, one or more of the items may be added to a company or requisitioner hot list for future ordering on a repeat basis. For example, the end user could add the specific brand of Taq DNA Polymerase to his hot list to facilitate a less time consuming reordering process. These hot lists may not be appropriate for products such as the oligo probes, Molecular Beacon probes, and dye oligonucleotides that need customization during each order.

If the requisitioner limits are exceeded, the Integrator system preferably queries the requisitioner 's approver for approval of the order. If this approver does not have sufficient authority, the order may be sent to an administrator for approval. Once approval is given, the order is actually placed and the item or items will be delivered to the end user. The bill for the items may come in one integrated bill from the Integrator (as with normal catalog products) or the end user may be directly billed for some products from some suppliers according to the company and requisitioner profiles.

The requisition builder of the present invention may also be used in conjunction with another electronic purchasing system. For example, there may be a third party website that allows users to request and purchase various products from various suppliers. That third party system may have its own rules and business logic for authorizing spending limits and determining billing procedures. The Integrator system of the present invention may exist as one of many suppliers on that third party system. Therefore, users of the third party system may punch-out to or window into the Integrator's site and select one or more items found on the Integrator site, and then "check-out" these items on the third party system using business logic and other information found on the third party system.

If a third party user attempts and fails to locate a product from the catalogs on the Integrator site, that third party user can preferably use the requisition builder of the present invention to locate the desired product. Preferably, the third party user completes the web-based header and line item forms, a customer service representative associated with the Integrator locates the supplier and the requested product, and the product information (e.g., description, price, delivery date) are returned to the third party end user. Unlike in the previous examples, however, the approval levels and other business logic decisions are preferably made at the third party website rather than at the Integrator site. In this way, the present requisition builder invention could be expanded as a tool for content providers in addition to full system providers like the Integrator.

The above specification describes several different embodiments and features of a web-based buying system. Various parts, selections, and/or alternatives from the various embodiments may preferably be interchanged with other parts of different embodiments. Although the invention has been described above in terms of particular embodiments, one of ordinary skill in the art, in light of the teachings herein, can generate additional embodiments and modifications without departing from the spirit of, or exceeding the scope of, the claimed invention. Accordingly, it is to be understood that the drawings and the descriptions herein are proffered by way of example only to facilitate comprehension of the invention and should not be construed to limit the scope thereof.

Claims

What is claimed is:

1. A purchasing method, comprising the steps of:

maintaining at least one customer profile associated with each of multiple customers;

maintaining a database of items offered by each of multiple suppliers;

searching, on behalf of a customer, the database of items for a first desired item and, upon failing to find the first desired item,

providing a web-based requisition form to the customer.

2. The method of claim 1, wherein the step of searching the database employs a requisition methodology selected from the group consisting of a rapid order form, a hot list, a template, a catalog search, and a catalog browser.

3. The method of claim 1, wherein information associated with a selected customer profile is automatically used with the web-based requisition form.

4. The method of claim 1, comprising the steps of:

receiving the web-based requisition form identifying at least the first desired item; and

searching said database of items for said first desired item.

5. The method of claim 4, wherein said web-based requisition form identifying at least the first desired item includes information selected from the group consisting of: a desired price to be paid for the first desired item; the name of the first desired item; a description of the first desired item; the name of a manufacturer of the first desired item; the name of a supplier of the first desired item; an address for a supplier of the first desired item; a telephone number for a supplier of the first desired item; an email address for a supplier of the first desired item; shipping information about the first desired item; and pricing information about the first desired item.

6. The method of claim 5, comprising the steps of:

contacting a potential supplier of the first desired item; and

obtaining a price for the first desired item from the potential supplier.

7. The method of claim 6, wherein said price includes a customer contract price.

8. The method of claim 6, comprising the step of:

determining whether the price for the first desired item is within an acceptable range of the desired price and, if so, requisitioning the first desired item.

9. A purchasing method, comprising the steps of:

maintaining at least one customer profile associated with each of multiple customers; maintaining a database of items offered by each of multiple suppliers;

accepting a request for a first desired item from a selected customer;

maintaining information related to the sourcing of the first desired item in a first virtual shopping cart;

automatically using information associated with a customer profile for the selected customer in a web-based purchasing form after the selected customer is unable to locate a second desired item in the database;

receiving the web-based purchasing form, including a desired price for the second desired item, from the selected customer; and

maintaining information related to the sourcing of the second desired item in a second virtual shopping cart.

10. The purchasing method of claim 9, wherein the information associated with a customer profile for the selected customer is from the group consisting of a supplier name, a credit card type, a credit card number, and a purchase order number.

11. The method of claim 9, comprising the steps of:

tracking the status of the first desired item; and

tracking the status of the second desired item.

12. The method of claim 9, comprising the step of sourcing said second desired item, including obtaining a price for said second desired item.

13. The method of claim 12, wherein the step of obtaining a price for said second desired item includes obtaining a customer-specific price based on customer profile information.

14. The method of claim 9, further comprising the step of determining whether the price for the second desired item is within an acceptable range of the desired price and, if so, requisitioning the second desired item.

15. The method of claim 9, wherein the first and second virtual shopping carts are presented to the selected customer as part of a single web page.

16. A purchasing method, comprising the steps of:

maintaining a database of items offered by each of multiple suppliers;

providing a plurality of purchasing methodologies with which a customer can request said items;

accepting a request from said customer for a first desired item using one of said plurality of purchasing methodologies;

maintaining information related to the sourcing of the first desired item in a first virtual shopping cart; accepting a request from said customer for a second desired item using one of said plurality of purchasing methodologies; and

adding, based on profile information, information related to the sourcing of said second desired product to one of a plurality of virtual shopping carts.

17. The purchasing method of claim 16, wherein said profile information is selected from the group consisting of supplier name, supplier profile information, company profile information, or requisitioner profile information.

18. The purchasing method of claim 16, wherein said purchasing methodologies are selected from the group consisting of hot lists, templates, catalog searches, catalog browsing; rapid order , and requisition builder.

19. The purchasing method of claim 16, wherein said step of adding includes:

adding information related to the sourcing of said second desired product to the first virtual shopping cart.

20. The purchasing method of claim 16, wherein said step of adding includes:

adding information related to the sourcing of said second desired product to a second virtual shopping cart.

21. The purchasing method of claim 20, wherein said information related to the sourcing of said second desired product is added to the second virtual shopping cart because said request for a second desired item was placed using requisition builder.

22. The purchasing method of claim 20, wherein said information related to the sourcing of said second desired product is added to the second virtual shopping cart because a business rule in a company profile associated with said customer establishes that all products requested from the supplier of the second desired product are associated with a supplier-specific virtual shopping cart.

23. The purchasing method of claim 16, further comprising the steps of:

maintaining information related to the sourcing of said second desired item in a second virtual shopping cart;

allowing the customer to checkout any items associated with said first virtual shopping cart; and

separately allowing the customer to checkout any items associated with said second virtual shopping cart.

24. The purchasing method of claim 23, further comprising the steps of:

generating a purchase order from an integrator, who maintains said database of items offered by each of multiple suppliers, to the customer for any items associated with said first virtual shopping cart after checkout; and generating a separate purchase order for the items associated with said second virtual shopping cart after checkout, wherein said second purchase order is from the supplier of the items associated with said second virtual shopping cart and to said customer.

25. A purchasing method, wherein a customer has successfully requested a first desired item for purchase and has searched for, and failed to find in a database, a second desired item, comprising the steps of:

maintaining a customer profile associated with the customer; and

automatically using infoπnation associated with the customer profile in a web-based requisition form, the web-based requisition form for use with an alternative approach for finding the second desired product.

26. The purchasing method of claim 25, comprising the steps of:

receiving the web-based requisition form, including a request for the second desired item, at an integrator site;

locating a supplier of the second desired item;

maintaining information related to the first desired item in a first virtual shopping cart; and

maintaining information related to the second desired item in a second virtual shopping cart.